Application Tracker: Difference between revisions
BerkmanSysop (talk | contribs) (old project) |
|||
(4 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
{{Template:Oldproject}} | |||
Basic tool requirements: | Basic tool requirements: | ||
Line 21: | Line 23: | ||
*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 want this application to work perfectly on both Postgres and MySQL. | |||
We'd probably have these models, minimally: | We'd probably have these models, minimally: | ||
* User - has many | * '''User''' - has many Jobs. This keeps track of administrators. Ideally it'd be able to use pluggable authentication - specifically LDAP. | ||
* Applicant | * '''Applicant''' | ||
* JobApplicationStatus - | * '''JobApplicationStatus''' - A basic workflow allowing Users to accept, reject, and move JobApplications through a set of stages. . . | ||
* Job - A job, with file attachments. | * '''Job''' - A job, with file attachments. | ||
* JobFile | * '''JobApplicationFileRequirements''' - Allows a User to define what JobApplicationFiles are required for an Applicant to apply. | ||
* JobFileCategory | * '''JobFile''' A job posting in PDF format. A background document. A white paper. | ||
* JobCategory | * '''JobFileCategory''' | ||
* JobMessages | * '''JobCategory''' | ||
* JobMessageType | * '''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. | ||
* JobApplicationFile | * '''JobApplication''' - Relates jobs and applicants. | ||
* JobApplicationFileCategory | * '''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 - | In narrative - | ||
* A User has many Jobs. | * A User has many Jobs. | ||
* A Job has many categorized JobFiles and is organized in (at least one) JobCategory | * A Job has many categorized JobFiles and is organized in (at least one) JobCategory. A Job also has JobApplicationFileRequirements. | ||
* An Applicant has many JobApplications. | * An Applicant has many JobApplications. | ||
* A JobApplication has many categorized JobFiles | * A JobApplication has many categorized JobFiles | ||
* A Job has many JobMessages, invoked by the backend at various stages according to their JobMessageType. | * A Job has many JobMessages, invoked by the backend at various stages according to their JobMessageType. | ||
* A JobApplication has a JobApplicationStatus. | * 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: | And then we'd want a set of administrator-level tools to do things like: | ||
Line 52: | Line 59: | ||
interested in them, | interested in them, | ||
* Send custom messages to job applicants. | * 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'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. |
Latest revision as of 09:50, 18 March 2019
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!