Experiences with the new MOTU Mentoring process

Emmet Hikory emmet.hikory at gmail.com
Tue Jul 10 14:39:51 BST 2007

On 7/10/07, Daniel Holbach <daniel.holbach at ubuntu.com> wrote:
> I'd like to stir up some discussion regarding the new MOTU Mentoring
> process. It's in place now for 6 weeks and I made some observations
> which I'd like to share:
> Bad
>       * avoidance of official processes
>       * abuse of mentors as personal reviewers

        * contributors looking to individuals rather than teams for assistance

> One possible outcome could be to just use the mentoring for:
>       * making the new contributor feel comfortable using the proper
>         mailing lists, IRC channels and wiki pages
>       * run the new contributor through one review process
>       * explain processes like sponsorship process etc

    I believe significantly more robust mentoring also has value.  My
personal technique to avoid some of the bad items is to avoid doing
things that don't follow the processes (e.g. "Attach the debdiff to
the bug, and subscribe the sponsors.  If it's not already uploaded by
the time I next review the queue, I'll take a look").  On the other
hand, I've found that sometimes a new contributor attempts to bite
more than they can chew, and I'm not sure that mentors shouldn't be
available to help provide guidance on how to get more help (e.g. "You
might check with this person about that", "Have you tried looking
here", or even "That's a little tricky.  Why don't you build a simpler
test case, and see if you can fix that first,").  Statements like
these shouldn't take much time, but can be a great help in becoming
familiar with resources and processes with which the contributor is
not yet familiar.

    On the other hand, I agree that mentors should not 1) be
responsible for reviewing all of the mentees work (otherwise, the
mentee will never have enough recommendations to apply for MOTU), 2)
be responsible for helping the mentee with patches or code (not to
stop people from giving solutions or help if they want, but the goal
is for the mentee to learn), or 3) act as a dedicated contact point
for the mentee - community involvement is important.

> I think the best use of our time is to
>       * base the sponsorship and review on as many shoulders as
>         possible
>       * make http://wiki.ubuntu.com/SponsorshipProcess and make
>         http://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews healthy and
>         robust processes
>       * improve documentation with every question we get asked by new
>         contributors - maybe even ask to help with that task

    These are all excellent targets and goals, although I've found
that most of the answers I provide for the third are either already in
the wiki, and that new contributors may need much more help with
drafting documentation than with bug management and patching, as they
have not yet internalised the processes, and are often focusing on
learning to package.


More information about the Ubuntu-motu-mentors mailing list