[development] Time to take away RTBC from every Joe
drupal-devel at webchick.net
Thu Feb 21 18:37:37 UTC 2008
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.
More information about the development