On 05/11/2018 02:00 PM, 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?
>
> 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.
I can think of a couple good example problems that probably fall into
the category you've described. But, I wouldn't say it was solely because
two or more projects were convinced the problem exists and it wasn't
their responsibility (IMO, that at least seems like a broad
generalization of the root of why cross-project issues take a long time).
For example, the push for default roles surfaced in 2015 as an
OpenStack-wide specification, but lost steam when we realized just how
terrible the migration path would be for users. Eventually, a solution
for that migration issue made it's way into the commons (oslo.policy)
and enabled a Queens community goal. I think the leadership established
through community goals makes this kind of work possible, even if it
does take a while.
>
> 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)
This sounds like the group of people who propose, review, and implement
community goals.
>
> 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 [***@gmail.com]
> Sent: Friday, May 11, 2018 9:31 AM
> To: openstack-***@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-***@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-***@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev