Open Stack

On 10/31/2013 10:36 PM, Jeremy Stanley wrote:
> On 2013-10-31 22:45:56 +0000 (+0000), Romain Hardouin wrote:
>> Adding a message for new comers is a good idea.
>> I am a new Horizon contributor, some of my fixes have been merged
>> (thanks to Upstream University :-) and reviewers of course) but I
>> still hesitate to do code review. To my mind, it is reserved to
>> "known" developpers whose opinion matters...
> Not at all. One of the best ways to become "known" within the
> community is to review code and provide good recommendations. Even
> something as simple as spotting typographical errors in changes to
> user-facing messages and documentation provides value. The more
> problems you can find (and ultimately help prevent) in a change, the
> faster your reputation will grow.
>
> As has been said many times already, OpenStack does not lack
> developers... it lacks reviewers.
Reviewing and contributing unit tests are the developer activities we 
have for addressing quality. I think the issue here is how we as a 
community make sure there is balance between these activities and raw 
feature (and bug) contribution, given that most developers most enjoy 
hacking away, myself included. In a corporate software project, this 
balance would be enforced by one or all of:

1. Slowing down development
2. Providing more qa resources, including requiring developers to write 
unit tests
3. Knowingly accepting quality risk in exchange for some 
business-related gain

As an open source community we cannot do some of these things. But lack 
of reviewers effectively slows down development, and we can strive for 
the scalability of quality that comes from developers writing unit 
tests. My first contribution to swift was rejected until I enhanced the 
test infrastructure even though what I did was similar to other things 
that were not really being tested.

We should be nice about it, and spend a little extra effort in helping 
new contributors get into the swing of writing unit tests, but the 
review gate is the only real mechanism we have for making sure we have 
sufficient coverage to keep the code base maintainable by others in the 
future. I really like Rob's list because it leads down a path of better 
shared understanding of how lax/lenient reviewers should be about this.

  -David

  -David