[openstack-dev] [tc] Who is allowed to vote for TC candidates

Maish Saidel-Keesing maishsk at maishsk.com
Tue May 5 15:00:15 UTC 2015



On 05/05/15 16:01, Doug Hellmann wrote:
> Excerpts from Adam Lawson's message of 2015-05-04 10:25:10 -0700:
>> So Thierry I agree. Developers are required to make it happen. I would say
>> however that acknowledging the importance of developer contributions and
>> selecting leadership from the development community is really half the
>> battle as it's pretty rare to see project teams led and governed by only
>> developers. I think addressing the inclusion of architects/operators/admins
>> within this committee is a hugely positive development.
> The community of contributors is led by members, not all of whom
> are "developers" -- some are writers, translators, designers, or
> fill other important roles. The characteristic that cuts across all
> of those roles is that they are *contributors*.
>
> If "architects/operators/admins" or anyone else want to become
> contributors, there is already a path to accomplish that by interacting
> with the existing teams, and their insight and input would be very
> welcome. But there is no shortcut to becoming a leader in this
> community. Everyone has to earn their stripes.
>
> I've asked a couple of times in this thread what benefit you see
> in having someone from outside of the contributor community on the
> TC, but I haven't seen an answer. Is there something specific we
> could be addressing beyond the question of representation?
Hi Doug.

It is not only the representation - it is also action on the feedback.

There was an OPS summit not so long ago in Philadelphia [1]. Two full 
days. I personally did not participate but from what I heard it was a 
good two days of discussions.

There are at least 10 etherpads (Yay!! The OpenStack way of doing 
things!) that summarized the thoughts and concerns of the participants.

I think it would be fair to ask - how many actionable items came out of 
the this meeting that were implemented in any of the projects? If anyone 
has answers - they would be highly appreciated.
Did the TC follow up on these items?
Did the PTL's? (I know some of the PTL's were present there at the summit)

Now you might say - that is not their job, but I do think that it should 
be. The developer teams are asking for feedback the whole time. Saying 
that Operators are not sending it back their way. Here they are. What 
was done with all of this?

Were bugs raised?
Were blueprints submitted to make changes to accommodate any of these 
requests? Address any of them?
Please don't tell me that you are waiting for the Operations people to 
submit all of these - because it is not going to happen. Most of them do 
not know how.

So here is a process that breaks down. The info is there, but that 
information is not being followed through upon.

Whose responsibility is this? The TC? The Foundation? The PTL's?
Here we have proper feedback from those using the products, fighting 
with (not against) the products and trying to get it working. If even 
10% of the items mentioned in these etherpads were addressed (or have a 
documented plan to be addressed in the future) then I will be very 
surprised.

It comes down to this. OpenStack developers have a way of doing things. 
Operators also have a way of doing things - which is quite different to 
the way OpenStack does things.

If each of these groups 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.

There is a feeling (at least that is my perception) that code is 
developed in a vacuum today. Without actually going into the field and 
asking what is needed - what is being used - what could be made better - 
before deciding what to write and fix.

"If you build it they will come[2]" was a great idea in Hollywood, but I 
am not sure it will work as well for us - for OpenStack.

Any ideas on how this could be solved - would be highly appreciated.
[1] https://etherpad.openstack.org/p/PHL-ops-meetup
[2] http://en.wikipedia.org/wiki/Field_of_Dreams
-- 
Best Regards,
Maish Saidel-Keesing



More information about the OpenStack-dev mailing list