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.



OpenStack-dev mailing list

Reply via email to