TMF Application Specs

file:///music/calabashmusic com In my mind.mp3

Definitions and Introduction

This page covers specifications and tasks for the TMF Application launch (Nov 15).  Although the content of the forms are exteremely simluar to Quest Bridge and in fact, simplified, there are some signifigant workflow changes such as Nominations vs. reccomendations and Continued Eligibility Tracking.  Currently this document is in 1.0rc1 for the Application and Nomination sections, the other sections are still in alpha or not started.

Milestones 1.0rc1

TMF Application Specifications

The TMF Application will extend the QuestMatch feature set and schema with:

• Elimination / Modification of existing forms
• Customization of main form in a few instances depending on the type of scholarship applied for.
• New Workflow for reccommenders (nominators)
• New Searching / Filtering Criteria
• Continued Eligibility Forms for entering updated acedemic info on students

TMF Application Workflow beta

1. Admin creates Nominator account (op)
   1. Email to nominator
   2. Nominator logs in and creates nomination
      1. email to student , tmf, nominator
2. Student logs in to locker
3. Student clicks begin application
   1. Student reviews req. of Vista Scholarship and Scholars Scholarship, confirms pre-screening questions and chooses appropriate application - This is spec'd out below Note: Student can apply for Vista of Scholars, not both.
4. Student completes application
   1. email to tmf / student
   2. Submit Application checks that all sections/forms are complete and then sets an App Submitted" status and goes to static page (in drupal) which informs the student of what doucmentation they need to send it. 
5. TMF Officers log on, review applications for eligibility (manually) and put them either in "To review" group, "declined" or "follow-up" group
   1. If declined, email goes to student with sorry letter
   2. If it is a follow-up TMF will manually contact student to get the required documents
6. Readers log on and view lists of assigned students.  Students will be assigned to reviewers by county, but more complex rules / Overrides may be needed here. More Info in Reader Spec Below## Readers review apps and give a numerical score + comments 
7. Report is generated by region sorted by score.  Top applications are added to shortlist group for interviewing. (More below)
   1. +Somehow,+applications are assigned to interviewers (Interview groups are the same (Shasta, Modoc, etc) as reader groups, so the only thing that changes is "forward to interview" and "do not forward" dt)
   2. Interviewers log on, get their students, perform interview and give a Yea / Nay + comments
   3. SPO decides on final lot, if not select, so sorry letter needs to be printed and sent
8. Activation Process
   1. Selectee completes +activation forms (+this is exactly like the transcript requirement. Either they have their documents in or they don't.)
   2. If applicant does not submit forms by due date - How is this defined, Get's too bad so sad letter (due date will be August 1st each year, but the system doesn't have to do anything-again, this is a manual check done by me. If they don't have their documents in before I'm ready to disburse their first check, then they are sol-dt)
   3. Else goes to disbursement process
9. Disbursement Process
10. Continued Eligibility Tracking

TMF Application Changes 1.0

The College Match Application builds upon the Preapp application. It extends the data model by changing and adding to the model.

• Prescreen - New Form
  • This will be a series of check boxes with questions.  Nothing will get stored in the database, it is just a means to confirm that the student understands the requirements of the scholarship they are applyig for. Mockup: http://mcconnell-dev.civicactions.net/civicactions.net/sites/mcconnell-dev.civicactions.netmockups/preScreen.php - More updates coming, just new questions.   No big deal.
• Personal Information
  • Note: Birth Date field may be used to calc additional field (hidden) - age as of due date, or this may be calculated runtime in a filter
  • Added: County Select box on Perm. Add. and Mailing.  Pre-populated with "Modoc County","Shasta County, Redding area","Shasta County, outside of Redding area","Siskiyou County","Trinity County","Big Valley High School District in Lassen County","None of the above".  Also will have other option with write-in, can be stored in same field I think if easier
  • Changed: Label "Telephone at mailing addess" Telephone at current maling addess"
  • Removed: Country of Families Orgin
  • Removed: Where did you grow up
  • Changed: Label "Alt. Telephone" to "Mobile Telephone"
  • Changed: Ethnicity - Open ended text box
  • Moved+Changed: Number of years in U.S.  Changed to "Number of years in county of residence", move next to county field in mailing address
  • Removed: First Language
  • Changed: Year of HS grad, changed to Year of HS Graduation or GED.
  • Changed: Year of HS grad: add note: If homeschooled or other leave blank. - Make not required
• Additional Information
  • Changed entirely, see mockup at http://mcconnell-dev.civicactions.net/civicactions.net/sites/mcconnell-dev.civicactions.netmockups/additionalInformation.php(schweet!-dt)
• Educational Interests
  • Changed: Educational Interests Label: What is your intended major(s)  / Input: text field
  • Removed: Types of Colleges
  • Added: Colleges Applied to.  Each college applied to needs a text box of Institution name and a radio set (accepted, declined, pending).  5 fieldsets should be enough (again, for Vista this is an eligibility filter, so for the Vista application the only choices will be "I will be attending Shasta College this Fall", "I will be attending College of the Siskiyous this fall", or "I am a clueless nitwit who doesn't read directions"-d.t.)
• Extracurricular Information
  • Changed: Grade Level or Post Sec. to text box "no. of years involved"
  • Changed: Describe your.... 150wds limit
  • Removed: List and Describe your activities...
  • Removed: Hobbies
• Work Experience
  • Changed: Label on "list any job..." to "Please describe your work history" ("including volunteer or non-paid work." -dt)
  • Changed: "Specific nature of work" to "Describe your duties at this position" make 50wds limit
  • Added: Column "Position" before employer (text box)
  • Removed: Check if summer job
• Household Information
  • Just one long open ended text box, "Please describe your current living situation as well as your family background. For example, do you live with both/one/neither parent? You may include as much or as little detail as you want. 150 words maximum"
  • All sub pages except Household Income dropped
• Household Income
  • Changed: Completely.  see mockup at http://mcconnell-dev.civicactions.net/civicactions.net/sites/mcconnell-dev.civicactions.netmockups/income.php
  • Varies:
    • For Vista Scholars all fields - EFC not Required
    • For Scholars - just EFC, is required, no other fields
• School Information
  • Removed: All sub pages accept accedemic info and testing info
  • Note: we should save the transcript form though, it will be used for continued eligibility.  That is, it's not required to be submitted electronically (must be mailed) at application time, but studnets' grades will be updated every semester if they win the scholarship. More on this in Cont. Eligibility Spec
• Academic Information
  • Mostly Changed: see mockup at http://mcconnell-dev.civicactions.net/civicactions.net/sites/mcconnell-dev.civicactions.netmockups/acedemicInformation.php
• Testing
  • Added: PSAT (same fields as SAT)
• Essays
  • Changed:
    • For Both
      • "How do you spend a typical weekday evening?" (50wds)
      • "What things make you the happiest?" (50wds)
      • "What things make you the angriest?" (50wds)
      • "What qualities do you look for in friends?" (50wds)
      • "If you could change one thing about your community, what would it be and why?" (50wds)
    • For Vista Students:
      • "what in your life has encouraged you to attend college? what has discouraged you?" (150wds)
      • "Describe your academic and career goals. How did you choose them? Why are they important to you?" (150wds)
      • "What are some of the challenges you will face when attending college? How do you plan to deal with them?" (150wds)
      • "If you are awarded The McConnell Foundation Vista Scholarship, how will you use the money?" (150wds)
    • For Scholars:
      • "What are your academic and career goals? What do you need to do and learn to achieve them?" (500wds)
      • "Describe one of your significant challenges or accomplishments and its value to your life". (500wds)
• Recommendations (Removed Entirely)
• College Match Ranking (Removed Entirely)

Recommender Nominator Module Specifications  1.0

• Form will be different from current recommender form, but will be fairly simular in format.  Some fields will remain
• Nominators will be given accounts by TMF staff.  This can be done from the Drupal user create interface.
• Nominators will have to log-in and nominate students for the scholarship.  After doing this the following will happen:
  • Create drupal account for student, and email student a one-time password
  • Create ccrm contact for student as a "vista applicant" (however, the student would still need to fill out the pre-screen)
  • If student already exists - just don't create the drupal user/student contact again.
  • Note: Nominators can't edit nomination once submitted
  • Send email to nominator as a receipt
  • Send email to TMF staff
• Note: Independent students can also apply (without being nominated)
• Personal Information : Renamed to "Nominator Information"
  • Added: Student Name and email
  • Added: Gender / Address of Nominator
  • Added: "nominator position/title";
  • Added: "how long have you known this student?"
  • Changed: Legal Name, remove legal
  • Added: Work and Cell telephone lines
  • Changed: School Department to "Nominator's place of employment/business/volunteer service."
  • Changed: Relationship to Student  - "counselor" to "high school counselor," add "community college counselor";"academic advisor";"College OPTIONS advisor";"ETS advisor";"volunteer supervisor";"supervisor";"mentor"; "Other" (w/ txt box)
• Student Ranking - Renamed : Student Assessment
  • Note: The quantitative questions on this form will be changed...  Mockup pending
  • Removed: Years you've been a teacher
  • Removed: Subjects
  • Removed: Grades
  • Changed: Based on your experience as a teacher to "Based on your knowlege of this student..."
  • Changed: his or her entire class to "students of similar background"
  • Removed: I would reccomend this student
• Evaluation - Renamed: Written Asssessment
  • Removed: Everything
  • Added: Short Answer Essays
    • "How do you know this student? How long have you known him or her?" (50 words max)
    •  "What makes you believe this student qualifies for The McConnell Vista Scholarship? For example, does this student face hardships, unusual responsibilities, or impediments to success in school-are they in danger of 'falling through the cracks'?" (150 words max),
    • "Given the opportunity, could this student be successful in completing an AS, AA Transfer, or Certificate program at Shasta College or College of the Siskiyous? What evidence have you seen of this student's motivation and dertimination to succeed? What sets this student apart from others in similar situations?" (300 words max).
  • Added: Additional Information (From next section)
• Additional Information (removed)

Selection Spec beta

General

• Applications (students) will move through various "states" in the selection process.  These states are mutually exlusive and linear. Will store as custom field (Applicant Status) Is this true?**
  • In Progress (application not done yet)
  • Submitted
  • Ineligible - This is skipped for most applications, if an applicant doesn't qualify on a given filter, they are given this state and communicated with until eligible or deleted
    • Everytime the user updates their completed app (from the locker) - the state is reset to submitted.
  • Deleted / Rejected - These applicants should no longer have access to the locker and arenot even being considered.
  • Eligible - marked as such by SPO, previous state is submitted or ineligible
  • Reviewed (for those who pass the cutoff after readers)
  • Awarded (for those passing the cutoff after interviews)
  • Receipeint (for those who are awarded and complete all the paperwork, etc)

Eligibility

• SPOs will need to filter the list of canidates for eligibility.  Some of the filters are "hard" filters (such as ineligibility due to a student already having a BA), others are "soft" such as a felony conviction of a low GPA.  SPOs will filter from most restrictive to least, moving students to an inelligable list as they go.  David: Do we need to send correspondance to inelligible students?  (yes. email is ok.-dt)
• Most filters will be done when the user is filtering the application.  Filters should be built into the advanced search.
  • Filters Needed
    • Scholarship Type
    • GPA, <>
    • Felony Conviction, bool
    • County, Select (one or more counties or other)
    • Date of Birth, <>
    • EFC, <>
    • Program, checkbox (vista or scholars)
    • HighSchool Completion Status (highschool_years_id)

• Upon searching, the SPO will see the following fields in the selector: key: s = sortable
  • Scholarship (Vista / Scholars) -probably best to have an icon or something
  • Status - s (as in state of being, not member of the union)
  • Name
  • County - s
  • GPA - s
  • Age - s
  • EFC - s
  • Component-injected Action links are: View App (html preview) and Edit App

• The SPO will then need to be able to send emails to the students asking them to clarify parts of their application that may make them inelligable.  This can be done via smart groups and/or civimail / mail merge exports / ind. emails.
  • The students will then have to edit their application by the deadline.  There will be no editing by students after the deadline!  This means that this functionality has to happen soonest, so Dave can work out these kinks now.
• The SPO should have a quick task to change the eligibility (state) of multiple students at a time. (this will be done via batch profile)
• After a certain transitionary date ( about 2-3 days after the deadline), all students who are marked as ineligibile will be e-mailed rejection letters. This can be done via the api if necessary.

Readers

• A script written using the api will add eligible canidates to reader groups based on country.  These are just normal civicrm groups I believe.  From here on out, SPO can move students between groups, although we will need validation to ensure that a student only exists in one reader group at a time.  Because civicrm offers no heirarchy of group taxonomy, we need a solution here, ideas?** Details below:
  • Each reader group will have multiple readers who will each give scores and comments about students in that group.  These scores will be averaged and should be a sortable / filterable field in the selector.
  • Explanation of Reader Groups: There are some exceptions.  For one county there are too many students, so the applicant pool needs to be split into two groups of readers.  Because of this, it seems to make sence to create another layer of abstraction, so there are "reader groups" and there are counties.  Selecting a county automatically puts a student in that county's reader group, but students can be removed from reader groups and put into other reader's groups manually by staff (i.e. by city or by GPA).  This ability should be available from the advanced search / saved search interface.
    • Note: From David - If we are going to use this as a criteria to assign applicants to reading groups, those groups would break down like this: Big Valley and Modoc to Modoc readers, Shasta Redding to Redding readers, Shasta (not Redding), Siskiyou to Siskiyou Readers, and Trinity to Trinity Readers. Really, a little flexibility wouldn't hurt here in case I have to add more reading groups if the number of applications I get is much greater than I expected. Also, the preceding groups are strictly for the Scholars program. Vista has only two reading groups, "Shasta College" and Siskiyou College" since those are the only two colleges  you can go to and get the Vista scholarship.
  • Scholars / Vista : The preceeding really applies to Scholars.  Vista will have reader groups loosely based on region.  I don't think civicrm needs to worry about this however, as it will just look like seperate reader groups.    In thins stage no, but when it comes to shortlisting, it will come into play.

• Readers will be invited via drupal, and they will be assigned to reader groups automatically via the api.  In some cases, the SPO will need to re-assign them to other groups directly in civicrm.
• Upon logging in Readers will be presented with this in the locker (still up for debate, perhaps entire selector will be in locker) http://mcconnell-dev.civicactions.net/sites/mcconnell-dev.civicactions.net/mockups/reviewer_locker.png
  • IMPORTANT: Reviewing should be an anonymous process.  No identifying information should be shown to readers.
  • Readers will enter the system and should see no civicrm menu or options besides a selector containing the following fields:
    • Unique ID - the contact ID should do - better to have readable ID using scholarship type like VS-2007-00001, VS-2007-00002, etc.  I'm thinking ScholarshipType-Year-cid.  (autoincrement is fine, no need to have VS-01 and SC-01).
    • Reviewer score (this is the score (the sum of the 10 questions) they have already given this student, if it has been completed)
    • Link to scoring sheet http://mcconnell-dev.civicactions.net/sites/mcconnell-dev.civicactions.net/mockups/reviewer_scoring.php
      • Note that Vista and Scholars have different questions, so we will need to account for this
    • Link to Application (pdf)

• Readers will have the option of viewing the applications online (pdf format), or printing the entire batch of applications.  This should just be a link in the locker "print all applications"
• They will then score each student.
• After submitting, all scores are entered into the DB, and the total score gets saved to a field called "reader score".  See the fake datamodel at http://mcconnell-dev.civicactions.net/sites/mcconnell-dev.civicactions.net/mockups/reader_datamodel.png
• We should have some sort of "whine" alert for readers who haven't finished their batch when the deadline is approaching (this means a smart group of all readers who have applications they have not reviewed). Jacob will handle this by writing a SQL query.
  • If a reader does not complete all their applications we need to make sure the applications they didn't get to, don't end up being 0's in the average.

Shortlisting

• The SPO will then want to find the top n average total scores by county (scholars) or region (vista) & scholarship type (not reader group).  They can use the selector for that, with the following fields:
  • full name
  • average reader score (sortable)
• SPO will then grab the top n scores and put them in a "reviewed" state (using Batch Update via Profile)

Interviews

• Interviewers will not have accounts, they are off-line players only at the moment.

