On Jul 1, 2011, at 6:57 PM, David Ripton wrote: > Working with patches because you don't have svn commit rights is annoying, > but this annoyance is a relatively minor fixed cost.
It's still important for us to reduce this cost; even if it's not the bottleneck, we have to optimize first where we can optimize :). > The real issue, for controversial features, is achieving consensus, and then > getting your feature in before consensus is lost. Yes, absolutely. And there's are some important guidelines for reviewers that can be inferred from this: Try to stick to coding-standard stuff as much as possible, especially if there's been a previous review. Don't bring up "I think it would be better if..." things, except to say "file an additional ticket". If there's a previous review, as much as possible, stick to the points brought up in the previous review. Make sure they're addressed, and try not to add a pile of conflicting stylistic suggestions. When you do a review, try to be as thorough as possible. Don't ever do a review that says "update @since markers" or "2 blank lines between methods" and nothing else; at least, you need to say "... and then it will be ready to merge". Remember that when you take it out of review, no other reviewer is going to look at it until the author fixes it and resubmits it, which may be quite a while. If you feel like adding some partial commentary to help the next full reviewer, just add a comment, don't remove the review keyword. Be explicit about what happens next, even if it's going to be redundant. Always say "... and it will need another review" or "... and then merge". Try not to voice a vague dissatisfaction with the architecture of something without an explicit suggestion about (A) what should be done, and (B) whether it needs to be done before the feature can be merged. For contributors, one suggestion: make implementation details private as much as possible, so that the reviewer will have to consider the aesthetics of the implementation details less. The smaller the public API of the contribution, the easier it is to avoid bikeshedding around method names and class placement :). None of this would have helped in particular on the IPv6 stuff, but given that that affected an extremely core API, and had a ton of fiddly little details, I'm not sure much could have helped on that one... I know I've broken these rules myself on occasion, and I'd like to encourage other reviewers to call me out on it when they notice it :). -glyph
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
