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