Angie, excellent post.<div><br class="webkit-block-placeholder"></div><div>I reviewed a patch earlier today, <span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px; "><a href="http://drupal.org/node/223549">http://drupal.org/node/223549</a>. It's a no-duh usability patch that I highly approve of, but I hadn't yet looked at the code, and even if I had, I'm not a coder by any means. So I said, yep, I wish I could mark this RTBC but I can't.</span></div>
<div><span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px;"><br class="webkit-block-placeholder"></span></div><div><span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px;">But I looked at the code for the heck of it, and I saw that it was a one word change- After to Before. If that's all it takes, it's an RTBC by my standards, so I marked it RTBC.</span></div>
<div><span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px;"><br class="webkit-block-placeholder"></span></div><div><span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px;">I may be wrong on that, but if I don't have the ability to mark that RTBC, then that's irrational. It's a simple change that was not getting a lot of attention, and Usability is a high priority in D7. What's the point of contributing if you can't make that simple change?</span></div>
<div><span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px;"><br class="webkit-block-placeholder"></span></div><div><span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px;">Sorry for the rant.<br>
</span><br><div class="gmail_quote">On Thu, Feb 21, 2008 at 1:37 PM, Angela Byron <<a href="mailto:drupal-devel@webchick.net">drupal-devel@webchick.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">James Walker wrote:<br>
> On 21-Feb-08, at 7:57 AM, Moshe Weitzman wrote:<br>
>> FYI, what Karoly proposes is exactly how the Mozilla project works.<br>
>> Each patch needs a "super review" from a fixed (but large) list of<br>
>> reveiwers. See <a href="http://www.mozilla.org/hacking/" target="_blank">http://www.mozilla.org/hacking/</a><br>
><br>
> Those who have bothered to stick around and listen long enough while I<br>
> ramble will know that I'm actually in favor of this kind of approach. I<br>
> think it has several benefits :<br>
><br>
> * Clear responsibility - in case of questions, complications, etc - the<br>
> "buck stops" at a defined point for resolution.<br>
><br>
> * Allows for "domain experts" - very frequently patches come in that can<br>
> have tricky, subtle implications for some of the more complicated<br>
> systems (menu, formapi, search etc etc etc) and it's *really* hard<br>
> (frankly too much to ask) for the few core committers to have<br>
> comprehensive understanding of all of Drupal at this level.<br>
<br>
</div>But we already have this, albeit more informally:<br>
- OpenID patches don't get committed until you've looked them over.<br>
- Actions patches don't get committed until John VanDyk has chimed in.<br>
- chx or pwolanin need to look at menu system patches.<br>
- Jeff Eaton or chx need to approve FAPI patches.<br>
- Barry or Frando need to thumbs-up Schema API changes.<br>
- merlinofchaos and dvessel are in charge of theming-related changes.<br>
- quicksketch is the Drupal JS master.<br>
<br>
And so on. MAINTAINERS.txt /already/ means something.<br>
<br>
The vast majority of patches, however, are not directly related to these<br>
types of low-level changes that require specific domain knowledge;<br>
they're string fixes, or usability improvements, or logic fixes, or<br>
simple new features, and so on. Being able to rely the "wisdom of<br>
crowds" in the larger community to handle tasks like reviewing patches<br>
and changing issue statuses is a /good/ thing.<br>
<br>
Further, I think Mozilla's model works because of the Mozilla<br>
Foundation, and the Mozilla Corporation. MoFo directly gets involved in<br>
setting directions and policies of development and MoCo has employees<br>
who are paid to oversee certain aspects of the code base.<br>
<br>
Drupal, by contrast, is a flat-hierarchy, bazaar-style project, with no<br>
one entity controlling the direction or governance of the project's<br>
development. The Drupal Association is removed from setting this type of<br>
direction, by design. It's the textbook case of herding cats. ;)<br>
<br>
Therefore, we need a completely different model: it's 100% in our best<br>
interest to *spread around* the domain knowledge and development process<br>
as much as possible, rather than entrusting it to a small handful of<br>
people. We have absolutely no guarantees that domain experts will remain<br>
as such. merlinofchaos might leave the Drupal community to become a<br>
world-renowned novelist, or quicksketch might take off and go<br>
backpacking around Europe for a year. When our menu system maintainer<br>
went AWOL, our only recourse was to start over completely over from<br>
scratch again. We should do everything we can to ensure that this does<br>
/not/ happen again.<br>
<br>
-Angie<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>Sincerely,<br>Michael
</div>