Open Stack

On 05/04/2015 01:11 PM, Doug Hellmann wrote:
> Excerpts from Maish Saidel-Keesing's message of 2015-05-04 17:46:21 +0300:
>> On 05/04/15 17:07, Anita Kuno wrote:
>>> I'd like to go back to the beginning to clarify something.
>>>
>>> On 04/29/2015 02:34 PM, Adam Lawson wrote:
>>>> So I started replying to Doug's email in a different thread but didn't want
>>>> to hi-jack that so I figured I'd present my question as a more general
>>>> question about how voting is handled for the TC.
>>>>
>>>> Anyway, I find it curious that the TC is elected by those within the
>>>> developer community but TC candidates talk about representing the operator
>>>> community
>>> In my statements I talked about acknowledging the operator community not
>>> representing them. When I speak, I represent myself and my best
>>> understanding of a certain situation, if others find value in the
>>> position I hold, they will let me know.
>>>
>>> In my view of what comprises OpenStack, the TC is one point of a
>>> triangle and the operators are an entirely different point. Trying to
>>> get two points of a triangle to be the same thing compromises the
>>> integrity of the structure. Each needs to play its part, not try to be
>>> something it is not.
>> A three point triangle. I like the idea! Anita I assume that you are 
>> talking about the TC[3], the board [1] and the user committee [2].
>>
>> I honestly do not see this at the moment as an equally weighted triangle.
>> Should they be? Perhaps not, maybe yes.
>>
>> It could be that my view of things is skew, but here it is.
>>
>> The way to get something into OpenStack is through code.
>> Who submits the code? Developers.
>> Who approves code? Reviewers and core
>> On top of that you have the PTL
>> Above the PTL - you have the TC. They decide what is added into 
>> OpenStack and (are supposed) drive overall direction.
>>
>> These are the people that have actionable influence into what goes into 
>> the products.
>>
>> AFAIK neither the Foundation - nor the User committee have any 
>> actionable influence into what goes into the products, what items are 
>> prioritized and what is dropped.
>>
>>
>> If each of the three point of the triangle had proper (actionable) 
>> influence and (actionable) say in what goes on and happens within the 
>> OpenStack then that would be ideal. Does the representation have to be 
>> equal? I don't think so. But it should be there somehow.
>>
>> One of the points of the User Committee mission is:
>> "Consolidate user requirements and present these to the management board 
>> and technical committee"
>>
>> There is no mention that I could find on any of the other missions[3][1] 
>> that says that the TC or the board have to do anything with user 
>> requirements presented to them.
>>
>> I do not know if this has ever been addressed before, but it should be 
>> defined. A process with where the TC and collects requirements from the 
>> User Committee or Board and with a defined process this trickles down 
>> into the teams and projects.
> 
> You're describing these relationships in a much more hierarchical manner
> than I think reflects their reality.
> 
> Decisions about the future of OpenStack are made by the people who
> show up and contribute.  We try to identify common goals and
> priorities, and where there's little overlap we support each other
> in ways that we perceive improve the project. That process uses
> input from many sources, including product managers from contributing
> companies and operator/user feedback. As Thierry pointed out, there's
> no community group dictating what anyone works on or what the
> priorities are.

I think that's the dead on point. You get other people to help with
features / fixes not because they are told to, but because they also
believe them to be important / exciting.

Being a PTL or on the TC gives you a slightly larger soapbox, however
I'd argue that typically the individual earned the larger soapbox first,
and becoming PTL / TC was the effect of having built credibility and
influence, not the cause.

This is the nature of collaborative open development.

	-Sean

-- 
Sean Dague
http://dague.net