Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Thierry Carrez]

Fox, Kevin M wrote:

[...]
Part of the disconnect to me has been that these questions have been left up to 
the projects by and large. But, users don't use the projects. Users use 
OpenStack. Or, moving forward, they at least use a Constellation. But 
Constellation is still just a documentation construct. Not really a first class 
entity.

Currently the isolation between the Projects and the thing that the users use, the 
Constellation allows for user needs to easily slip through the cracks. Cause 
"Project X: we agree that is a problem, but its Y projects problem. Project Y: we 
agree that is a problem, but its X projects problem." No, seriously, its OpenStacks 
problem. Most of the major issues I've hit in my many years of using OpenStack were in 
that category. And there wasn't a good forum for addressing them.

A related effect of the isolation is also that the projects don't work on the 
commons nor look around too much what others are doing. Either within OpenStack 
or outside. They solve problems at the project level and say, look, I've solved 
it, but don't look at what happens when all the projects do that independently 
and push more work to the users. The end result of this lack of Leadership is 
more work for the users compared to competitors.
[...]


+1

Slicing development along component lines ("project teams") was a useful 
construct to absorb all the energy that was sent to OpenStack between 
2011 and 2016. But at our current stage (less resources, more users) I 
agree that that structure is no longer optimal.


I think we need to start thinking about ways to de-emphasize project 
teams (organizing work around code boundaries) and organize work around 
goals instead (across code boundaries). A bit like work in Kubernetes is 
tracked at SIG level, beyond code ownership. It's not an easy change, 
with project teams being so integral to our culture, but it is something 
we should start looking into.


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Matt Riedemann]

On 5/11/2018 2:00 PM, Fox, Kevin M wrote:

Currently the isolation between the Projects and the thing that the users use, the 
Constellation allows for user needs to easily slip through the cracks. Cause 
"Project X: we agree that is a problem, but its Y projects problem. Project Y: we 
agree that is a problem, but its X projects problem." No, seriously, its OpenStacks 
problem. Most of the major issues I've hit in my many years of using OpenStack were in 
that category. And there wasn't a good forum for addressing them.


Agree, and we'll be talking about this during the volume multi-attach 
talk at the summit [1]. Because once we got it out the door in Queens, 
there was a lot of "what took so long?" feedback, and the answer to that 
question pulls from a lot of the stuff you're talking about in this 
thread, i.e. big changes are hard, big changes across multiple projects 
are hard, finding people to sustain the efforts for those big changes is 
hard, not dumping a steaming pile on the operators and users is hard 
(think smooth upgrades), etc. So things take time to do them correctly 
and even then people are not satisfied because "it took too long". 
Anyway, there are hopefully some nuggets of wisdom we can share in that 
talk to make stuff like this smoother in the future. I know this isn't 
the only example (by far), it's just a recent one. Lance has some other 
good ones in his reply.


[1] 
https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/20850/the-multi-release-multi-project-road-to-volume-multi-attach


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Lance Bragstad]

gh. And we can't even really define what a user is. This is a big problem.
>
> Anyway, more Leadership please! Ready. GO! :)
>
> Thanks,
> Kevin
>
> 
> From: Jay Pipes [jaypi...@gmail.com]
> Sent: Friday, May 11, 2018 9:31 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in 
> Vancouver
>
> On 05/11/2018 12:21 PM, Zane Bitter wrote:
>> On 11/05/18 11:46, Jay Pipes wrote:
>>> On 05/10/2018 08:12 PM, Zane Bitter wrote:
>>>> On 10/05/18 16:45, Matt Riedemann wrote:
>>>>> On 5/10/2018 3:38 PM, Zane Bitter wrote:
>>>>>> How can we avoid (or get out of) the local maximum trap and ensure
>>>>>> that OpenStack will meet the needs of all the users we want to
>>>>>> serve, not just those whose needs are similar to those of the users
>>>>>> we already have?
>>>>> The phrase "jack of all trades, master of none" comes to mind here.
>>>> Stipulating the constraint that you can't please everybody, how do
>>>> you ensure that you're meeting the needs of the users who are most
>>>> important to the long-term sustainability of the project, and not
>>>> just the ones who were easiest to bootstrap?
>>> Who gets to decide who the users are "that are most important to the
>>> long-term sustainability of the project"?
>> The thing I'm hoping to convince people of here is that the question is
>> interesting independently of how you define that.
> Agreed. The question is interesting regardless, but how seriously people
> take the answers to the question will depend on how much they agree with
> the people that decide who the "important users" are.
>
> Best,
> -jay
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Jimmy McArthur]

Fox, Kevin M wrote:

Who are your users, what do they need, are you meeting those needs, and what 
can you do to better things?

IMO, OpenStack really needs some Leadership at a higher level. It seems to be 
lacking some things:
1. A group that performs... lacking a good word reconnaissance? How is 
OpenStack fairing in the world. How is the world changing and how must 
OpenStack change to continue to be relevant. If you don't know you have a 
problem you can't correct it.
2. A group that decides some difficult political things, like who the users are. Maybe at 
a per constellation level. This does not mean rejecting use cases from "non 
users". just helping the projects sort out priorities.
3. A group that decides on a general direction for OpenStack's technical 
solutions, encourages building up the commons, helps break down the project 
communication walls and picks homes for features when it takes too long for a 
user need to be met (users really don't care what OpenStack project does what 
feature. They just that they are suffering, things don't get addressed in a 
timely manner, and will maybe consider looking outside of OpenStack for a 
solution)
This is a big reason we're excited that the Ops & Users Meetup are 
co-locating at the next PTG.  Some of the breakdown is getting 
actionable items from Ops Meetups and UC back to the devs in time for 
the next development cycle.


The current governance structure is focused on hoping the individual projects 
will look at the big picture and adjust to it, and commit the relevant common 
code to the commons rather then one-offing a solution and discussing solutions 
between projects to gain consensus. But that's generally not happening. The 
projects have a narrow view of the world and just wanna make progress on their 
code. I get that. The other bits are hard. Guidance to the projects on how they 
are are, or are not fitting, would help them make better choices and better 
code.
Keep in mind, UC also has governance :)  I think it's really important 
to start looking to the UC to help craft the big picture and be part of 
the conversation. This serves the purpose of getting Ops & Devs working 
together towards a better OpenStack.  It also helps broaden the 
perspective of everyone involved in the project, from all sides.


The focus so much on projects has made us loose sight of why they exist. To 
serve the Users. Users don't use projects as OpenStack has defined them though. 
And we can't even really define what a user is. This is a big problem.

Anyway, more Leadership please! Ready. GO! :)

Thanks,
Kevin


From: Jay Pipes [jaypi...@gmail.com]
Sent: Friday, May 11, 2018 9:31 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in 
Vancouver

On 05/11/2018 12:21 PM, Zane Bitter wrote:

On 11/05/18 11:46, Jay Pipes wrote:

On 05/10/2018 08:12 PM, Zane Bitter wrote:

On 10/05/18 16:45, Matt Riedemann wrote:

On 5/10/2018 3:38 PM, Zane Bitter wrote:

How can we avoid (or get out of) the local maximum trap and ensure
that OpenStack will meet the needs of all the users we want to
serve, not just those whose needs are similar to those of the users
we already have?

The phrase "jack of all trades, master of none" comes to mind here.

Stipulating the constraint that you can't please everybody, how do
you ensure that you're meeting the needs of the users who are most
important to the long-term sustainability of the project, and not
just the ones who were easiest to bootstrap?

Who gets to decide who the users are "that are most important to the
long-term sustainability of the project"?

The thing I'm hoping to convince people of here is that the question is
interesting independently of how you define that.


Agreed. The question is interesting regardless, but how seriously people
take the answers to the question will depend on how much they agree with
the people that decide who the "important users" are.

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Fox, Kevin M]

Who are your users, what do they need, are you meeting those needs, and what 
can you do to better things?

If that can't be answered, how do you know if you are making progress or 
staying relevant?

