Update hackathon best practices with a timeline.

TrainingBestPractices.md

@@ -87,15 +87,30 @@ Instructors should describe what participants need to know or do in advance of t
 * Keep the program largely free of planned activities to give people time to develop code.
 * The hackathon should involve 7-10 days of focused coding.
   Five days is usually too short to make significant progress and more than ten days would be physically exhausting.
-* Start with everyone introducing themselves and what their goals are for the hackathon.
-  Identify experienced developers who can mentor others. This fosters more exchange among the participants by letting them know who to ask (other than the primary developers) in case of questions.
-* Provide a brief introduction to git, github, …, how to submit patches, and how the patch review process will work.
 * Identify key people who will be responsible for reviewing code and accepting pull requests
 * At random times during the hackathon, encourage participants to show images, movies, and other results that they have obtained using the functionality they just implemented.
 * Begin each day with a session in which each person has a few minutes to outline what they achieved the previous day and what they intend to work on that day. 
 * Produce a hackathon report describing the accomplishments of the hackathon. Each participant would contribute a “one pager” describing their activity and results.
-* OPTIMAL PRIMARY DEVELOPER/HACKER RATIO? ??? Optimal experienced: unexperienced hacker
-* Add minimum requirements. What level of coding ability and subject matter expertise should the participants have?
+
+
+### Specific activities, with days
+Every hackathon, and indeed every project that runs hackathons has their own style. What works and what doesn't depends on the concrete group of people, how well they know each other, and the prior knowledge of participants. 
+
+The following is a sample schedule for a 9-10 day hackathon that includes both experienced developers as well as people with little knowledge of either the code, or of how the project as a whole works. The overarching consideration in this schedule is to ensure that every participant is productive both with regard to their own goals, but also with regard to the project's goals as a whole. In the best of cases, inexperienced developers feel motivated and encouraged to contribute to the project following the hackathon. An important component of this goal is to ensure that participants form *personal* connections with developers, and that nobody "falls through the cracks".
+
+* *Day 1, morning:* Start with everyone introducing themselves and what their goals are for the hackathon.
+  Identify experienced developers who can mentor others. This fosters more exchange among the participants by letting them know who to ask (other than the primary developers) in case of questions.
+* *Day 1, afternoon:* Provide a brief introduction to git, github, …, how to submit patches, and how the patch review process will work.
+* *Day 2, morning:* For everyone other than principal developers, walk them through the process of creating a pull request using a concrete example (no opt outs even for those who know `git` already). Have ready a few categories of patches people can write, such as:
+  - Remove deprecated code or functions
+  - Write a test for the kind of model they want to run, or the kind of feature they want to implement; ensure that the output matches expectations
+  - Have a list of "starter projects" identified on github via tags.
+* *Day 2, afternoon:* Icebreaker or other activities that ensure *personal* connections between newcomers and experienced developers. This can mean that people sit in pairs for five minutes and talk about anything (with pen and paper). Prompts can be given. Then regroup and each person tells the group three things that they find most interesting/curious about the other person. Or it could be a game night, or group activities.
+* *Days 3, 6, last:* Remind everyone of the hackathon report during morning rounds.
+* *Day 3, before morning rounds:* Identify who has not submitted a pull request, assign a principal developer to make sure the participant does not fall through the cracks.
+* *Day 3, morning:* Have a "speed dating round" where each participant gets to talk for 5-10 minutes with one or two principal developers. The goal should be to make sure participants know how to break down their project into manageable tasks.
+* *Day 5, before morning rounds:* Principal developers get together to identify problematic cases, assign a principal developer to make sure the participant does not fall through the cracks.
+
 
 # Appendix