Roman Prykhodchenko <rprikhodchenko@gmail.com> wrote:
> My students have to make their science projects during this
> half-year. I would like to involve some of them in PostgreSQL to
> give them an opportunity to work on a real project instead of
> writing their own equation solvers or any other useless apps.
>
> Here is my vision of such collaboration:
>
> - I ask students who would like to work on PostgreSQL project and
> we choose one
> - You select the supervisor for the student. The supervisor will
> be the student's "boss" and will give him tasks and help in
> solving complex problems.
> - The project should take student two-three months of time and you
> can decide can be developed by student during this term.
> - The student discusses tasks the supervisor and agrees them with
> me.
> - When the tasks are agreed the student begins working on them and
> writing his Project report.
> - During the term I coordinate the student and solve organization
> problems.
> - When the term is finished the student should complete all tasks,
> agreed on the beginning of the term and also the student should
> finish his Project report.
> - The student can continue working with you after the science
> project is finished, if he likes it.
Since I haven't seen a reply by anyone else, I'll point out that
right now the committers are at their most busy time of the year,
trying to wrap up the 9.1 release. I'll offer what advice I can;
someone else will probably flesh this out more later.
The usual way something like this is done is for the student to have
a mentor rather than a supervisor, and for the student to deal
directly with the PostgreSQL community through this list. The
student would be expected to discuss, perhaps at great length, what
was to be implemented and how it should be approached. The
community tends to operate by consensus.
When a first attempt at an implementation is presented, there is
usually significant input and the patch is usually returned for
revision, sometimes after another lengthy round of discussion on the
list. There is no guarantee of acceptance, although active
participation in the discussions and close attention to concerns and
suggestions helps considerably. Patches are not accepted without
corresponding updates to the documentation and the regression tests.
In the end it comes down to an evaluation, after seeing the patch,
of how beneficial the patch is balanced against the risks and costs,
including the cost of long term maintenance of the extra code.
That said, I'm sure it would be an educational experience for the
student, and likely to benefit the PostgreSQL community. The first
two hurdles, obviously, would be to pick a good project and find a
mentor. The project should be interesting to the student, within
their abilities, and seen as valuable to the community. The student
might want to review the TODO list and follow the PostgreSQL lists
for ideas. It would also be wise to follow the other links from the
Developers tab on the main PostgreSQL web page.
-Kevin