Re: Developers, developers, developers

[Stephen J. Turnbull]

Tom writes:

 > Is there an uptodate list of small tasks which someone can
 > starts working on?

Uh-oh.  Wishful thinking alert, here!

This takes an amount of maintenance effort comparable to simply fixing
bugs yourself for many such tasks.  It also seems to require a culture
of mentorship to go with it, which Emacs doesn't yet have (at least
it's not visible on emacs-devel).  For the mentorship aspect, read on.

 > Keeping such a list increases the administration a bit, but
 > it would also be beneficial for offloading these tasks to
 > casual contributors.

I know of two projects (Python and Bazaar) that have effectively done
this kind of thing, and "a bit" is a huge underestimate of the time
that experienced developers need to provide.  Emacs might be somewhat
less, because Python has a fair amount of formal process and Bazaar's
process was extreme and a lot of the mentoring effort was helping the
newcomer get with the program.  Still, the pure developer mentoring
aspect is quite expensive.

I think both projects got ample return for the effort, but it was also
quite clear that there are two types of experienced developers: those
who enjoy personal benefits from being mentors, and those who don't.

 > E.g. someone says: "I have an hour of free time, I'll fix
 > something in emacs."

People just don't do that very often.  Itches and scratching, ya
know.  That kind of behavior is *much* more popular among core
developers than casual contributors.

 > and he goes to this list, picks a task, does it, sends the patch
 > and it can be crossed out.

But "pick" is a problem, and it makes time estimation difficult.  I've
often asked for people to deal with NEWS, and get no takers.  (It is
possible to require committers to write NEWS, as Emacs does.)  Tasks
like that are easy to estimate: just estimate how much time it would
take you to do it.  People mostly want to work on bugs or features and
develop their design and coding skills.  A few will work on tests
(more code!).  All of these may require far more time (and help) for
the newcomer than for an experienced developer.  And any code requires
review, especially from new contributors.  (Note that all review has a
mentoring component, of course, but review != mentoring by a long
shot.)  Usually some core contributor effort (in the form of applying
a patch to a workspace, committing, and pushing to the trunk) will be
required as well, until the "casual" contributor becomes a regular.

 > So the regular developers would regularly add these small
 > tasks to the list which could be done by the casual 
 > contributors, so it would free up core developers to work
 > on other, more demanding tasks.

In Python and Bazaar, it did *not* free up core developers.  What
actually happened with Bazaar was a few regular contributors were
recruited (but they bailed out too when Canonical started withdrawing
manpower).  With Python (and more recent experience) what is happening
is that GSoC wannabes are flocking to the mentorship program.  That
biases things in favor of code too (Google doesn't permit
documentation or even pure testing tasks in GSoC).

Net, it has balanced out for both.  The main benefit was a few new
regular contributors who might not have become regulars without
mentoring, as well as a general "newcomers welcome" atmosphere that I
believe attracted new developers with little-to-no need for mentoring.

 > It seems to me the little more administration which 
 > consists of adding these tasks to this list would
 > be worth it.

I think we've found your "little task"! ;-)  Seriously, it's worth
doing, but curating such a list is a specific task, it's not a good
one for distributed effort "a little by each core contributor."