Lines of code committed is not a metric of real progress.
Number of reviews isn't.
Feature addition metrics aren't necessarily if the features are not relevant.
Developer community size is not really a metric of progress either. (not a bad 
thing. just doesn't grantee progress if devs are going in different directions)

If you can't answer them, how do separate things like, "devs are leaving 
because the project is mature, from the overall project is really broken and 
folks are just leaving?"

Part of the disconnect to me has been that these questions have been left up to 
the projects by and large. But, users don't use the projects. Users use 
OpenStack. Or, moving forward, they at least use a Constellation. But 
Constellation is still just a documentation construct. Not really a first class 
entity.

Currently the isolation between the Projects and the thing that the users use, 
the Constellation allows for user needs to easily slip through the cracks. 
Cause "Project X: we agree that is a problem, but its Y projects problem. 
Project Y: we agree that is a problem, but its X projects problem." No, 
seriously, its OpenStacks problem. Most of the major issues I've hit in my many 
years of using OpenStack were in that category. And there wasn't a good forum 
for addressing them.

A related effect of the isolation is also that the projects don't work on the 
commons nor look around too much what others are doing. Either within OpenStack 
or outside. They solve problems at the project level and say, look, I've solved 
it, but don't look at what happens when all the projects do that independently 
and push more work to the users. The end result of this lack of Leadership is 
more work for the users compared to competitors.

IMO, OpenStack really needs some Leadership at a higher level. It seems to be 
lacking some things:
1. A group that performs... lacking a good word reconnaissance? How is 
OpenStack fairing in the world. How is the world changing and how must 
OpenStack change to continue to be relevant. If you don't know you have a 
problem you can't correct it.
2. A group that decides some difficult political things, like who the users 
are. Maybe at a per constellation level. This does not mean rejecting use cases 
from "non users". just helping the projects sort out priorities.
3. A group that decides on a general direction for OpenStack's technical 
solutions, encourages building up the commons, helps break down the project 
communication walls and picks homes for features when it takes too long for a 
user need to be met (users really don't care what OpenStack project does what 
feature. They just that they are suffering, things don't get addressed in a 
timely manner, and will maybe consider looking outside of OpenStack for a 
solution)

The current governance structure is focused on hoping the individual projects 
will look at the big picture and adjust to it, and commit the relevant common 
code to the commons rather then one-offing a solution and discussing solutions 
between projects to gain consensus. But that's generally not happening. The 
projects have a narrow view of the world and just wanna make progress on their 
code. I get that. The other bits are hard. Guidance to the projects on how they 
are are, or are not fitting, would help them make better choices and better 
code.

The focus so much on projects has made us loose sight of why they exist. To 
serve the Users. Users don't use projects as OpenStack has defined them though. 
And we can't even really define what a user is. This is a big problem.

Anyway, more Leadership please! Ready. GO! :)

Thanks,
Kevin


From: Jay Pipes [jaypi...@gmail.com]
Sent: Friday, May 11, 2018 9:31 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in 
Vancouver

On 05/11/2018 12:21 PM, Zane Bitter wrote:
> On 11/05/18 11:46, Jay Pipes wrote:
>> On 05/10/2018 08:12 PM, Zane Bitter wrote:
>>> On 10/05/18 16:45, Matt Riedemann wrote:
>>>> On 5/10/2018 3:38 PM, Zane Bitter wrote:
>>>>> How can we avoid (or get out of) the local maximum trap and ensure
>>>>> that OpenStack will meet the needs of all the users we want to
>>>>> serve, not just those whose needs are similar to those of the users
>>>>> we already have?
>>>>
>>>> The phrase "jack of all trades, master of none" comes to mind here.
>>>
>>> Stipulating the constraint that you can't please everybody, how do
>>> you ensure that you're meeting the needs of the users who are most
>>> important to the long-term 

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Jay Pipes]

On 05/11/2018 12:21 PM, Zane Bitter wrote:

On 11/05/18 11:46, Jay Pipes wrote:

On 05/10/2018 08:12 PM, Zane Bitter wrote:

On 10/05/18 16:45, Matt Riedemann wrote:

On 5/10/2018 3:38 PM, Zane Bitter wrote:
How can we avoid (or get out of) the local maximum trap and ensure 
that OpenStack will meet the needs of all the users we want to 
serve, not just those whose needs are similar to those of the users 
we already have?


The phrase "jack of all trades, master of none" comes to mind here. 


Stipulating the constraint that you can't please everybody, how do 
you ensure that you're meeting the needs of the users who are most 
important to the long-term sustainability of the project, and not 
just the ones who were easiest to bootstrap?


Who gets to decide who the users are "that are most important to the 
long-term sustainability of the project"?


The thing I'm hoping to convince people of here is that the question is 
interesting independently of how you define that.


Agreed. The question is interesting regardless, but how seriously people 
take the answers to the question will depend on how much they agree with 
the people that decide who the "important users" are.


Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Zane Bitter]

On 11/05/18 11:46, Jay Pipes wrote:

On 05/10/2018 08:12 PM, Zane Bitter wrote:

On 10/05/18 16:45, Matt Riedemann wrote:

On 5/10/2018 3:38 PM, Zane Bitter wrote:
How can we avoid (or get out of) the local maximum trap and ensure 
that OpenStack will meet the needs of all the users we want to 
serve, not just those whose needs are similar to those of the users 
we already have?


The phrase "jack of all trades, master of none" comes to mind here. 


Stipulating the constraint that you can't please everybody, how do you 
ensure that you're meeting the needs of the users who are most 
important to the long-term sustainability of the project, and not just 
the ones who were easiest to bootstrap?


Who gets to decide who the users are "that are most important to the 
long-term sustainability of the project"?


The thing I'm hoping to convince people of here is that the question is 
interesting independently of how you define that.


- ZB

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Jay Pipes]

On 05/10/2018 08:12 PM, Zane Bitter wrote:

On 10/05/18 16:45, Matt Riedemann wrote:

