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?
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
