[openstack-dev] [Nova] Blueprint review process

Thierry Carrez thierry at openstack.org
Wed Oct 30 10:29:32 UTC 2013


Stefano Maffulli wrote:
> On 10/28/2013 10:28 AM, Russell Bryant wrote:
>> 2) Setting clearer expectations.  Since we have so many blueprints for
>> Nova, I feel it's very important to accurately set expectations for how
>> the priority of different projects compare.  In the last cycle,
>> priorities were mainly subjectively set by me.  Setting priorities based
>> on what reviewers are willing to spend time on is a more accurate
>> reflection of the likelihood of a set of changes making it in to the
>> release.
> 
> I'm all for managing expectations :) I had a conversation with Tom about
> this and we agreed that there may be a risk that new contributors with
> not much karma in the project would have a harder time getting their
> blueprint assigned higher priorities. If a new group proposes a
> blueprint, they may need to "court" bp reviewers to convince them to
> dedicate attention to their first bp. The risk is that the reviewers of
> Blueprints risk of becoming a sort of gatekeeper, or what other projects
> call 'committers'.
> 
> I think this is a concrete risk, it exists but I don't know if it's
> possible to eliminate it. I don't think we have to eliminate it but we
> need to manage it to minimize it in order to keep our promise of being
> 'open' as in open to new contributors, even the ones with low karma.
> 
> What do you think?

Two remarks:

(1) Rating blueprints "low priority" doesn't mean they won't make it. It
means we have no idea if they will make it. Maybe the proposer doesn't
have a proven track record of hitting promised deadlines, maybe we don't
have core reviewers who signed up to review the work even before it was
proposed. Looking back to the havana cycle you can see that a *lot* of
"Low" blueprints made it. It's just hard to predict that they would at
the beginning of the cycle. "Priority" is not really the right word for
it. "Certainty" would be better.

(2) About creating gatekeepers like "committers": one key difference is
that anyone can participate in code reviews, so the gatekeepers are
actually an open group. That makes quite a lot of difference. If the
process doesn't specialcase "core" reviewers too much and we have a good
history of objectively promoting people with lots of reviews to "core
reviewer" status, we should be good.

-- 
Thierry Carrez (ttx)



More information about the OpenStack-dev mailing list