On 5/10/2018 3:38 PM, Zane Bitter wrote:
How can we avoid (or get out of) the local maximum trap and ensure 
that OpenStack will meet the needs of all the users we want to serve, 
not just those whose needs are similar to those of the users we 
already have?


The phrase "jack of all trades, master of none" comes to mind here. 


Stipulating the constraint that you can't please everybody, how do you 
ensure that you're meeting the needs of the users who are most important 
to the long-term sustainability of the project, and not just the ones 
who were easiest to bootstrap?


Who gets to decide who the users are "that are most important to the 
long-term sustainability of the project"?


Assuming there is a single definition of what "the project" actually is...

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Thierry Carrez]

Zane Bitter wrote:
> [...]
> How can we avoid (or get out of) the local maximum trap and ensure that
> OpenStack will meet the needs of all the users we want to serve, not
> just those whose needs are similar to those of the users we already have?

It'a a good question, and a topic I raised a couple years ago.

Back then we had (and we arguably still have) a critical mass of
medium-sized private clouds, which makes most contributions gravitate to
that middle area of the potential usage spectrum.

But for the success of OpenStack we need the two extremes to be served:
the "giant public cloud" use case (because we all need that giant public
cloud to burst infinite capacity to in hybrid scenarios), but also the
"lab deployment" use case because that's a great on-boarding tool.
Currently it's still too complex to use OpenStack in those two ends of
the use case spectrum.

How do we solve that ? We can't rely on natural open collaboration
dynamics ("show up and be the change you want to see in the world") --
that one will continue to feed the medium use case. We can continue to
wait for proponents of the "small deployment" or the "massive public
cloud" to suddenly invest hundreds of FTEs to cover their use case. Or
we can be aware of the local maximum trap, go a bit out of our ways to
serve both ends of the spectrum, and realize that it puts us in a lot
better place.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Zane Bitter]

On 10/05/18 16:52, Doug Hellmann wrote:

Excerpts from Zane Bitter's message of 2018-05-10 16:38:37 -0400:

On 17/04/18 05:24, Thierry Carrez wrote:

Hi everyone,

As you know the Technical Committee (the governance body representing
contributors producing OpenStack software) meets with other OpenStack
governance bodies (Board of Directors and User Committee) on the Sunday
before every Summit, and Vancouver will be no exception.

At the TC retrospective Forum session in Sydney we decided we should
more broadly ask our constituency for topics they would like us to cover
in that discussion.

Once the current election cycle is over and the new TC chair is picked,
we'll come up with a proposed agenda and submit it to the Chairman of
the Board for consideration.

So... Is there any specific topic you think we should cover in that
meeting ?


There's one topic I've been thinking about that I think would be
valuable to discuss with the Board and the UC. I don't know if we still
have time to add stuff to the agenda for Vancouver, but if not then
consider this my advance submission for Denver.

OpenStack was bootstrapped using a very powerful positive feedback loop:
in (very) broad-brush terms it started with a minimum viable product;
users for whom that was enough to entice them tried it out and offered
suggestions; vendors who wanted to sell to those users (as well as the
users themselves) implemented the suggestions; both groups joined the
Foundation, which marketed OpenStack to folks with similar needs.

Obviously that is a good thing, but it also comes with the danger of
getting trapped in a local maximum. Users for whom the product has not
yet met the threshold of minimum viability are generally not going to
show up, and their needs are no match for the feedback loop set up with
the users who _have_ shown up. (Specifically, we are arguably only just
now approaching the minimum viability point for the types of cloud-aware
applications that are routinely written against the APIs of the big 3
proprietary clouds.)

How can we avoid (or get out of) the local maximum trap and ensure that
OpenStack will meet the needs of all the users we want to serve, not
just those whose needs are similar to those of the users we already have?

Discuss.

thanks,
Zane.



This does feel like an excellent topic for one of these strategic
discussion sessions, but I think the agenda is already full for this
particular meeting. Maybe we can discuss it within the TC between now
and Denver so we have a good way to frame the question and discussion at
that meeting?


+1. As usual I've been struggling to find a good balance between being 
too abstract and too specific, so I'd appreciate help in framing the 
question to avoid sending the discussion directly into the weeds. cdent 
already had a good suggestion on IRC.


cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Zane Bitter]

On 10/05/18 16:45, Matt Riedemann wrote:

On 5/10/2018 3:38 PM, Zane Bitter wrote:
How can we avoid (or get out of) the local maximum trap and ensure 
that OpenStack will meet the needs of all the users we want to serve, 
not just those whose needs are similar to those of the users we 
already have?


The phrase "jack of all trades, master of none" comes to mind here. 


