[openstack-dev] [tc] Who is allowed to vote for TC candidates
Tim Bell
Tim.Bell at cern.ch
Tue May 5 18:38:23 UTC 2015
On 5/5/15, 6:52 PM, "Maish Saidel-Keesing" <maishsk at maishsk.com> wrote:
>On 05/05/15 19:22, Doug Hellmann wrote:
>> Excerpts from Maish Saidel-Keesing's message of 2015-05-05 18:00:15
>>+0300:
>>> On 05/05/15 16:01, Doug Hellmann wrote:
>>>> Excerpts from Adam Lawson's message of 2015-05-04 10:25:10 -0700:
>>>>>ups continue down the paths they are currently going
>>> - never shall the twain meet. They need to come towards each other. The
>>> OpenStack community needs be more receptive to the way Operators need
>>> things done. Operators need to be more receptive to the way things are
>>> done in OpenStack.
>>> Yes we have made progress. Yes we will continue to make progress. But
>>> until the Operators/users (and you can interchange users with Operators
>>> throughout my whole email - I was lazy) are accepted to be part of the
>>> decision process in OpenStack (and I think that you can agree - that if
>>> that actually happens today - it is way after the fact - or extremely
>>> late in the process) then this disconnect is going to continue.
>> Yes, I think we all want operator and user input to be included
>> much earlier in the process. It remains to be seen if the TC is the
>> right group to address those concerns directly, since we tend to
>> deal with issues that affect all projects rather than individual
>> projects. That said, there is certainly still a gap in expectations
>> for how feedback should be handled, and there's work to do to collect
>> it and make sure the right audience sees it, and helping to develop
>> the process to facilitate that communication may be something for
>> the TC to take on.
>So how do we bridge this gap and get the feedback added earlier in the
>development cycle?
>And of course the obvious question - with whom does this responsibility
>lie?
Let¹s not underestimate how far we¹ve come in the past 18 months. Ops
meetups have gone from the first with around 40 people to over 200 in
Paris. A single stream meeting in San Jose has gone to over 50 Ops
sessions at Vancouver. The specs process has given a way for the right
improvements to be made. We have now done 4 in-place upgrades in CERN's
production cloud thanks to the efforts of the various OpenStack projects
to make these activities easier while maintaining compatibility for 1000s
of usersŠ I don¹t write lengthy blogs on upgrades anymore since the
documentation covers how to do it Š. This is seriously hard work by all
concerned which has given major improvements compared to Folsom days...
The product working group has not been mentioned in this discussion so
far. It has potential to help to address the questions which often arise
when there are enhancements being requested but no resources to focus on
them or address them. While there are some people running clouds who also
contribute code, many have neither the skills or knowledge to make the
commits into the upstream versions. As many companies go through the cloud
transformation, helping the organisation's end users and changing the way
we deliver IT services is very time consuming.
I find it very encouraging that the product working group are looking to
have some people in the major sessions to consolidate some of the ideas
into actionable blueprints. This is a major contribution by the companies
working on OpenStack to bridge the etherpad->blueprint which requires many
perspectives (such as funding justification).
At Vancouver, we have the chance to have a single design summit. This
should allow people to move more quickly between sessions with aligned
timetables and location.
User committee governance fans are welcome to bring their ideas to
https://etherpad.openstack.org/p/YVR-ops-user-committee. I have been
noting down the various points from the recent threads into the ether pad
but feel free to add anything further as you wish. The bylaws give a lot
of flexibility for the user committee but we also need to be realistic
that many of the potential electorate have delivering value to their
organisations as their objective.
Tim
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
More information about the OpenStack-dev
mailing list