In context of the Campus Ambassador Program that is in place/being launched.

<http://blogs.gnome.org/bolsh/2011/05/31/effective-mentoring-programs/>

I’ve been thinking a lot recently about mentoring programs, what
works, what doesn’t, and what the minimum amount of effort needed to
bootstrap a program might be.

With the advent of Google Summer of Code and Google Code-In, more and
more projects are formalising mentoring and thinking about what
newcomers to the project might be able to do to learn the ropes and
integrate themselves into the community. These programs led to other
organised programs like GNOME’s Women Summer Outreach Program. Of
course, these initiatives weren’t the first to encourage good
mentoring, but they have helped make the idea of mentors taking new
developers under their wing much more widespread.

In addition to these scheduled and time-constrained programs, many
projects have more informal “always-on” mentoring programs – Drupal
Dojo and GNOME Love come to mind. Others save smaller easier tasks for
newcomers to cut their teeth on, like the “easy hacks” in LibreOffice.
Esther Schindler wrote a fantastic article a few years ago documenting
best and worst practices in mentoring among different projects.

Most mentoring programs I have seen and participated in don’t have a
very good success rate, though. In this article, I look at why that is
the case, and what can be put in place to increase the success rate
when recruiting new developers.

Why most mentoring fails

Graham Percival, a GNU/LilyPond developer, decided in 2008 to run an
experiment. At one point, Graham decided that he would quit the
project, but felt guilty about doing so in one go. So he  started the
“Great Documentation Project” to recruit a replacement documentation
team to follow on after his departure. He then spent 12 months doing
nothing but mentoring newcomers to get them involved in the project,
and documented his results. Over the course of a year, he estimates
that he spent around 800 hours mentoring newcomers to the project.

His conclusions? The net result for the project was somewhere between
600-900 hours of productivity, and at the end of the year, 0 new
documentation team members. In other words, Graham would have been
better off doing everything himself.

Graham found that “Only 1 in 4 developers was a net gain for the
project” – that is, for every 4 apprentices that Graham spent time
mentoring, only 1 hung around long enough for the project to recoup
the time investment he put into mentoring. A further 1 in 4 were
neither gain or loss – their contribution roughly equalled the mentor
time that they took up. And the remainder were a net loss for the
project, with much more time spent mentoring than the results could
justify.

The GNOME Women’s Summer Outreach Program in 2006 had 6 participants.
In 2009, the GNOME Journal ran a “Where are they now?” follow-up
article. Of the 6 original participants, only one is still involved in
free software, and none are involved in GNOME. Murray Stokely did a
follow-up in 2008 to track the 57 alumni of Summer of Code who had
worked on FreeBSD. Of these, 10 students went on to get full commit
access, and a further 4 students were still contributing to FreeBSD or
OpenBSD after the project. Obey Arthur Liu also did a review of Debian
participants in 2008. Of 11 students from 2008 who had no previous
Debian developer experience, he found that 4 remained active in the
project one year later.

From my own experience as a replacement mentor and administrator in
the Summer of Code for the GIMP in 2006, we had 6 projects, most of
which were considered a success by the end of the summer, yet of the
participating students, none have made any meaningful contribution to
the GIMP since.

I feel safe in saying that the majority of mentoring projects fail –
and Graham’s 1 in 4 sounds about right as an overall average
success/failure rate. This begs the question: why?

Most mentored projects take too long

What might take a mentor a couple of hours working on his own could
well take an apprentice several days or weeks. All of the experience
that allows you to hit the ground running isn’t there. The most
important part of the mentoring experience is getting the student to
the point where he can start working on the problem. To help address
this point, many projects now require Summer of Code applicants to
compile the project and propose a trivial patch before they are
accepted for the program, but understanding the architecture of a
project and reading enough code to get a handle on coding conventions
will take time. It will also take mentor time. It takes longer to
teach a newcomer to your project than to do the work yourself, as
anyone who has ever had a Summer intern will attest.

When you set a trainee task which you estimate to be about 4 hours
work, that will end up costing a few weeks of volunteer effort for
your apprentice, and 8 to 10 hours mentoring time for you during that
time. Obviously, this is a big investment on both sides, and can lead
to the apprentice giving up, or the mentor running out of patience. I
remember in the first year of Summer of Code, projects were taking
features off their wishlists that had not been touched for years, and
expecting students new to the project to come in and work full time
implementing them perfectly over the course of 12 weeks. The reality
that first year was that most of the time was spent getting a working
environment set up, and getting started on their task.

Mentoring demands a lot of mentors

As a free software developer, you might not have a lot of time to work
on your project. Josh Berkus, quoted in Schindler’s article, says
“being a good mentor requires a lot of time, frequently more time than
it would take you to do the development yourself”.  According to the
Google Summer of Code FAQ, “5 hours a week is a reasonable estimate”
for the amount of time you would need to dedicate to mentoring.
Federico Mena Quintero suggests that you will need to set aside
“between 30 and 60 minutes a day“.

When you only have 10 hours a week to contribute to a project, giving
up half of it to help someone else is a lot. It is easy to see how
working on code can get a higher priority than checking in with your
apprentice to make sure everything is on track.

Communication issues

More mentoring projects fail for lack of communication than for any
other reason.

Apprentices may expect their mentors to check in on them, while
mentors expect apprentices to ask questions if they have any. Perhaps
newcomers to the project are not used to working on mailing lists, or
are afraid of asking stupid questions, preferring to read lots of
documentation or search Google for answers. In the absence of clear
guidelines on when and how parties will talk to each other,
communication will tend towards “not enough” rather than “too much”.

No follow through

Many mentoring programs stop when your first task is complete. The
relationship between the mentor and the apprentice lasts until the end
of the task, and then either the apprentice goes off and starts a new
task, with a new mentor, or that is the end of their relationship with
the project. I would be really interested to hear how many Summer of
Code mentors maintained a relationship with their students after the
end of the Summer, and helped them out with further projects. I
suspect that many mentors invest a lot of time during the program, and
then spend most of their time catching up with what they wanted to do.

Project culture

In her OSCON keynote in 2009, Skud talked about the creation of a
welcoming and diverse community as a prerequisite for recruiting new
developers. Sometimes, your project culture just doesn’t match
newcomers to the project. If this happens regularly, then perhaps the
project’s leaders need to work on changing the culture, but this is
easier said than done. As Chris di Bona says in this video, “the
brutality of open source is such that people will learn to work with
others, or they will fail”. While many think that this kind of
trial-by-fire is fine, the will not be the environment for everyone.
It is really up to each project and its leaders to decide how “brutal”
or forgiving they want to be. There is a trade-off: investing time in
apprentices who will contribute little is a waste of time, but being
too dismissive of a potential new developer could cost your project in
the long run.

Mentoring best practices

Is all the effort worth it? If mentoring programs are so much hassle,
why go to the bother?

Mentoring programs are needed to ensure that your project is long-term
sustainable. As Graham says in his presentation: “Core developers do
most of the work. Losing core developers is bad. Projects will lose
core developers.” Do you need any other reason to start actively
recruiting new blood?

There are a few simple things that you can put in place to give your
mentoring program a better chance of success.

Small tasks

Mentored tasks should be small, bite-sized, and allow the apprentice
to succeed or fail fast. This has a number of advantages: The
apprentice who won’t stick around, or who will accomplish nothing, has
not wasted a lot of your mentor’s time. The apprentice who will stay
around gets a quick win, gets his name in the ChangeLog, and gains
assurance in his ability to contribute. And the quick feedback loop is
incredibly rewarding for the mentor, who sees his apprentice attack
new tasks and increase his productivity in short order. Graham implies
that a 10 minute task is the right size, with the expectation that the
apprentice might take 1 hour to accomplish the task.

