[Sugar-devel] code review (was Re: buddy tags)
michael at laptop.org
Tue Aug 4 09:23:59 EDT 2009
I like your response but I'm surprised that you're confused about why your
review process is getting bogged down, so I'll share my perspective in the
hopes that you will find it helpful.
In short, expecting the submitter to do all the work listed in your review
process condemns many perfectly reasonable patches to oblivion and discourages
contributors from submitting. 
What you should do instead is to build community around each patch *by directly
asking specific individuals* to step in. 
(Bernie, Sascha, Chris Ball, and I would all seem like good victims for code
review work.) 
This way, you get more people involved in each patch, familiar with its ideas,
and comfortable supporting one another. That's how you ramp up the volume of
: Drucker famously wrote that
Management is about human beings. Its task is to make people capable of
joint performance, to make their strengths effective and their weaknesses
We aren't doing that very well here, which is why your process is failing.
(He also had some good advice on how to do it: see, e.g., "The Essential
Drucker", ISBN 978-0066210872).
: The individuals can obviously say no, but I have found that we're all
/far/ more likely to do things when someone we respect asks us, personally,
to do them.
: We're just good guinea pigs because we're all friends of yours who are
familiar with the Sugar code base, who like making lots of different small
technical contributions, and who I know to be capable of giving a decent code
: People like to feel good and helping your friends out in small ways often
feels really good. You should take more advantage of this phenomenon. :)
* This strategy also works well for testing and deployment feedback; c.f.
Friends in Testing, NZ-testing, and the relationships that Greg formed with
people he worked with, like Pablo Flores.
* Another good name for this strategy is "providing good customer service".
You just have to realize that SL coders are customers of SL who are trading
time and frustration for satisfaction and experience.
* Does anyone need more examples, clarifications, or advice?
More information about the Sugar-devel