Application Tracker: Difference between revisions
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!