Open Stack

On 30/10/13 17:14, Russell Bryant wrote:
> 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.

Any practical ideas on the best way to make that work for you?