Chris,

Thank you for your questions.  I agree that not having the election deprived the community of a chance to get to know the candidates better so I am happy to help out here.  :-)

Hope my thoughts in-line below make sense!

Jay

On 9/4/2019 5:32 AM, Chris Dent wrote:

On Wed, 4 Sep 2019, Jeremy Stanley wrote:

...

Thank you to all candidates who put their name forward for Project Team Lead (PTL) and Technical Committee (TC) in this election. A healthy, open process breeds trust in our decision making capability thank you to all those who make this process possible.

Congratulations and thank you to the people taking on these roles.

We need to talk about the fact that there was no opportunity to vote in these "elections" (PTL or TC) because there were insufficient candidates. No matter the quality of new leaders (this looks like a good group), something is amiss. We danced around these issue for the two years I was on the TC, but we never did anything concrete to significantly change things, carrying on doing things in the same way in a world where those ways no longer seemed to fit.

We can't claim any "seem" about it any more: OpenStack governance and leadership structures do not fit and we need to figure out the necessary adjustments.

I was surprised that we didn't have any PTL elections.  I don't know that this is all bad.  At least in the case of the Cinder team it seems to be a process that we have just kind-of internalized.  I got my chance to be PTL and was ready for a break.  I had reached out to Brian Rosmaita some time ago and had been grooming him to take over.  I had discussions with other people knew Brian was interested, so we went forward that way.

I think this is a natural progression for where OpenStack is at right now.  There isn't a lot of contention over how the project needs to be  run right now.  In the future that may change and I think having our election process is important for if and when that happens.

I haven't got any new ideas (which is part of why I left the TC). My position has always been that with a vendor and enterprise led project like OpenStack, where those vendors and enterprises are operating in a huge market, staffing the commonwealth in a healthy fashion is their responsibility. In large part because they are responsible for making OpenStack resistant to "casual" contribution in the first place (e.g., "hardware defined software").

We get people, sometimes, but it is not healthy:

i may see different cross-sections of the community than others     do, but i feel like there's been a strong tone of burnout since     2012 [1]

This is a very real concern for me.  We do have a very few people who have taken over a lot of responsibility for OpenStack and are getting burned out.  We also need to have more companies start investing in OpenStack again.  We can't, however, force them to participate.

I know from my last year or so at Lenovo that there are customers with real interest in OpenStack.  OpenStack is running in the real world.  I don't know if it is just working for people or if the customers are modifying it themselves and not contributing back. It would be interesting to get numbers on this.  Not sure how we can do that.  I am afraid, in the past, that the community got a reputation of being 'too hard to contribute to'.  If that perception is still hurting us now it is something that we need to address.

I think that some of the lack of participation is also due to cultural differences in the geos where OpenStack has been expanding.  That is a very hard problem to address.

We drastically need to change the expectations we place on ourselves in terms of velocity.

[1] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019-...

...

Ghanshyam Mann (gmann)  Jean-Philippe Evrard (evrardjp)  Jay Bryant (jungleboyj)  Kevin Carter (cloudnull)  Kendall Nelson (diablo_rojo)  Nate Johnston (njohnston)

Since there was no need to vote, there was no need to campaign, which means we will be missing out on the Q&A period. I've found those very useful for understanding the issues that are present in the community and for generating ideas on what to about them. I think it is good to have that process anyway so I'll start:

What do you think we, as a community, can do about the situation described above? What do you as a TC member hope to do yourself?

I addressed this a bit in my candidacy note.  I think that we need to continue to improve our education and on-boarding processes.  Though I don't think it is hard to contribute successfully to OpenStack, there is a lot of tribal knowledge required to be successful in OpenStack.  Documenting those things will help.

I would like to work with the foundation to reach out to companies and find out why they are less likely to participate than they used to be.  People are using OpenStack ... why aren't they contributing.  Perhaps it is a question that we could add to the user survey.  I know when I had the foundation reach out to companies that were about to lose their drivers from Cinder, we got responses.  So, I think that is a path we could consider.

Thanks

Chris Dent wrote:

[...] We need to talk about the fact that there was no opportunity to vote in these "elections" (PTL or TC) because there were insufficient candidates. No matter the quality of new leaders (this looks like a good group), something is amiss.

The reality is, with less hype around OpenStack, it's just harder to justify the time you spend on "stewardship" positions. The employer does not value having their employees hold those positions as much as they used to. That affects things like finding volunteers to officiate elections, finding candidates for the TC, and also finding PTLs for every project.

As far as PTL/TC elections are concerned I'd suggest two things:

- reduce the number of TC members from 13 to 9 (I actually proposed that 6 months ago at the PTG but that was not as popular then). A group of 9 is a good trade-off between the difficulty to get enough people to do project stewardship and the need to get a diverse set of opinions on governance decision.

- allow "PTL" role to be multi-headed, so that it is less of a superhuman and spreading the load becomes more natural. We would not elect/choose a single person, but a ticket with one or more names on it. From a governance perspective, we still need a clear contact point and a "bucket stops here" voice. But in practice we could (1) contact all heads when we contact "the PTL", and (2) consider that as long as there is no dissent between the heads, it is "the PTL voice". To actually make it work in practice I'd advise to keep the number of heads low (think 1-3).

[...] We drastically need to change the expectations we place on ourselves in terms of velocity.

In terms of results, train cycle activity (as represented by merged commits/day) is globally down 9.6% compared to Stein. Only considering "core" projects, that's down 3.8%.

So maybe we still have the same expectations, but we are definitely reducing our velocity... Would you say we need to better align our expectations with our actual speed? Or that we should reduce our expectations further, to drive velocity further down?

---- On Thu, 05 Sep 2019 19:04:39 +0900 Chris Dent cdent+os@anticdent.org wrote ----

On Thu, 5 Sep 2019, Thierry Carrez wrote:

...

So maybe we still have the same expectations, but we are definitely reducing our velocity... Would you say we need to better align our expectations with our actual speed? Or that we should reduce our expectations further, to drive velocity further down?

We should slow down enough that the vendors and enterprises start to suffer. If they never notice, then it's clear we're trying too hard and can chill out.

+1 on this but instead of slow down and make vendors suffer we need the proper way to notify or make them understand about the future cutoff effect on OpenStack as software. I know we have been trying every possible way but I am sure there are much more managerial steps can be taken. I expect Board of Director to come forward on this as an accountable entity. TC should raise this as high priority issue to them (in meetings, joint leadership meeting etc).

I am sure this has been brought up before, can we make OpenStack membership company to have a minimum set of developers to maintain upstream. With the current situation, I think it make sense to ask them to contribute manpower also along with membership fee. But again this is more of BoD and foundation area.

I agree on ttx proposal to reduce the TC number to 9 or 7, I do not think this will make any difference or slow down on any of the TC activity. 9 or 7 members are enough in TC.

As long as we get PTL(even without an election) we are in a good position. This time only 7 leaderless projects (6 actually with Cyborg PTL missing to propose nomination in election repo and only on ML) are not so bad number. But yes this is a sign of taking action before it goes into more worst situation.

-gmann

-- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

On 5/09/19 7:36 AM, Tom Barron wrote:

On 05/09/19 19:33 +0900, Ghanshyam Mann wrote:

...

---- On Thu, 05 Sep 2019 19:04:39 +0900 Chris Dent cdent+os@anticdent.org wrote ----

...

On Thu, 5 Sep 2019, Thierry Carrez wrote:

...

So maybe we still have the same expectations, but we are

definitely reducing

...

...

our velocity... Would you say we need to better align our

expectations with

...

...

our actual speed? Or that we should reduce our expectations

further, to drive

...

...

velocity further down?

We should slow down enough that the vendors and enterprises start to suffer. If they never notice, then it's clear we're trying too hard and can chill out.

+1 on this but instead of slow down and make vendors suffer we need the proper way to notify or make them understand about the future cutoff effect on OpenStack as software. I know we have been trying every possible way but I am sure there are much more managerial steps can be taken.  I expect Board of Director to come forward on this as an accountable entity. TC should raise this as high priority issue to them (in meetings, joint leadership meeting etc).

I am sure this has been brought up before, can we make OpenStack membership company to have a minimum set of developers to maintain upstream. With the current situation, I think it make sense to ask them to contribute manpower also along with membership fee.  But again this is more of BoD and foundation area.

+1

IIUC Gold Membership in the Foundation provides voting privileges at a cost of $50-200K/year and Corporate Sponsorship provides these plus various marketing benefits at a cost of $10-25K/year.  So far as I can tell there is not a requirement of a commitment of contributors and maintainers with the exception of the (currently closed) Platinum Membership, which costs $500K/year and requires at least 2 FTE equivalents contributing to OpenStack.

Even this incredibly minimal requirement was famously not met for years by one platinum member, and a (different) platinum member was accepted without ever having contributed upstream in the past or apparently ever intending to in the future.

What I'm saying is that if this a the mechanism we want to use to drive contributions, I can tell you now how it's gonna work out.

The question we should be asking ourselves is why companies see value in being sponsors of the foundation but not in contributing upstream, and how we convince them of the value of the latter.

One initiative the TC started on this front is this:

https://governance.openstack.org/tc/reference/upstream-investment-opportunit...

(BTW we could use help in converting the outdated Help Most Wanted entries to this format. Volunteers welcome.)

cheers, Zane.

In general I see requirements for annual cash expenditure to the Foundation, as for membership in any joint commercial enterprise, but little that ensures the availability of skilled labor for ongoing maintenance of our projects.

-- Tom Barron

...

I agree on ttx proposal to reduce the TC number to 9 or 7, I do not think this will make any difference or slow down on any of the TC activity. 9 or 7 members are enough in TC.

As long as we get PTL(even without an election) we are in a good position. This time only 7 leaderless projects (6 actually with Cyborg PTL missing to propose nomination in election repo and only on ML) are not so bad number. But yes this is a sign of taking action before it goes into more worst situation.

-gmann

...

-- Chris Dent                       ٩◔̯◔۶           https://anticdent.org/ freenode: cdent

On 06/09/19 13:44 -0400, Zane Bitter wrote:

On 5/09/19 7:36 AM, Tom Barron wrote:

...

IIUC Gold Membership in the Foundation provides voting privileges at a cost of $50-200K/year and Corporate Sponsorship provides these plus various marketing benefits at a cost of $10-25K/year.  So far as I can tell there is not a requirement of a commitment of contributors and maintainers with the exception of the (currently closed) Platinum Membership, which costs $500K/year and requires at least 2 FTE equivalents contributing to OpenStack.

Even this incredibly minimal requirement was famously not met for years by one platinum member, and a (different) platinum member was accepted without ever having contributed upstream in the past or apparently ever intending to in the future.

What I'm saying is that if this a the mechanism we want to use to drive contributions, I can tell you now how it's gonna work out.

I expect that you are right but if anyone has references to past communications between TC and Foundation about participation requirements or expectations for Members and Sponsors I'd appreciate pointers to these. (By analogy, it's helpful to know who has made commitments to the Paris Agreement [1], who has not, and actual track records even if one is not convinced that the agreement is going to work out.)

[1] https://en.wikipedia.org/wiki/Paris_Agreement

The question we should be asking ourselves is why companies see value in being sponsors of the foundation but not in contributing upstream, and how we convince them of the value of the latter.

Participating companies are complex organizations whose decision makers have a mix of motives and goals, but functionally I think the classic tragedy of the commons model fits pretty well. It may be worth $50-500/K per year to foster the perception that one is a supporter or contributor to OpenStack, and to get the various marketing advantages that come along, even if one doesn't actively contribute to or maintain the software or community beyond that.

One initiative the TC started on this front is this:

https://governance.openstack.org/tc/reference/upstream-investment-opportunit...

(BTW we could use help in converting the outdated Help Most Wanted entries to this format. Volunteers welcome.)

Reframing "Help Wanted" as "Investment Opportunities" is IMO a great idea. There were seven entries for 2018 and there is one for 2019. Did the other six get done or does the help solicited amount to submitting governance reviews like the one you did for Glance [2] for the remaining 2018 items?

[2] https://review.opendev.org/#/c/668054/

On 9/5/2019 5:33 AM, Ghanshyam Mann wrote:

---- On Thu, 05 Sep 2019 19:04:39 +0900 Chris Dent cdent+os@anticdent.org wrote ----

...

On Thu, 5 Sep 2019, Thierry Carrez wrote:

...

So maybe we still have the same expectations, but we are definitely reducing our velocity... Would you say we need to better align our expectations with our actual speed? Or that we should reduce our expectations further, to drive velocity further down?

We should slow down enough that the vendors and enterprises start to suffer. If they never notice, then it's clear we're trying too hard and can chill out.

+1 on this but instead of slow down and make vendors suffer we need the proper way to notify or make them understand about the future cutoff effect on OpenStack as software. I know we have been trying every possible way but I am sure there are much more managerial steps can be taken. I expect Board of Director to come forward on this as an accountable entity. TC should raise this as high priority issue to them (in meetings, joint leadership meeting etc).

Agreed.  I think that partially falls into the community's hands itself.  I have spent years advocating for OpenStack in my company and have started having success.  The problem is that it is a slow process.  I am hoping that others are doing the same and we will start seeing a reverse in the trend.  Otherwise, I think we need help from the foundation leadership to reach out and start re-engaging companies.

I am sure this has been brought up before, can we make OpenStack membership company to have a minimum set of developers to maintain upstream. With the current situation, I think it make sense to ask them to contribute manpower also along with membership fee. But again this is more of BoD and foundation area.

