TMF Selection Phase - Work Estimate

This is an estimate of work for the Selection Phase based on the Specifications with revision date of Jan 19.

Summary Estimate of CiviCRM Work

• Time spent as of 1/31: 2 days (Sr), 3 days (Jr)
• Est for reamining CiviCRM tasks: 1 day (Sr) 3 days (Jr)
• Allowance for spec additions, debugging...: 1 day (Sr), 1 day (Jr)
  Total Est: 4 days (Sr) + 7 days (Jr) = 11 days

Details

Specifications and Eligibility - 5 days

• Detailed specs for engineers
• Schema modifications
• Implementing component search functionality for TMF component including ability to inject TMF filter fields, birth date, and county into profiles for search listings and for batch update via profile.

Readers - 2 days

Assignment of applications to readers

• Students will be manually assigned to (static) "Reader" groups (Reader Group 1, 2 etc.)
• A custom field - "Reader's Group" will be created (type = INT, select) which stores the ID of the group that a reader is responsible for.
• Jacob/CA will use existing CiviCRM APIs to create a "selector" in the locker module which queries the logged in readers Group and uses that to return a listing of the students they are responsible for.
  (CiviCRM time est: 0 days. All tasks for this item are handled by CA.)

Reader Review

• • The reader "selector" will be coded in the locker by CA. CA will enhance the TMF API's as needed to retrieve the readers' student records, current score and generate links to review the anonymized application and to access the reader scoring form.

• reader scoring form and processing
  (CiviCRM time est: 2 days)

Shortlisting - 0 days

• Can use existing Profile Search Views (component assigns Avg Score as profile eligible)

Interviews - 1 day

NOTE: CA will need 2 days to create the templates and PDFLib blocks. PDFLib is commercial software and a license purchase is required (~ $ 2,000)

JS: Is this really needed?  There are lots of free pdf generation tools out there such as http://www.fpdf.org/.  Can we avoid this expense?  do you feel like it's not worth it, or not possible?  Also, do we need PDF versions?  Can't we just print from the "view application" report? 

DGG: If printing the HTML "view" is sufficient - then PDFLib is not needed. If you want a batch job to print a "set" of html apps, that will need to be coded probably as a command-line script.

• Creation of PDF version of applications - 1 day
  • JS: This can be updated if we aren't using pdf, yes?
• Based on partially complete spec, we recommend handling interview flow manually (using printed PDF applications). (no coding required)
• Ranking assignment can be done using Profile Search Views. (no coding required)

JS: Other notes:

• How do you plan on handling student "state"? somehow, we will need to be able to store the qualified students in a group which can be used to begin the disbursement process.
  • DGG: With Quest, we used a multiple-choice custom field that supported the range of states (Not Reviewed, Eligible, Ineligible, Finalist, etc.) - and then they created Smart Groups for each state.
    • JS: Cool, I think that will work.  btw, any plan on annual data archiving?

• What Drupal development do you anticipate?  Anything beyond reader / interviewer account creation and the locker?  In terms of reader / interviewer creation, can this be done just by using the API to put a user in the sub_type 'reader' and set their reader group based on the county they select upon registration?  Can we get a list of the county options from the API to give the reader a chance to choose when signing up? 
  • DGG: Actually, I would assume that the reader and interviewer accounts would be created by the SPO via Drupal Admin. We can include county in the profile for user creation and the appropriate role would be assigned. We probably don't need contact sub_types for these folks - but you could use the contact API to set it. I don't see any other Drupal dev for this flow - based on my current understanding of the requirements.
    • JS: I'm planning to use the invite module like I did for nominators.  I'll think about this and try to define the user interaction in a little more detail on the spec for my own estimate and your aggreement.