A ten minute task might even take longer to identify and list than it
would to do. You can consider this cost the boot-strapping cost of the
mentoring program. Some tasks that are well suited to this might
include:

Write user documentation for 1 feature
Get the source code, compile it, remove a compiler warning, and submit a patch
Critique 1 unreviewed patch in Bugzilla
Fix a trivial bug (a one line/local change)
Of course, the types of tasks on your list will change from one
project to the next.

Mentoring is management

Just as not everyone is suited to being a manager, not everyone is
suited to being a mentor. The skills needed to be a good mentor are
also those of a good manager – keeping track of someone else’s
activity while making them feel responsible for what they’re working
on, communicating well and frequently, and reading between the lines
to diagnose problems before it’s too late to do anything about them.

When you think of it in this way, there is an opportunity for
developers who would like to gain management experience to do so as a
mentor in a free software project. Continually recruiting mentors is
just as important as recruiting developers. Since mentoring takes a
lot of time, it’s important that mentors get time off and new mentors
are coming in in their place.

Pair apprentices with mentors, not tasks

An apprentice should have the same mentor from the day he enters the
mentoring program until he no longer needs or wants the help. The
relationship will ideally continue until the apprentice has himself
become a mentor. Free software communities are built on relationships,
and the key point to a mentoring program is to help the creation of a
new relationship. Mentoring relationships can be limited in time also,
6 months or a year seem like good time limits. The time needed to
mentor will, hopefully, go down over this period.

Regular meeting times

Mentors and apprentices should ensure that there is a time on their
calendar for a “one on one” at regular times. How regularly will
depend on the tasks, and the amount of time you can spend on it.
Weekly, fortnightly or monthly are all reasonable in different
situations. This meeting should be independent of any other
communication you have with the person – it is too easy for the
general business of a project to swallow up a newbie and prevent their
voice from being heard. Rands said it well when he said “this chatter
will bury the individual voice unless someone pays attention.”

Convert apprentices into mentors

Never do you understand the pain of the initial learning curve better
than when you have just gone through it. The people best suited to
helping out newcomers to the project are those who have just come
through the mentoring program themselves.

This is a phenomenon that I have seen in the Summer of Code. Those
students who succeed and stay with the project are often eager to
become mentors the following year. And they will, in general, be among
the best mentors in the project.

Keep track

For all involved, it’s useful to have some idea of the issues
newcomers have – ensure that documenting solutions is part of what you
ask. It’s also useful to know how successful your mentoring program
is. Can you do better than the 1 in 4 success rate of LilyPond?
Keeping track of successes and failures encourages new mentors, and
gives you data to address any problems you run into.

Manage the mentors

All of this work has overhead. In a small project with 1 or 2 core
developers, it’s easy enough to have each core developer take an
apprentice under their wing, and co-ordinate on the mailing list. In
bigger projects, keeping track of who is a mentor, and who is
mentoring who, and inviting new mentors, and ensuring that no-one
falls through the cracks when a mentor gets too busy, is a job of
itself. If your mentoring program goes beyond more than ~5 mentors or
so, you might want to consider nominating someone to lead the program
(or see who steps up to do the job). This is the idea behind the
Summer of Code administrator, and it’s a good one.

Go forth and multiply

Developer attrition is a problem in open source, and recruitment and
training of new developers is the only solution. Any project which is
not bringing new developers up to positions where they can take over
maintainership is doomed to failure. A good mentoring program,
however, with a retention rate around 25%, organised continuously,
should ensure that your project continues to grow and attract new
developers.

Replenishing your stock of mentor tasks and recruiting new mentors
will take effort, and continual maintenance of someone putting in a
few hours a week. If you execute well, then you will have helped
contribute to the long term diversity and health of your project.

--
sankarshan mukhopadhyay
<http://sankarshan.randomink.org/blog>

_______________________________________________
Wikimedia-IN-PUN mailing list
Wikimedia-IN-PUN@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikimedia-in-pun