Hi all,
There are some veteran LyX developers who are not sure if they can/want to
become a mentor or not.
There is a short manual online:
http://en.flossmanuals.net/GSoCMentoring/what-makes-a-good-mentor/
If you think that being a mentor appeals to you, then these are in my
opinion the tasks that are important to make the project a success:
(1) Selection of good students. This is maybe the most important factor,
but also the most difficult one, as it can be difficult to evaluate a
student based on a proposal alone (and on communication with developers).
We are basically looking for two things: The ability to write working code,
and the ability to organize one's time and work to achieve the goals. The
former can be evaluated if a student can already fix bugs, or show his or
her coding abilities in other ways, during the proposal time. The latter is
harder to evaluate; I've seen talented students who need constant reminders
to get to work, and that can be very tedious for a mentor after a while. I
think a good sign is if the student breaks up the projects into reasonable
milestones (also see below).
(2) Define clear goals. Especially in the early phase of the project, there
should be a couple of "bite-sized" milestones that can be completed in a
couple of days. If the student is accepted but fails to reach these early
goals, then this gives us a chance to pull the emergency break (unless
there is a good reason such as a real unanticipated problem towards
reaching a goal). It's better to be strict at the beginning rather than
dragging out a project making no progress.
(3) Once a project starts, make sure you stay in touch frequently (ideally
daily) and review each commit early. I would strongly encourage students to
commit as often as possible (on their own branch or repository, of course).
This way, it is much easier to review and debug changes. It also makes it
easier to make the code conform to existing coding styles/guidelines.
Be polite but firm if a student starts to communicate or commit
infrequently. If we interact only once or twice a week, then it becomes
extremely hard to track and steer progress. I would consider this a
dangerous sign, and unless the contributions are otherwise of high quality
(which can be the case for talented students), it can be a reason for
failing a student.
A successful project requires both regular communication and code commits.
If a student keeps describing problems he or she worked on, without
delivering code, then this is no better than not communicating. So I would,
in the first month or so, absolutely insist on daily commits/pushes and
reports, until things are on a stable track. (In my opinion, commits should
be as frequent as possible, even for fixing a typo or adding a few
comments. So for a sequence of incremental changes/fixes, it's good to
commit several times per hour.)
(4) For bigger milestones, define testable goals if possible. This may be
not so easy for a user interface, but for many parts of the code, an
automated regression test can give a clearly measurable goal. This is
especially important when it comes to passing/failing a student. Agree on
some minimal goals for each major milestone (a week before the evaluation
deadline), and use that goal as a guide for passing/failing a student.
(5) Time commitment. This depends on the abilities of the student, and also
on the time zone difference (there is less you can do if the student is
eight hours away). Early on in the project, one hour per day or even more
is common, so make sure you have enough time to mentor a student if you are
the primary mentor of a project.
--
Regards,
Cyrille Artho - http://artho.com/
Critical mass: a condition of the software such that fixing one
bug introduces one plus epsilon bugs.
-- The New Hacker's Dictionary
