schedule - does it need updating?

[Karsten Wade]

I'm looking at the schedule ...

https://fedoraproject.org/wiki/Summer_Coding_2010_schedule

... and the relevant months:

      June 2010             July 2010            August 2010    
Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa  Su Mo Tu We Th Fr Sa
       1  2  3  4  5               1  2  3   1  2  3  4  5  6  7
 6  7  8  9 10 11 12   4  5  6  7  8  9 10   8  9 10 11 12 13 14
13 14 15 16 17 18 19  11 12 13 14 15 16 17  15 16 17 18 19 20 21
20 21 22 23 24 25 26  18 19 20 21 22 23 24  22 23 24 25 26 27 28
27 28 29 30           25 26 27 28 29 30 31  29 30 31            

Some facts:

* The accepted proposals were announced on Thursday 03 June, which is
  six (6) days late.

* The coding was supposed to start on 01 June.  The gap was mainly to
  make the scheduling come out evenly with one month before mid-term
  and one-month after mid-term.

* If students started working on their projects upon receiving work of
  the approval (which they should have done!), then that is only a
  loss of two (2) days from the actual work schedule.

So, people were asking about moving up the mid-term to reflect the
loss of time.  While it's true 6 days were lost from the schedule,
only 2 days of work were lost.

If we move up the mid-term by, for example, a full week to reflect the
6 days lost from the schedule, we would have to either cut the second
half short or move the closing of the program back by a week.

My current thinking is to do this instead:

* Make 05 July the FIRST, SOFT mid-term deadline, and mentors have until 12
  June to evaluate.

* Make 08 July the SECOND, HARD mid-term deadline - students who miss
  this one are cut from the program.

* In all cases, the mentors have until the original 12 July to
  evaluate student work.  If your student needs the three more days
  until 08 July for the mid-term deadline, you as the mentor still
  have to get your work in by 12 July.

* If any mentors are late with 12 July evaluation, that is not a fault
  of the student, as long as the student i) got their mid-term work in
  by the HARD deadline, and ii) the student has been communicating
  with the mentor so there are no surprises for the mentor.  If the
  mentor is late, the student is NOT cut from the project.

This idea causes the mentors to absorb the impact of our own mistake
in making the schedule start late.

The mid-term evaluation is *much* easier than the initial evaluation
of proposals.  In fact, most mentors should be able to approve or deny
by the mid-term based on the work done so far.  We gave the mentors a
week in the schedule just in case.  Now we can use part of that week
to make the schedule smooth.

Ideas?  Thoughts?  Opinions?  If you give a -1 (or no vote), please
explain why and provide an alternative suggestion.

- Karsten
-- 
name:  Karsten 'quaid' Wade, Sr. Community Gardener
team:                Red Hat Community Architecture 
uri:               http://TheOpenSourceWay.org/wiki
gpg:                                       AD0E0C41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/summer-coding-discuss/attachments/20100605/70536390/attachment.bin