[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.