Open Stack

On 10/29/2013 07:14 PM, Tom Fifield wrote:
> On 30/10/13 07:58, Russell Bryant wrote:
>> On 10/29/2013 04:24 PM, 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?
>>
>> I think you're right, but it's actually no different than things have
>> been in the past.  It's just blueprints better reflecting how things
>> actually work.
>>
>> However, people that have a proven track record of producing high
>> quality work are going to have an easier time getting attention, because
>> it takes less work overall to get their patches in.  With that said, if
>> the blueprint is good, it should get priority based on its merit, even
>> if the submitter has lower karma in the community.
>>
>> Where we seem to hit the most friction is actually when merit alone
>> doesn't grant higher priority (only relevant to a small number of users,
>> for example), and submitter hasn't built up karma, either.  Those are
>> the ones that have a hard time, but it's not that surprising.
> 
> The user committee might be able to help here. Through the user survey,
> and engagement with communities around the world, they have an idea of
> what affects what number of users and how.
> 
> So, how would you feel about giving some priority manipulation abilities
> to the user committee? :)

Abilities, no, but input, of course.

If users are screaming for something, then we should absolutely be
paying attention to that.  But at the end of the day, the priorities
still have to be based on where code reviewers are willing to spend
their time.

FWIW, I love the user survey and use the results to help me think about
priorities.

-- 
Russell Bryant