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 want this application to work perfectly on both Postgres and MySQL.

We'd probably have these models, minimally:

• User - has many Jobs. This keeps track of administrators. Ideally it'd be able to use pluggable authentication - specifically LDAP.
• Applicant
• JobApplicationStatus - A basic workflow allowing Users to accept, reject, and move JobApplications through a set of stages. . .
• Job - A job, with file attachments.
• JobApplicationFileRequirements - Allows a User to define what JobApplicationFiles are required for an Applicant to apply.
• JobFile A job posting in PDF format. A background document. A white paper.
• JobFileCategory
• JobCategory
• JobMessages - A message to be sent via html and plain text multipart email to an applicant.
• JobMessageType - Defines a set of "triggers" and relates to a JobMessage. This would 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.
• JobApplication - Relates jobs and applicants.
• JobApplicationFile - A file submitted along with an JobApplicant by an Applicant. A customized CV, a letter of recommendation, a tarball of sample code, etc.
• JobApplicationFileCategory Categories could probably be a single polymorphic model using a tree model for organization.
• JobReference

In narrative -

• A User has many Jobs.
• A Job has many categorized JobFiles and is organized in (at least one) JobCategory. A Job also has JobApplicationFileRequirements.
• 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.
• An Applicant has many JobReferences. These JobReferences will have an email address, allowing the reference to authenticate and create a JobFile with a "letter of reference" category. We might consider relating this model to JobApplications - we haven't through it through yet.

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.

Wrapping Up

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!