Application Tracker

From Berkman Klein Google Summer of Code Wiki
Revision as of 17:02, 27 March 2010 by Geeks (talk | contribs)
Jump to navigation Jump to search

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!