[development] Very concerned over Drupal's core development

[Angela Byron]

On 20-Apr-09, at 11:35 AM, Nedjo Rogers wrote:

> <snip>
> c. The maintainers listed at
> http://cvs.drupal.org/viewvc.py/drupal/drupal/MAINTAINERS.txt?view=co
> are given permanent commit access to be used only in the areas they  
> are
> responsible for.

Let's examine the consequences of this, since it's always a popular  
option when it comes up. I'm going to choose the menu system as a  
random example, but you can easily substitute  'menu system' as  
$subsystem and 'chx and pwolanin' as $subsystem_maintainers in the  
following narrative.

The menu system is a bit tweaky and its innards not easily understood  
by the "common developer" in the Drupal community. As a result,  
patches that improve the menu system tend to languish in the queue in  
"code needs review" for weeks or months. When a review does happen,  
it's normally on more minor things like coding style or similar; not  
about the fundamental architecture of the menu system. This is  
extremely frustrating to chx and pwolanin, the menu system  
maintainers, since they want to keep going with their crazy  
development ideas and are blocked.

So, to resolve the issue of menu system patches languishing in the  
queue, chx and pwolanin are granted commit access to the menu system.  
Suddenly, all of our problems with languishing patches magically  
disappear! After a quick discussion in #drupal-dev, patch after patch  
that improves the menu system is committed. The menu system has never  
evolved so quickly in such a short period of time! And better still,  
the committers for the field API, the database system, actions/ 
triggers, etc. are all empowered to do so as well, so Drupal evolves  
at lightning speed! WIN!

Of course, without any kind of peer oversight, while these patches  
that get committed make perfect sense to chx and pwolanin, they  
completely mystify the "common developer." When Drupal 7 is released,  
it becomes painfully obvious that we've developed extremely well- 
engineered subsystems without ever exposing a "real" human developer  
to having to work with them. And since these patches only needed to  
make sense to two subsystem maintainers with intimate knowledge of the  
underlying subsystem already, documentation is extremely sparse. It's  
now way harder than ever before to jump in and get involved in core  
development.

Worse, because all of these subsystems were rapidly evolving within  
their own sphere, 20, 30, perhaps 50 patches committed per day, it's  
become impossible for anyone to oversee all of them; at best you have  
people inspecting one-off patches here and there. That means things  
like coding standards compliance, performance benchmarking, algorithm  
optimization, and the collective DX (not to mention UX) experience of  
Drupal 7 plummets. Drupal 7 is usable by chx, pwolanin, DamZ, catch,  
and about 20 other people, and everyone else switches to Django. ;)

We have this kind of decentralized development model, where one or two  
people are solely responsible for code with basically zero peer  
review. It's called contrib. And it's notoriously filled with sub- 
standard, shoddily documented code that needs to be closely inspected  
by individual site maintainers before being deployed on any serious  
production sites.

The entire strength of Drupal core *is* that it is peer reviewed  
(sometimes mercilessly so :)), it has oversight from others who are  
*not* deeply immersed in APIs who can give sanity checks, and has  
people who are bringing a very *diverse* range of experience levels,  
specializations, and use cases. You remove that, you remove what I  
would argue is the very heart and soul of Drupal.

"But webchick!" I hear you say. "Obviously, we wouldn't let these  
subsystem maintainers work /completely/ bereft of peer review. We'd  
surely have someone else check over their work." And I say, "Great!  
Then *why aren't these mythical someones doing this right now*?" and  
*then* you get at what I believe is the /actual/ root of the problem. ;)

*We need to grow the base of people who have understanding in these  
subsystems.*

People who consider themselves subsystem maintainers should be  
actively working to build teams around their subsystem of choice. They  
should be documenting how their underlying APIs work so that someone  
without familiarity could jump in and get oriented quickly. They  
should be recruiting from contrib authors who are doing interesting/ 
innovative work in their areas. They should be maintaining a "patch  
spotlight" page under http://drupal.org/community-initiatives/drupal-core 
  so that people who want to jump in and don't know where to start  
have a direction. They should be guiding and mentoring "younger"  
contributors on how to do patch reviews, and actively advocating for  
others to do so as well.

If subsystem maintainers do this, the collective IQ of the Drupal  
development community goes up, we grow the larger pool of  
contributors, and no patch gets left as code needs review. Then you  
can come back to me when the RTBC queue is 6 pages long (as opposed to  
cleared down to zero about once every couple of months as it has been)  
and say "webchick, we need subsystem maintainers to have commit  
rights, because these patches have all been thoroughly peer reviewed  
and are languishing at RTBC." and I will probably back you up 110%.

-Angie