[drupal-devel] more core comitters

[Nedjo Rogers]

[See bottom of this email for two concrete proposals.]

Gerhard:
>>> I said this before and I'll say it again: the problem is not the
>>> committing but the reviewing.
>>
>> No, one affects the other.

Absolutely.

The issue of bottlenecks and problems with the code review and committing
has been brought up repeatedly, there have been many good suggestions, but
no significant changes have been made--and so the problem remains.

After so many months of hearing it, the "everyone should just review more"
pat response is beginning to sound like a mantra. Yes, it's a truism that
more and better testing and reviewing by qualified developers is the key.
But the question is, what steps are we going to take to bring that about?
Aside from this mantra, which, I think it's obvious, does nothing to address
the cause of the problem.

Dries:

> I guess I "waste"  at least 2 hours of my time a day [testing and
reviewing]

Why?  Is it unrelated to the fact that that Dries (a) has a recognized role
and position, (b) has a direct decision making role, and so knows his work
will be used and not wasted?

When we call for more core committers, we're not saying we need more people
who can press a button when everything is all ready.  We're saying, rather -
or I am, anyway, as I have repeatedly over the past couple of years, but to
no avail - that we need to bring more people into formal, recognized
decision-making roles.

Where are all these highly skilled, dedicated reviewers supposed to come
from?  The motivation to commit time and energy doesn't come from nowhere.
It certainly doesn't come from the experience of investing gobs of time and
energy only to have it sit there forever in limbo.  That's what I hear
Gerhard saying--and he couldn't be more correct.

This sort of dedication comes, rather, from a feeling of recognition,
membership, involvement, and a direct role in decision making.

Dries:
> Steven only started to commit "independently" one year ago

And what is the result of that experience?  Is it better to have two
"independent" committers than only one?  Is there any reason to think that
more wouldn't be a further improvement?

I hear, repeadedly, concern from the project owners and some others about
the drastic risks of opening up decision making.  While understandable, I
think this fear is pretty well entirely unfounded.  My experience from
another open source project I'm involved with (Mapbuilder, like Drupal
founded by an individual who did much of the initial coding himself) is that
bringing in more people as members and decision makers can be energizing and
a great way to encourage involvement and draw on expertise.  New committers
have always been respectful and productive.  Some, encouraged by their
reception and finding a place in the project, go on to become major
developers.  In this case, quality comes from openness, involvement, and
consultation, as opposed to strict central control.

Here are two concrete steps that could actually address this ongoing issue
and greatly strengthen the Drupal project rather than, once again, doing
nothing and hoping the issue (and those raising it?) will go away.

1. Create a new group of "committers", with defined responsibilities,
accountable to the owners.  Around 4 or 5 initially would be a good number.
This is a common role in open source projects.

2. Implement the issue status options I coded for the Project module, or
some subset of them, providing a more nuanced process for designating the
review status of issues.  I provided with the module a default set of status
options based on the long discussions we'd had and designed for use on
drupal.org.  While the patch has been accepted, we've not yet seen any
changes on drupal.org.