Guidelines/Schedule for Mentoring Process

[Emmet Hikory]

Andres E. Rodriguez Lazo wrote:
> I've been discussing with Cesare Tirabassi the need of having a Schedule,
> Guidelines or a Tasks list for the Mentoring Process. By this I mean that
> the mentoring process should have a schedule, or guidelines, so that mentors
> and mentees can follow them, and set tasks for the mentees.

    I'm rather inclined to disagree with this.  I think having an
expected timeframe is better than an explicit schedule, as people come
from all sorts of backgrounds, and may progress at different rates in
different areas.  By encouraging everyone to complete a cycle within
some given number of months, each mentor/mentee pair can establish a
different, flexible, schedule to meet the requirements each has
towards progression.

    As each person involved in Ubuntu is encouraged to contribute in
the ways that they find interesting, I don't think a specific Task
List is necessarily appropriate.  If someone wants to work on
maintaining ubuntu-local packages and spends lots of time updating
things from UEHS, that person might not want to spend time working on
merges and syncs, and may find themselves working more with Debian QA
than with specific Debian maintainers.  If someone wants to track down
python crashes and fix them, pushing patches upstream, that is useful
in it's own right, but that person may not find it interesting to
track down FTBFS or unmetdeps.  More generally, for those gaining a
first introduction to Ubuntu Development community, it's more
important that they get to know those working in areas in which they
are interested and understand the basic mechanisms by which to get
their code into the repositories, rather than having hit some set of
"targets".  For those with experience in Ubuntu Development seeking
mentoring on joining MOTU, I think it's even more important not to
have a specific list, as the largest problem this class of people face
is the development of their own plan for improving Ubuntu themselves
(perhaps in concert with other teams), along with demonstration of
solving "hard" problems.  Note that any class of work may be "hard":
sometimes a bugfix, sometimes a merge, sometimes an upstream update,
sometimes package integration issues, but these are better generated
by the interest of the person doing them, rather than on some exterior
list that may not match that person's interests.

-- 
Emmet HIKORY