Stipulating the constraint that you can't please everybody, how do you 
ensure that you're meeting the needs of the users who are most important 
to the long-term sustainability of the project, and not just the ones 
who were easiest to bootstrap?


It's the same question.

Wasn't the explosion of big tent projects at least an indication of 
people trying to make OpenStack all things to all people and failing 
most of the time?


Well, just to take one example, we built a lot of things that you might 
characterise as application services, but not until Queens did we have a 
mechanism for applications to authenticate to those services without 
giving them the user's LDAP password. (Thanks Colleen!!!) Now, to the 
extent that those projects can be said to have "mostly fail[ed]", was it 
because we:


* Tried to do too much?
* Tried to do too little?
* Tried to do the wrong things?

Opinions differ.

- ZB

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Doug Hellmann]

Excerpts from Zane Bitter's message of 2018-05-10 16:38:37 -0400:
> On 17/04/18 05:24, Thierry Carrez wrote:
> > Hi everyone,
> > 
> > As you know the Technical Committee (the governance body representing
> > contributors producing OpenStack software) meets with other OpenStack
> > governance bodies (Board of Directors and User Committee) on the Sunday
> > before every Summit, and Vancouver will be no exception.
> > 
> > At the TC retrospective Forum session in Sydney we decided we should
> > more broadly ask our constituency for topics they would like us to cover
> > in that discussion.
> > 
> > Once the current election cycle is over and the new TC chair is picked,
> > we'll come up with a proposed agenda and submit it to the Chairman of
> > the Board for consideration.
> > 
> > So... Is there any specific topic you think we should cover in that
> > meeting ?
> 
> There's one topic I've been thinking about that I think would be 
> valuable to discuss with the Board and the UC. I don't know if we still 
> have time to add stuff to the agenda for Vancouver, but if not then 
> consider this my advance submission for Denver.
> 
> OpenStack was bootstrapped using a very powerful positive feedback loop: 
> in (very) broad-brush terms it started with a minimum viable product; 
> users for whom that was enough to entice them tried it out and offered 
> suggestions; vendors who wanted to sell to those users (as well as the 
> users themselves) implemented the suggestions; both groups joined the 
> Foundation, which marketed OpenStack to folks with similar needs.
> 
> Obviously that is a good thing, but it also comes with the danger of 
> getting trapped in a local maximum. Users for whom the product has not 
> yet met the threshold of minimum viability are generally not going to 
> show up, and their needs are no match for the feedback loop set up with 
> the users who _have_ shown up. (Specifically, we are arguably only just 
> now approaching the minimum viability point for the types of cloud-aware 
> applications that are routinely written against the APIs of the big 3 
> proprietary clouds.)
> 
> How can we avoid (or get out of) the local maximum trap and ensure that 
> OpenStack will meet the needs of all the users we want to serve, not 
> just those whose needs are similar to those of the users we already have?
> 
> Discuss.
> 
> thanks,
> Zane.
> 

This does feel like an excellent topic for one of these strategic
discussion sessions, but I think the agenda is already full for this
particular meeting. Maybe we can discuss it within the TC between now
and Denver so we have a good way to frame the question and discussion at
that meeting?

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Matt Riedemann]

On 5/10/2018 3:38 PM, Zane Bitter wrote:
How can we avoid (or get out of) the local maximum trap and ensure that 
OpenStack will meet the needs of all the users we want to serve, not 
just those whose needs are similar to those of the users we already have?


The phrase "jack of all trades, master of none" comes to mind here. 
Wasn't the explosion of big tent projects at least an indication of 
people trying to make OpenStack all things to all people and failing 
most of the time?


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Zane Bitter]

On 17/04/18 05:24, Thierry Carrez wrote:

Hi everyone,

As you know the Technical Committee (the governance body representing
contributors producing OpenStack software) meets with other OpenStack
governance bodies (Board of Directors and User Committee) on the Sunday
before every Summit, and Vancouver will be no exception.

At the TC retrospective Forum session in Sydney we decided we should
more broadly ask our constituency for topics they would like us to cover
in that discussion.

Once the current election cycle is over and the new TC chair is picked,
we'll come up with a proposed agenda and submit it to the Chairman of
the Board for consideration.

So... Is there any specific topic you think we should cover in that
meeting ?


There's one topic I've been thinking about that I think would be 
valuable to discuss with the Board and the UC. I don't know if we still 
have time to add stuff to the agenda for Vancouver, but if not then 
consider this my advance submission for Denver.


OpenStack was bootstrapped using a very powerful positive feedback loop: 
in (very) broad-brush terms it started with a minimum viable product; 
users for whom that was enough to entice them tried it out and offered 
suggestions; vendors who wanted to sell to those users (as well as the 
users themselves) implemented the suggestions; both groups joined the 
Foundation, which marketed OpenStack to folks with similar needs.


