[development] Time to take away RTBC from every Joe

[James Walker]

Uh oh, angie... ;-)

On 21-Feb-08, at 1:37 PM, Angela Byron wrote:
> 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.

Well.... *sorta*. If we're using me as an example, yes, it's been  
mostly true for OpenID so far - definitely not true for blogapi ...  
it's been broken several times over the years by patches I missed on  
their way in.

Perhaps I'm a bad maintainer (most would argue I am), but I think we  
could do a lot to help maintainers out.

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

To a point. Never would I suggest we remove the wisdom of the  
crowds... everyone should be encouraged to submit and review patches.  
Currently, however, we have a very narrow gate (Gabor and Dries for  
D6) for stuff that actually goes in. What I'm suggesting (or  
envisioning) is actually widening that gate a bit - by expanding to a  
super-review tier (that includes MAINTAINERS.txt - and likely  
others) ... to help ease the burden of the core committers in  
verifying that an RTBC is *really* RTBC.

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

Yes, Mozilla's model is different - based on MoFo & MoCo - but the  
organizational principles don't dictate or necessitate incorporated  
bodies. Look at the typical standards bodies - or the ASF - or other  
models that have similar structures of hierarchy with more  
'consortium' type models.

Also, mozilla super reviewers are not necessarily MoCo employees (I  
haven't looked at the list in a while, but IIRC, most of them aren't).

> 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. ;)

Drupal isn't a flat-hierarchy. Again, see above.

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

I'm not advocating single points of failure... again, I would  
advocate additional redundancy. The key motive here being essentially  
formalizing the structure that you alluded is already in place - with  
the end result being formal help, and responsibility distribution  
outside the current core committers.

Truth is, we're not so different. Mozilla has *thousands* of  
contributors ... they're an older, bigger project... and I think we  
can stand to learn from them as well as others out there. Shoulders  
of giants 'n' all that :-)
--
James Walker :: http://walkah.net/ :: xmpp:walkah at walkah.net