|
⇤ ← Revision 1 as of 2012-04-17 11:40:50
Size: 624
Comment:
|
Size: 614
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #pragma page-filename DEV/versions/13304162 This page is for capturing ideas of things that might be worth doing in future summer of code years. |
#pragma page-filename DEV/versions/13304164 This page is for capturing ideas that might be worth doing in future summer of code years. |
This page is for capturing ideas that might be worth doing in future summer of code years.
- Encourage students to look at the PEP templates to help them write stronger proposals
- Be significantly more detailed in our list of suggested projects
- Include desired skills and level of ability
- Include pointers to relevant documentation (if there is any)
Comments
Re: weekly timeline
As a template? I like that (and it may as well include the "hard" deadlines imposed by GSoC itself).
Re: expected times for code reviews/integration
I would say, in the instructions remind the students that they should include these. Figuring out where they go and how much time they take is the kind of experience GSoC should provide IMHO. More work for reviewers and mentors, yes, but this is the kind of thing that's hard to teach in a class (not impossible, but requiring enough effort on the part of the teacher that few do it in my experience in the U.S. and in Japan).
Re: Be significantly more detailed in our list of suggested projects
I think this is not easy. The kinds of specification you mention are (again) the kind of thing that the students should be learning to develop for themselves. Also, if we already know all that much about it, a core developer probably is already working on it. This may tend to inhibit student originality. Of course, this is basically a matter of how to balance various considerations. My bottom line is we should be conscious of the tradeoffs as we make them.