• SPO will print out batches of students' applications for the interviewers.  This should basically just be a "task", so SPOs can deside how they want to break up the interview groups arbitrarily - although it will almost certainly be by county / region.
• Interviews will happen in person and ranking will happen off-line
• SPO will log onto the system, and filter by county (one-at-a-time) of applications which were up for interview
• The batch profile / selector will contain the following:
  • Full name
  • Rank (this will be a dropdown box with numbers 1-20, within a given county, there is one #1, one #2, etc.  So this column is redundant across the DB, but is meaningful only in the context of counties, which is how they will be selecting awards anyway.
• After assigning the ranks, SPO will submit the data

Shortlisting (part deux)

• Here, the SPO will take the top n students from each county (like before, only this time based on the interviewer rank, not the avg. reader score).  These students will be given a new state (awarded).  * note that the other students should be somehow marked as rejected, and receive letters, however, the system should still have someway of finding them, because should one of the winners fail to meet later criteria, they will be awarded it in their place based on the rank.  So if there are 20 students interviewed in a given county and the award is for the top 5, but the 3rd student doesn't show up for orientation, the 6th student (who has already at this point been rejected, would be bumped up to state "awarded".

Activation

• From this point, there will be a series of activities with the students including letters of evidence , phone calls, meetings etc. before they qualify for disbursement
  • There needs to be a way for SPOs to get lists of students who have or have not completed certain activities.

disbursement alpha

Goals

• Allow SPOs to track interaction with Students to ensure the students have completed the necessary paperwork and meetings to be eligible.
• Track when awards were given and *possibly* calculate the amount of awards based on financial information
• Enter an award dispusement as an activity in ccrm
• Allow the SPO to enter in meta-data about a disbursement such as the check no, notes, etc.
• Future Goal: To use the students continued elibilitiy information (essentially grades), to determine disbursement eligibility. (not covered in this section)

Workflow

1. SPO contacts all students who have cleared the selection process and this activity should be logged for all students contacted
   1. Emails should be handled by civimail
   2. Paper letters will go out with mailing lables
   3. System should be able to also generate phone list (via export)
2. Students will be asked to provide various forms of documentation including:
   1. Transcripts
   2. Photo ID
   3. Letter of acceptance, contract, etc
3. Students are also required to attend a summer orientation, and possibly other events
4. All of the correspondance mentioned above should be tracked as activities and there needs to be some way to trac the state of students so SPOs know which activities they have not yet completed.
5. SPO will find students who have not completed various activities and will contact them through ccrm., process 2-5 repeats until student clears all the needed tasks. *Note: This could very well wrap into the continued eligibility tracking where students are required to submit grades every semester or quarter.
6. When the disbursement time comes, SPO will select one student at a time for disbursement.  This will be enetered in as an activity (I think) and the SPO will enter in the check no, amount, etc along with the description.
7. There probably should be a way to "close" the disbursement when the student had confirmed that they have cashed the check.

Current Needs

• A way to include arbitrary numbers of files in groups. TMF is going to drop a complicated grade entry form, instead just receiving paper transcripts from students and manually adjusting cumm GPA and units complete. These paper transcripts need to be scanned and attached to the students' records. Current solution is to create a custom field group called Transcripts and create n * semesters file fields like TranscriptFall07, TranscriptSpring07. This is not ideal for a couple reasons. If we wanted to query it down the road, we would not know which semester each file applies to without some string manipulation. Also, it makes it difficult to accommodate students on a trimester or quarterly system. The former is not a huge deal, but ideally, custom file fields would support multiple values. Again, not absolutely necessary, but would be a good addition to core IMHO.

• Create Custom Activity type (disbursement). When a student is approved for a scholarship, SPO will schedule the student's next couple disbursements.

• Create a few more student "states" : Pre Disbursement Check, Hold Placed, Cleared for Disbursement, Account Suspended, Account Closed/Withdrawal, Account Closed/Graduated.

• Make status visible on Contact overview

• Add group for Financial Aid Officers

• Define Relationships between Institutions, FAOs and Recipients.

Continued Eligibility alpha

Continued Eligibility

Transcript input form(s)

david : TODO, we need to make these forms  (okay. Let's talk about it-I want to make sure you get the info in the best format possible-dt)

Locker APIs

Student locker 

• Get application and application section's status.
  • getTaskStatus( $sourceID, $targetID, $taskID ); 
    // returns Not Started/In Progress/Completed, last updated date, URL to edit task, for task
• Get status on recommendations.
  • getRecommendationStatus( $sourceID );  
    // given a sourceID, returns an array of - display_name, contact_id, status for all recommendations that the student has requested 
• Get URL for print/view of completed application

Recommender locker 

• Get list of recommendations requested and status on each recommendation
  • getRecommenderStudentInfo( $sourceID )
    // returns a array of
    //   - display_name, school_name, contact_id, recommendar_status, recommender_url
    // for all students that he/she needs to write a recommendation for 

• Get URL for print/view of completed recommendation

Additional issues

• Establish game plan for segmenting (archiving/retaining?) prior years applicant data.