Application Tracker: Difference between revisions

From Berkman Klein Google Summer of Code Wiki
Jump to navigation Jump to search
(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===
==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 jobs, the administrators.
* '''User''' - has many Jobs. This keeps track of administrators. Ideally it'd be able to use pluggable authentication - specifically LDAP.
* Applicant
* '''Applicant'''
* JobApplicationStatus - a basic workflow allowing to accept, reject, and move JobApplications through a set of stages. . .
* '''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 (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.)
* '''JobMessages''' - A message to be sent via html and plain text multipart email to an applicant.
* JobApplications (relates jobs and applicants)
* '''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 (categories could probably be a single polymorphic model)
* '''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

This page is for an old project that is not be part of Google Summer of Code currently. If you are a student looking for projects to get involved with we suggest you check out the projects linked to from the main page of this wiki.

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!