I had this thought, but it is quite likely that then I would not be able to contribute anymore.  :-(  So, I fear that could be a slippery slope for many people.

I agree on ttx proposal to reduce the TC number to 9 or 7, I do not think this will make any difference or slow down on any of the TC activity. 9 or 7 members are enough in TC.

As long as we get PTL(even without an election) we are in a good position. This time only 7 leaderless projects (6 actually with Cyborg PTL missing to propose nomination in election repo and only on ML) are not so bad number. But yes this is a sign of taking action before it goes into more worst situation.

-gmann

...

-- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

On Sep 5, 2019, at 6:04 AM, Chris Dent cdent+os@anticdent.org wrote:

On Thu, 5 Sep 2019, Thierry Carrez wrote:

...

So maybe we still have the same expectations, but we are definitely reducing our velocity... Would you say we need to better align our expectations with our actual speed? Or that we should reduce our expectations further, to drive velocity further down?

We should slow down enough that the vendors and enterprises start to suffer. If they never notice, then it's clear we're trying too hard and can chill out.

As much as I support the labor movement, I don’t think *starting* from an adversarial “we’ll show them!” position with our employers and potential contributors is the most effective way to establish the sort of change we want. It would much more likely instill the idea that this community won’t work with new contributors, which isn’t going to be any healthier than the current situation over the long term.

That said, I do agree with the “chill out” approach.

Do what you can and then emphasize collaboration over doing things for non-contributors, to turn them into contributors. Be honest about the need for help, and clear about what sort of help is needed, so that someone who *is* motivated can get involved. And make it easy for others to join and fulfill those needs, so the bureaucracy doesn’t demotivate them into looking for other communities to join instead.

Also, accept that either approach is going to mean things will not be done, and that is OK. Look for ways to minimize the amount of effort for tasks that must be done, but let “good ideas” go. If they’re good enough, and you make it possible for others to contribute, someone will step up. But if that doesn’t happen, it should not be a source of stress for anyone. That means the “good idea” doesn’t meet the bar of economic viability.

Doug

On Thu, Sep 05, 2019 at 11:59:22AM +0200, Thierry Carrez wrote:

Chris Dent wrote:

...

[...] We need to talk about the fact that there was no opportunity to vote in these "elections" (PTL or TC) because there were insufficient candidates. No matter the quality of new leaders (this looks like a good group), something is amiss.

The reality is, with less hype around OpenStack, it's just harder to justify the time you spend on "stewardship" positions. The employer does not value having their employees hold those positions as much as they used to. That affects things like finding volunteers to officiate elections, finding candidates for the TC, and also finding PTLs for every project.

As far as PTL/TC elections are concerned I'd suggest two things:

• reduce the number of TC members from 13 to 9 (I actually proposed that 6

months ago at the PTG but that was not as popular then). A group of 9 is a good trade-off between the difficulty to get enough people to do project stewardship and the need to get a diverse set of opinions on governance decision.

• allow "PTL" role to be multi-headed, so that it is less of a superhuman

and spreading the load becomes more natural. We would not elect/choose a single person, but a ticket with one or more names on it. From a governance perspective, we still need a clear contact point and a "bucket stops here" voice. But in practice we could (1) contact all heads when we contact "the PTL", and (2) consider that as long as there is no dissent between the heads, it is "the PTL voice". To actually make it work in practice I'd advise to keep the number of heads low (think 1-3).

I think there was already an effort to allow the PTL to shed some of their duties, in the form of the Cross Project Liaisons [1] project. I thought that was a great way for more junior members of the community to get involved with stewardship and be recognized for that contribution, and perhaps be mentored up as they take a bit of load off the PTL. I think if we expand the roles to include more of the functions that PTLs feel the need to do themselves, then by doing so we (of necessity) document those parts of the job so that others can handle them. And perhaps projects can cooperate and pool resources - for example, the same person who is a liaison for Neutron to Oslo could probably be on the look out for issues of interest to Octavia as well, and so on.

I think that this looks different for projects of different size; large projects can spread it out a bit, while for smaller ones more of a "triumvirate" approach would likely develop.

Nate

[1] https://wiki.openstack.org/wiki/CrossProjectLiaisons for those not familiar

...

[...] We drastically need to change the expectations we place on ourselves in terms of velocity.

In terms of results, train cycle activity (as represented by merged commits/day) is globally down 9.6% compared to Stein. Only considering "core" projects, that's down 3.8%.

So maybe we still have the same expectations, but we are definitely reducing our velocity... Would you say we need to better align our expectations with our actual speed? Or that we should reduce our expectations further, to drive velocity further down?

-- Thierry Carrez (ttx)

On 9/6/19 3:48 AM, Thierry Carrez wrote:

Nate Johnston wrote:

...

On Thu, Sep 05, 2019 at 11:59:22AM +0200, Thierry Carrez wrote:

...

• allow "PTL" role to be multi-headed, so that it is less of a

superhuman and spreading the load becomes more natural. We would not elect/choose a single person, but a ticket with one or more names on it. From a governance perspective, we still need a clear contact point and a "bucket stops here" voice. But in practice we could (1) contact all heads when we contact "the PTL", and (2) consider that as long as there is no dissent between the heads, it is "the PTL voice". To actually make it work in practice I'd advise to keep the number of heads low (think 1-3).

I think there was already an effort to allow the PTL to shed some of their duties, in the form of the Cross Project Liaisons [1] project.  I thought that was a great way for more junior members of the community to get involved with stewardship and be recognized for that contribution, and perhaps be mentored up as they take a bit of load off the PTL.  I think if we expand the roles to include more of the functions that PTLs feel the need to do themselves, then by doing so we (of necessity) document those parts of the job so that others can handle them.  And perhaps projects can cooperate and pool resources - for example, the same person who is a liaison for Neutron to Oslo could probably be on the look out for issues of interest to Octavia as well, and so on.

Cross-project liaisons are a form of delegation. So yes, PTLs already can (and probably should) delegate most of their duties. And in a lot of teams it already works like that. But we have noticed that it can be harder to delegate tasks than share tasks. Basically, once someone is the PTL, it is tempting to just have them do all the PTL stuff (since they will do it by default if nobody steps up).

That makes the job a bit intimidating, and it is sometimes hard to find candidates to fill it. If it's clear from day 0 that two or three people will share the tasks and be collectively responsible for those tasks to be covered, it might be less intimidating (easier to find 2 x 50% than 1 x 100% ?).

Just to play a bit of devil's advocate here, in many cases if a problem is everyone's problem then it becomes no one's problem because everyone assumes someone else will deal with it. This is why it usually works better to ask a specific person to volunteer for something than to put out a broad call for *someone* to volunteer. That said, maybe this ties into what Doug wrote earlier that if something doesn't get done maybe it wasn't that important in the first place. I'm not entirely sure I agree with that, but if it's going to be our philosophy going forward then this might be a non-issue.

I'll also say that for me specifically, having the PTL title gives me a lever to use downstream. People don't generally question you spending time on a project you're leading. The same isn't necessarily true of being a core to whom PTL duties were delegated.

Again, I'm not necessarily opposed to this, I just want to point out some potential drawbacks from my perspective.

• reduce the number of TC members from 13 to 9 (I actually proposed

that 6 months ago at the PTG but that was not as popular then). A group of 9 is a good trade-off between the difficulty to get enough people to do project stewardship and the need to get a diverse set of opinions on governance decision.

I am in support of this.  Seems appropriate to support the level of participation in OpenStack.

• allow "PTL" role to be multi-headed, so that it is less of a

superhuman and spreading the load becomes more natural. We would not elect/choose a single person, but a ticket with one or more names on it. From a governance perspective, we still need a clear contact point and a "bucket stops here" voice. But in practice we could (1) contact all heads when we contact "the PTL", and (2) consider that as long as there is no dissent between the heads, it is "the PTL voice". To actually make it work in practice I'd advise to keep the number of heads low (think 1-3).

No concerns with this given that it has been something we have unofficially done in Cinder for years.  I couldn't have gotten things done the way I did without help from Sean McGinnis.  Now that the torch has been passed to Brian I plan to continue to support him there.

...

[...] We drastically need to change the expectations we place on ourselves in terms of velocity.

In terms of results, train cycle activity (as represented by merged commits/day) is globally down 9.6% compared to Stein. Only considering "core" projects, that's down 3.8%.

So maybe we still have the same expectations, but we are definitely reducing our velocity... Would you say we need to better align our expectations with our actual speed? Or that we should reduce our expectations further, to drive velocity further down?

In the case of Cinder our velocity is slowing due to reduced review activity.  That is soon going to be a big problem and we have had little luck at encouraging to do more reviews again.  I have also found that we have had to get better at saying 'No' to things.  This is in the interest of avoiding burnout.  There is a lot we want to do but if it isn't a priority for someone it simply isn't going to get done.  Prioritizing the work has become increasingly important.

As has been touched upon in other discussions, I think we have a culture where it is difficult for them to say no to things.  It is great that people care about OpenStack and want to make things happen but it can't be at the cost of people  burning out.  To some extent we need to slow velocity.  If corporations don't step up to start helping out then we must be doing what needs to get done.