Application Tracker: Difference between revisions

From Berkman Klein Google Summer of Code Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 21: Line 21:
*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
*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.
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!
Your ideas are GREATLY appreciated!

Revision as of 18:02, 27 March 2010

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!