21 Feb
2008
21 Feb
'08
8:01 p.m.
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@walkah.net