Obviously that is a good thing, but it also comes with the danger of 
getting trapped in a local maximum. Users for whom the product has not 
yet met the threshold of minimum viability are generally not going to 
show up, and their needs are no match for the feedback loop set up with 
the users who _have_ shown up. (Specifically, we are arguably only just 
now approaching the minimum viability point for the types of cloud-aware 
applications that are routinely written against the APIs of the big 3 
proprietary clouds.)


How can we avoid (or get out of) the local maximum trap and ensure that 
OpenStack will meet the needs of all the users we want to serve, not 
just those whose needs are similar to those of the users we already have?


Discuss.

thanks,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Thierry Carrez]

Doug Hellmann wrote:
> Excerpts from Graham Hayes's message of 2018-04-23 15:36:32 +0100:
>> I think as an add on to this, would to ask the board to talk to members
>> and see what contributions they have made to the technical side of
>> OpenStack.
>>
>> This should not just be Number of commits / reviews / bugs etc but
>> also the motivation for the work, e.g. - Feature for a product, bug fix
>> found in a product, cross project work or upstream project maintenance.
> 
> A while back Jay Pipes suggested that we ask contributing companies
> to summarize their work. I think that was in the context of
> understanding what platinum members are doing, but it could apply
> to everyone. By leaving the definition of "contribution" open-ended
> and asking as a way to celebrate those contributions, we could avoid
> any sense of shaming as well as see what the companies consider to
> be important.

Yes, we discussed this in Sydney and I took the action to try to include
it in the Foundation annual report. You can find the result in the
Foundation annual report this year:

https://www.openstack.org/assets/reports/OpenStack-AnnualReport2017.pdf

See pages 7-9. Obviously not optimal (not everybody answered, and some
of the responses are a bit off-topic), but we had limited time to pull
it off and I think it's a good first step. We can take that as a basis
for the next stage of discussion.

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Jeremy Stanley]

On 2018-04-23 15:36:32 +0100 (+0100), Graham Hayes wrote:
> I think as an add on to this, would to ask the board to talk to members
> and see what contributions they have made to the technical side of
> OpenStack.
> 
> This should not just be Number of commits / reviews / bugs etc but
> also the motivation for the work, e.g. - Feature for a product, bug fix
> found in a product, cross project work or upstream project maintenance.
> 
> I don't necessarily want to shame corporate members of the foundation,
> but I think it is important to understand where our contributor base
> comes from, and what each member brings to the community table.
> 
> We should also ask the board to try and formulate a plan for growing
> new cross project leaders (not just TC / PTLs). We need to grow more
> technical contributors in the horizontal teams, which requires more
> than assigning a contributor to the QA / Infra / Olso / Docs teams
> for a year or so - the people should be allowed a certain amount
> of stability in a role, while not necessarily driving business goals.
[...]

Taking this further, I really think that the spirit of our
requirement that certain member organizations dedicate staff to
contributing is that they be applied to under-served commons in the
project (whether that's helping in horizontal teams and on
cross-project goals, or triaging bugs and answering random usage
questions). If they get to count the staff they put on some feature
they needed for their new product launch, that's rather self-serving
and doesn't really help us much.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Doug Hellmann]

Excerpts from Graham Hayes's message of 2018-04-23 15:36:32 +0100:
> On 18/04/18 11:38, Chris Dent wrote:
> > On Tue, 17 Apr 2018, Thierry Carrez wrote:
> > 
> >> So... Is there any specific topic you think we should cover in that
> >> meeting ?
> > 
> > The topics:
> > 
> > 1. What are we to do, as a community, when external pressures for
> > results are not matched by contribution of resources to produce
> > those results? There are probably several examples of this, but one
> > that I'm particularly familiar with is the drive to be able to
> > satisfy complex hardware topologies demanded by virtual network
> > functions and related NFV use cases. Within nova, and I suspect other
> > projects, there is intense pressure to make progress and intense
> > effort that is removing resources from other areas. But the amount
> > of daily, visible contribution from the interest companies [1] is
> > _sometimes_ limited. There are many factors in this, and obviously
> > "throw more people at it" is not a silver bullet, but there are
> > things to talk about here that need the input from all the segments.
> > 
> > 2. We've made progress of late with acknowledging the concepts
> > and importance of casual contribution and "drive-by bug fixing" in
> > our changing environment. But we've not yet made enough progress in
> > changing the way we do work. Corporate foundation members need to be
> > more aware and more accepting that the people they provide to work
> > "mostly upstream" need to be focused on making other people capable
> > of contribution. Not on getting features done. And those of us who
> > do have the privilege of being "mostly upstream" need to adjust our
> > priorities.
> > 
> > Somewhere in that screed are, I think, some things worth talking
> > about, but they need to be distilled out.
> > 
> > [1] http://superuser.openstack.org/articles/5g-open-source-att/
> 
> 
> I think as an add on to this, would to ask the board to talk to members
> and see what contributions they have made to the technical side of
> OpenStack.
> 
> This should not just be Number of commits / reviews / bugs etc but
> also the motivation for the work, e.g. - Feature for a product, bug fix
> found in a product, cross project work or upstream project maintenance.

