[haiku-development] Re: RFC: Idea for redefining our participation in Google Summer of Code
- From: PulkoMandy <pulkomandy@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 04 Jan 2010 20:57:37 +0100
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.
Yes, it's called summer of _code_.
I don't think the "fix as many bug as possible" project is a great idea :
- It is difficult to evaluate. If I fix only one bug but spend the whole
summer doing it, is that ok ? If I just close tickets because they are out
of date, I can handle a lot of tickets but write very little code.
- It is also not quite the way Haiku developpers work. Each of us usually
has some competence field and focus on more or less big projects. It's
also more interesting that way : working on the locale kit forced me to
touch various parts of the system ranging from jam rules to building a GUI
preflet. If you allow the student to keep doing what he knows best, he
will not learn anything, and probably leave the project, because
contributing that way is not that much interesting.
I think we have to think of Summer of Code as an internship. When a
student do an internship in some random company, he has a contract stating
its goal, evaluations, a mentor, and all that stuff. Working for Haiku is
of course way more fun, but when you're doing the summer of Code it's
still paid work. So as a student, one have to work seriously, with set
deadlines and objectives.
I'm all for getting the students to stay, but we still need some project
to be set before the program starts. It helps the selection process :
- Seeing how the student worked to get his proposal done let you see if he
wants to integrate the community : did he work alone on the GSoC webapp,
or did he ask for help on the ml or IRC ?
- Seeing if he is able to set deadlines and objectives : to do it properly
you have to ask the devs what work they think is involved, and what time
it will take
- seeing if he is able to make technical choices and decisions : we can't
ask the student to have all the design choices before GSoC starts, but he
should come up with a list of possible alternatives for getting a task
done. For example in my locale kit work, the alternatives were using ICU
or doing everything from scratch.
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.
I'm all for it on this side. Now that we have a dedicated svn server, it
may be interesting to have the student get immediate commit access to a
"gsoc" branch where code review could occur before merging to the trunk.
This is currently done through a special mailing list with only student
and mentors inside, which is quite a way to set students apart from the
community. It's made to make the code review go faster, but I don't think
it helps integrating people.
Also, due to the big changes ICU and localization involved, I was working
in an svn branch for the whole SoC last year. While it is the usual way of
doing things in Haiku (branching if the project involves breaking a lot of
things), it may not be a really good idea for GSoC. The code gets less
exposure, and basically I worked alone on it, besides peer review on
commits. There was no testing and a lack of integration in the other parts
of the system. I'm now still the only person to ask when there is a
localisation question. So it's not only about me getting integrated in the
Haiku community, but also ensuring the Haiku codebase integrates my
changes.
--
Adrien Destugues / PulkoMandy
http://pulkomandy.ath.cx
Other related posts:
