Application Tracker

Basic tool requirements:

General

• Create a database of profiles for people interested in applying to open Berkman positions,
• Accept application materials – CVs, cover letters, other various attachments/files including links and multimedia.

Administrators / decision makers

• Can manage job listings,
• Have the ability to report on candidates and the materials they've submitted,
• Can classify and download all of a certain kind of file (eg: all CVs, or all proposals, or all letters of recommendation, etc.),
• Are able to download all materials for a specific candidate (eg: get all of John Smith's application materials),
• Have the ability to send responses to applicants individually and as a group (eg: when a position has been filled, email all other applicants of the change in status),
• A basic "workflow" to track decisions and where an applicant stands in the process.

The applicant

• Can manage their profile and complete it incrementally,
• Can apply to multiple positions and tailor their application/letters/files to each application,
• Allow non-applicants – primarily people submitting letters of recommendation on an applicant’s behalf – to submit materials that would link to the applicant’s application

More info of a more technical bent

We'd probably have these models, minimally:

• User - has many jobs, the administrators.
• Applicant
• JobApplicationStatus - a basic workflow allowing to accept, reject, and move JobApplications through a set of stages. . .
• Job - A job, with file attachments.
• JobFile
• JobFileCategory
• JobCategory
• JobMessages
• JobMessageType (defines a set of "triggers" and relates to a JobMessage to allow for a set of customized messages per job and at points relating to an applicant. . the "thanks for applying" message, the "sorry, job is filled" message, etc.)
• JobApplications (relates jobs and applicants)
• JobApplicationFile
• JobApplicationFileCategory (categories could probably be a single polymorphic model)

In narrative -

• A User has many Jobs.
• A Job has many categorized JobFiles and is organized in (at least one) JobCategory
• An Applicant has many JobApplications.
• A JobApplication has many categorized JobFiles
• A Job has many JobMessages, invoked by the backend at various stages according to their JobMessageType.
• A JobApplication has a JobApplicationStatus.

And then we'd want a set of administrator-level tools to do things like:

• get all the CVs for a job application,
• get all the letters of recommendation,
• fill (or close) a job position and auto-email all the applicants,
• Deactivate all the JobApplications for an Applicant if we're just not

interested in them,

• Send custom messages to job applicants.

We're expecting that the GSoC participant would help us define a scope/requirements doc to the level of detail they need to be productive - it doesn't have to be spelled out in exquisite detail in your application.

We envision this being written in Rails, and are open to it being a plugin to an existing application (eg. Redmine) or a standalone application altogether. We are not entirely beholden to Rails as the implementation language, though we do have a strong preference for it. Put it this way: If we do not get a qualified applicant to build the application in Rails, then we're willing to consider building it in something else.

Your ideas are GREATLY appreciated!