[haiku-development] RFC: Idea for redefining our participation in Google Summer of Code
- From: Matt Madia <mattmadia@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 4 Jan 2010 14:16:00 -0500
Introduction:
Google Summer of Code 2010 is still some weeks away, but this idea is
a fundamental change in how the Haiku Project participates in GSoC.
The following idea will redefine our entire perspective on what to
achieve from Google Summer of Code, who can be assigned as Mentors,
and the overall structure of how our students interact with our
project at large. Because of this, I would appreciate feedback and
discussion, particularly whether or not the idea is indeed a path we
want to pursue.
History:
In the past years, we have selected the best student+project+mentor
combinations, hoping to gain a contributor and at the same time get
interesting work accomplished. This usually encouraged our most
skillful developers to pull double duty as both developer and private
mentor for several months. Sometimes, the return on investment was
indeed more than worthwhile; quality code being submitted and gaining
a regular contributor.
Idea explained:
Instead of placing an emphasis on the content of the project proposal
where a student's academic knowledge could be over-extended beyond
their limits, the project suggestions & proposals would become less
challenging tasks of work that needs to be done in the code base. This
reduction in academic challenge would allow the student to place their
energies on developing themselves as an effective and productive open
source contributor. My rationale and expectation is that students who
are successful in participating as a contributor will find the
motivation to further their skills and find open source participation
to be personally rewarding, particularly with Haiku.
Student & project selection:
The students would still be subject to Haiku's selection process for
determining the best of the best. However the topic of their project
proposal becomes secondary in nature. As long as the project consists
of work that is useful to Haiku directly or as a 3rd party
contribution (eg, software that runs on Haiku) and there is enough for
the length of the program, I would like to see it as a viable
proposal. One idea to be explored is a dynamic project proposal along
the lines of "Fix as many bugs/issues/open tickets as possible". To
note, even though documentation, translation, and other non-coding
tasks are indeed useful to the project, they should not be considered
-- IIRC there is even a Google policy about this, however I cannot
find a link at the moment.
Mentors:
In this proposal, the mentors would no longer be the end-all-be-all
for their student. The mentor should be able to balance answering a
student's questions directly and requiring the student to use the
appropriate forum -- a mailing list, trac, and so on to seek
additional information or code review. Essentially the mentor becomes
a parental figure responsible for their student's growth.
The above two concepts would lower the entry bar for a person to be a
primary or secondary mentor. By encouraging/requiring the students to
behave as any other contributor and seek information from the project
at large, the mentor would no longer need to be a specialist in that
particular field. This in turn, could free our best developers from
mentoring a single student and allow them to respond to any student in
the appropriate forum.
Evaluations:
By focusing on the growth of the student and requiring them to act as
any other contributor, there would be additional observable data that
can be used to measure their performance. This could help to further
objectify the process.
Examples of poor progress:
* providing meager patches and little to no public communications
with the project
* effectively communicating, but failing to produce code
--mmadia
Other related posts:
