[development] Time to take away RTBC from every Joe

[Angela Byron]

James Walker wrote:
> On 21-Feb-08, at 7:57 AM, Moshe Weitzman wrote:
>> FYI, what Karoly proposes  is exactly how the Mozilla project works.
>> Each patch needs a "super review" from a fixed (but large) list of
>> reveiwers. See http://www.mozilla.org/hacking/
> 
> Those who have bothered to stick around and listen long enough while I 
> ramble will know that I'm actually in favor of this kind of approach. I 
> think it has several benefits :
> 
> * Clear responsibility - in case of questions, complications, etc - the 
> "buck stops" at a defined point for resolution.
> 
> * Allows for "domain experts" - very frequently patches come in that can 
> have tricky, subtle implications for some of the more complicated 
> systems (menu, formapi, search etc etc etc) and it's *really* hard 
> (frankly too much to ask) for the few core committers to have 
> comprehensive understanding of all of Drupal at this level.

But we already have this, albeit more informally:
- OpenID patches don't get committed until you've looked them over.
- Actions patches don't get committed until John VanDyk has chimed in.
- chx or pwolanin need to look at menu system patches.
- Jeff Eaton or chx need to approve FAPI patches.
- Barry or Frando need to thumbs-up Schema API changes.
- merlinofchaos and dvessel are in charge of theming-related changes.
- quicksketch is the Drupal JS master.

And so on. MAINTAINERS.txt /already/ means something.

The vast majority of patches, however, are not directly related to these 
types of low-level changes that require specific domain knowledge; 
they're string fixes, or usability improvements, or logic fixes, or 
simple new features, and so on. Being able to rely the "wisdom of 
crowds" in the larger community to handle tasks like reviewing patches 
and changing issue statuses is a /good/ thing.

Further, I think Mozilla's model works because of the Mozilla 
Foundation, and the Mozilla Corporation. MoFo directly gets involved in 
setting directions and policies of development and MoCo has employees 
who are paid to oversee certain aspects of the code base.

Drupal, by contrast, is a flat-hierarchy, bazaar-style project, with no 
one entity controlling the direction or governance of the project's 
development. The Drupal Association is removed from setting this type of 
direction, by design. It's the textbook case of herding cats. ;)

Therefore, we need a completely different model: it's 100% in our best 
interest to *spread around* the domain knowledge and development process 
as much as possible, rather than entrusting it to a small handful of 
people. We have absolutely no guarantees that domain experts will remain 
as such. merlinofchaos might leave the Drupal community to become a 
world-renowned novelist, or quicksketch might take off and go 
backpacking around Europe for a year. When our menu system maintainer 
went AWOL, our only recourse was to start over completely over from 
scratch again. We should do everything we can to ensure that this does 
/not/ happen again.

-Angie