A while back Jay Pipes suggested that we ask contributing companies
to summarize their work. I think that was in the context of
understanding what platinum members are doing, but it could apply
to everyone. By leaving the definition of "contribution" open-ended
and asking as a way to celebrate those contributions, we could avoid
any sense of shaming as well as see what the companies consider to
be important.

> 
> I don't necessarily want to shame corporate members of the foundation,
> but I think it is important to understand where our contributor base
> comes from, and what each member brings to the community table.
> 
> We should also ask the board to try and formulate a plan for growing
> new cross project leaders (not just TC / PTLs). We need to grow more
> technical contributors in the horizontal teams, which requires more
> than assigning a contributor to the QA / Infra / Olso / Docs teams
> for a year or so - the people should be allowed a certain amount
> of stability in a role, while not necessarily driving business goals.

This topic has come up a few times. I wonder if we could get more
traction here if we had details about how attempts in the past have
failed ("person X was given 6 months to train on the team before
being moved to a different project", etc.)? Pulling together that
sort of information might take longer than we have between now and
the Vancouver meeting.

I also anticipate the board's response being, "Tell us what you need
done." so we should have an answer to that, even if it's just "we need
help with ideas, let's form a working group".

> 
> > 
> > 
> > 
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Zhipeng Huang]

big +1 to Graham's suggestion

On Mon, Apr 23, 2018 at 10:36 PM, Graham Hayes  wrote:

> On 18/04/18 11:38, Chris Dent wrote:
> > On Tue, 17 Apr 2018, Thierry Carrez wrote:
> >
> >> So... Is there any specific topic you think we should cover in that
> >> meeting ?
> >
> > The topics:
> >
> > 1. What are we to do, as a community, when external pressures for
> > results are not matched by contribution of resources to produce
> > those results? There are probably several examples of this, but one
> > that I'm particularly familiar with is the drive to be able to
> > satisfy complex hardware topologies demanded by virtual network
> > functions and related NFV use cases. Within nova, and I suspect other
> > projects, there is intense pressure to make progress and intense
> > effort that is removing resources from other areas. But the amount
> > of daily, visible contribution from the interest companies [1] is
> > _sometimes_ limited. There are many factors in this, and obviously
> > "throw more people at it" is not a silver bullet, but there are
> > things to talk about here that need the input from all the segments.
> >
> > 2. We've made progress of late with acknowledging the concepts
> > and importance of casual contribution and "drive-by bug fixing" in
> > our changing environment. But we've not yet made enough progress in
> > changing the way we do work. Corporate foundation members need to be
> > more aware and more accepting that the people they provide to work
> > "mostly upstream" need to be focused on making other people capable
> > of contribution. Not on getting features done. And those of us who
> > do have the privilege of being "mostly upstream" need to adjust our
> > priorities.
> >
> > Somewhere in that screed are, I think, some things worth talking
> > about, but they need to be distilled out.
> >
> > [1] http://superuser.openstack.org/articles/5g-open-source-att/
>
>
> I think as an add on to this, would to ask the board to talk to members
> and see what contributions they have made to the technical side of
> OpenStack.
>
> This should not just be Number of commits / reviews / bugs etc but
> also the motivation for the work, e.g. - Feature for a product, bug fix
> found in a product, cross project work or upstream project maintenance.
>
> I don't necessarily want to shame corporate members of the foundation,
> but I think it is important to understand where our contributor base
> comes from, and what each member brings to the community table.
>
> We should also ask the board to try and formulate a plan for growing
> new cross project leaders (not just TC / PTLs). We need to grow more
> technical contributors in the horizontal teams, which requires more
> than assigning a contributor to the QA / Infra / Olso / Docs teams
> for a year or so - the people should be allowed a certain amount
> of stability in a role, while not necessarily driving business goals.
>
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Graham Hayes]

