[development] RTBC - how does it work?

[Jeff Eaton]

On Jul 3, 2007, at 1:12 PM, John Wilkins wrote:

> The issue then becomes: how do patch developers get the attention  
> of committers or of the committer's web of trust? The only current  
> method is to get it marked RTBC. But then those developers get  
> frustrated as their issues languish in an RTBC queue that is the / 
> self-described/ last step.
>
> Obviously, RTBC is completely mis-named considering how committers  
> are treating that status.

Ultimately, I think the only thing that will help is a larger pool of  
people giving 'harder' reviews. In other words, taking the time to  
pore over complex or tricky patches and push back on them, pointing  
out shortcomings in architecture, code style, commenting,  
documentation, API simplicity, and so on.

This is not a statement about what 'you people' should do. I am one  
of the people that needs to do this. I look back over the D6 cycle,  
and I recognize that I gave fluff reviews and marked issues as RTBC  
prematurely for three reasons:

1) I wanted the functionality in
2) I was nervous that issues wouldn't make it in before the freeze
3) Social pressure

That last one is tricky. No one wants to be the annoying, anal- 
retentive person who holds up someone else's patch because it's not  
"just so." That's a job for Dries, right? HE'S the one who'll set it  
to 'Code Needs Work' because the PHPDoc stuff wasn't verbose enough,  
right? Add to that the social network that is the Drupal community.  
If a patch WORKS, and the person is someone who RTBC'd one of my  
patches recently, will giving it a tough 'philosophical' review  
result in ruffled feathers, mutterings of 'putting up roadblocks', etc?

I've been on that side of things, too -- asking people to 'just RTBC  
my patch already,' as if that's some sort of magic flag that  
eliminates problems. I was *really* annoyed when Dries and Steven  
raised serious questions about the 'Node Styles' and 'Node Rendering'  
patches for D6, setting them back to CNW. But you know what, after  
the dust settled and tempers cooled, it's good that those didn't go  
in. The objections they raised were important, and the only thing  
that would've been better is if someone else had been able to go over  
both patches with the same careful, critical eye to detail AND big- 
picture architecture.

I've made my decision -- from now on, I'm willing to be a 'bad guy'  
in patches that I review, and will do my best to review and manage  
statuses while asking the question, 'If I knew my RTBC would get it  
into core immediately, would that be a good thing?'



> Others (like Fernando and Earnie) have proposed a voting system or  
> a merit/karma-based system, but, as Dries said, Drupal is not a  
> democracy, so those systems would still be out of alignment with  
> how core committers are working.

I've worked with a lot of voting systems, and I think in this sort of  
scenerio they are pretty much doomed to failure. The amount of work  
that would be necessary to devise a difficult-to-game algorithm would  
be considerable. As Clay Shirky has noted in a number of his  
articles, the human brain -- and the social connections we naturally  
build -- are the best karma management system around.