On 18/04/18 11:38, Chris Dent wrote:
> On Tue, 17 Apr 2018, Thierry Carrez wrote:
> 
>> So... Is there any specific topic you think we should cover in that
>> meeting ?
> 
> The topics:
> 
> 1. What are we to do, as a community, when external pressures for
> results are not matched by contribution of resources to produce
> those results? There are probably several examples of this, but one
> that I'm particularly familiar with is the drive to be able to
> satisfy complex hardware topologies demanded by virtual network
> functions and related NFV use cases. Within nova, and I suspect other
> projects, there is intense pressure to make progress and intense
> effort that is removing resources from other areas. But the amount
> of daily, visible contribution from the interest companies [1] is
> _sometimes_ limited. There are many factors in this, and obviously
> "throw more people at it" is not a silver bullet, but there are
> things to talk about here that need the input from all the segments.
> 
> 2. We've made progress of late with acknowledging the concepts
> and importance of casual contribution and "drive-by bug fixing" in
> our changing environment. But we've not yet made enough progress in
> changing the way we do work. Corporate foundation members need to be
> more aware and more accepting that the people they provide to work
> "mostly upstream" need to be focused on making other people capable
> of contribution. Not on getting features done. And those of us who
> do have the privilege of being "mostly upstream" need to adjust our
> priorities.
> 
> Somewhere in that screed are, I think, some things worth talking
> about, but they need to be distilled out.
> 
> [1] http://superuser.openstack.org/articles/5g-open-source-att/


I think as an add on to this, would to ask the board to talk to members
and see what contributions they have made to the technical side of
OpenStack.

This should not just be Number of commits / reviews / bugs etc but
also the motivation for the work, e.g. - Feature for a product, bug fix
found in a product, cross project work or upstream project maintenance.

I don't necessarily want to shame corporate members of the foundation,
but I think it is important to understand where our contributor base
comes from, and what each member brings to the community table.

We should also ask the board to try and formulate a plan for growing
new cross project leaders (not just TC / PTLs). We need to grow more
technical contributors in the horizontal teams, which requires more
than assigning a contributor to the QA / Infra / Olso / Docs teams
for a year or so - the people should be allowed a certain amount
of stability in a role, while not necessarily driving business goals.

> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Chris Dent]

On Tue, 17 Apr 2018, Thierry Carrez wrote:


So... Is there any specific topic you think we should cover in that
meeting ?


I'll bite. I've got two topics that I think are pretty critical to
address with the various segments of the community that are the
source of code commits and reviews. Neither of these are
specifically Board issues but are things are that I think are pretty
critical to discuss and address, and topics for which corporate
members of the foundation ought to be worried about.

These aren't fully formed ideas or questions, but I hope that before
we get to Vancouver they might evolve into concrete agenda items
with the usual feedback loops in email. I figure it is better to get
the ball rolling early than wait for perfection.

In the past on topics like this we've said "usually it's not the
right people at the board meeting to make headway on these kinds of
things". That's not our problem nor our responsibility. If the
people at the board meetings are designated representatives of the
corporate members it's their responsibility to hear our issues and
respond appropriately (even if that means, over the long term,
changing the people that are there). The health and productivity of
the community is what we should be concerned with.

The topics:

1. What are we to do, as a community, when external pressures for
results are not matched by contribution of resources to produce
those results? There are probably several examples of this, but one
that I'm particularly familiar with is the drive to be able to
satisfy complex hardware topologies demanded by virtual network
functions and related NFV use cases. Within nova, and I suspect other
projects, there is intense pressure to make progress and intense
effort that is removing resources from other areas. But the amount
of daily, visible contribution from the interest companies [1] is
_sometimes_ limited. There are many factors in this, and obviously
"throw more people at it" is not a silver bullet, but there are
things to talk about here that need the input from all the segments.

2. We've made progress of late with acknowledging the concepts
and importance of casual contribution and "drive-by bug fixing" in
our changing environment. But we've not yet made enough progress in
changing the way we do work. Corporate foundation members need to be
more aware and more accepting that the people they provide to work
"mostly upstream" need to be focused on making other people capable
of contribution. Not on getting features done. And those of us who
do have the privilege of being "mostly upstream" need to adjust our
priorities.

Somewhere in that screed are, I think, some things worth talking
about, but they need to be distilled out.

[1] http://superuser.openstack.org/articles/5g-open-source-att/

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] Topics for the Board+TC+UC meeting in Vancouver

[Thierry Carrez]

Hi everyone,

As you know the Technical Committee (the governance body representing
contributors producing OpenStack software) meets with other OpenStack
governance bodies (Board of Directors and User Committee) on the Sunday
before every Summit, and Vancouver will be no exception.

At the TC retrospective Forum session in Sydney we decided we should
more broadly ask our constituency for topics they would like us to cover
in that discussion.

Once the current election cycle is over and the new TC chair is picked,
we'll come up with a proposed agenda and submit it to the Chairman of
the Board for consideration.

So... Is there any specific topic you think we should cover in that
meeting ?

-- 
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev