[tc] Campaign Question: Treating the Problem, not just the symptoms- Burnout, No Polling, etc
Hello :)
Wanted to split the question Chris Dent asked here[1] into its own thread so people down the road and those tracking it now can find more easily.
To kind of rephrase for everyone (Chris, correct me if I am wrong or not getting all of it): What do you think we, as a community, can do about the lack of candidates for roles like TC or PTL? How can we adjust, as a community, to make our governance structures fit better? In what wasy can we address and prevent burnout?
I think JP[2] and Jay[3] already started to enumerate good ideas on the other thread, so to summarize/ expand/ add to their lists:
- Reducing the number of TC members to 9, and maybe someday down to 7. When we were having polls for every election (maybe not every project) it was at a time where the electorate (and theoretically the number of possible candidates) was also huge. Since we have move past the hype curve and stabilized as a project, the number of polls we've (I say we because I used to be and still plan to help with elections) had to make have decreased. It seems to be a matter of proportions.
- Continuing to improve education and onboarding process. Agreed 100%, but this should be an ongoing focus for everyone too- every contributor TC, PTL, or otherwise. The best way to get more people involved faster is a lower barrier to entry, but we all know that. Yes some things like gerrit and IRC are hard for people to get past and likely won't be changing for our community any time soon, but there are things like that with every community (I don't know if you have ever tried to push patches to k8s but their tagging of PRs is something they are working on making less complicated and better documented). Breaking down the onboarding process we have at the moment into smaller modules and clearly documenting the progression through those modules for new comers to easily find and work through is important. Also, though, having that be the only place that we, as a community, point to (meaning no duplicate information in multiple places like we have today) when new contributors have issues.
- Better documentation of tribal knowledge. I proposed as a community goal for the U release[4], to formalize project specific onboarding information (some teams have already done this) and project specific guides for PTLs (I know we already have the broad strokes for all PTLs documented fairly well, but there's always project specific stuff) so that when there is a turn over mid release, its easier for someone new to step up.
- Utilize the user survey to gather info about how/why contribution is happening or why they aren't contributing if that's the case. There are already several questions there from the TC about this topic in the survey, but perhaps they can be re-framed if we aren't getting the info we want from them. As a reminder, here they are: -- To which projects does your organization contribute maintenance resources, such as patches for bug fixes and code reviews on master or stable branches? -- What prevents you or your organization from contributing more maintenance resources, or makes contributing difficult? -- How do members of your organization contribute to OpenStack? I think the real issue is getting larger vendors of OpenStack to get their users to take the user survey. We have a pretty solid reach as it is, but there are a lot of people using OpenStack that don't take the survey that we don't know about even because they are confidential (their results can still be confidential if they take the survey).
- Longer release cycle. I know this has come up a dozen or more times (and I'm a little sorry for bringing it up again), but I think OpenStack has stabilized enough that 6 months is a little short and now may finally be the time to lengthen things a bit. 9 months might be a better fit. With longer release cycles comes more time to get work done as well which I've heard has been a complaint of more part time contributors when this discussion has come up in the past.
- Co-PTL type position? I've noticed and talked to several PTLs on a variety of projects that need a little extra help with the role. They either don't feel like they have all the experience they need to be PTL yet and so they want the previous PTL to help out still or maybe they want to do it, but there are enough variables in their day to day work (or lack of overlap tz wise with most of the other contributors to that project), that having a backup person to help out and backfill when they need help.
- Talking to each other. I really honestly think just talking to one another could help too. When you find yourself in a conversation with someone about how unmotivated they are because they have a ton of work to do. You might offer to take something off their plate. Or help them see maybe they need to not take on anything new till some other work gets wrapped up. We are a community that succeeds together, so if you see someone burning themselves out do what you can to help lighten their load (helping directly is great, but there are plenty of other people in our community that you could call on to help too). Hopefully goes without saying, but don't burn yourself out trying to help someone else either.
Some of these things are more actionable, others are still high level and need to have concrete actions tied to them, but I think there are plenty of things we can do to make progress here.
-Kendall (diablo_rojo)
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009084... [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009087... [3] http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009101... [4] https://etherpad.openstack.org/p/PVG-u-series-goals
On Sep 4, 2019, at 3:35 PM, Kendall Nelson kennelson11@gmail.com wrote:
- Talking to each other. I really honestly think just talking to one another could help too. When you find yourself in a conversation with someone about how unmotivated they are because they have a ton of work to do. You might offer to take something off their plate. Or help them see maybe they need to not take on anything new till some other work gets wrapped up. We are a community that succeeds together, so if you see someone burning themselves out do what you can to help lighten their load (helping directly is great, but there are plenty of other people in our community that you could call on to help too). Hopefully goes without saying, but don't burn yourself out trying to help someone else either.
I would take this a step further, and remind everyone in leadership positions that your job is not to do things *for* anyone, but to enable others to do things *for themselves*. Open source is based on collaboration, and ensuring there is a healthy space for that collaboration is your responsibility. You are neither a free workforce nor a charity. By all means, you should help people to achieve their goals in a reasonable way by reducing barriers, simplifying processes, and making tools reusable. But do not for a minute believe that you have to do it all for them, even if you think they have a great idea. Make sure you say “yes, you should do that” more often than “yes, I will do that."
Doug
On 2019-09-04 16:53:20 -0400 (-0400), Doug Hellmann wrote:
On Sep 4, 2019, at 3:35 PM, Kendall Nelson kennelson11@gmail.com wrote:
[...]
Hopefully goes without saying, but don't burn yourself out trying to help someone else either.
This is the point in the flight safety demonstration where we remind passengers to affix their own oxygen masks before assisting others.
I would take this a step further, and remind everyone in leadership positions that your job is not to do things *for* anyone, but to enable others to do things *for themselves*. Open source is based on collaboration, and ensuring there is a healthy space for that collaboration is your responsibility. You are neither a free workforce nor a charity. By all means, you should help people to achieve their goals in a reasonable way by reducing barriers, simplifying processes, and making tools reusable. But do not for a minute believe that you have to do it all for them, even if you think they have a great idea. Make sure you say “yes, you should do that” more often than “yes, I will do that."
And also, as has been suggested to some extent in other responses on this thread, if there are expected things go undone because there's nobody who has available time to do them, then it's a distinct possibility those things weren't necessary in the first place.
On Wed, 4 Sep 2019, Doug Hellmann wrote:
I would take this a step further, and remind everyone in leadership positions that your job is not to do things *for* anyone, but to enable others to do things *for themselves*. Open source is based on collaboration, and ensuring there is a healthy space for that collaboration is your responsibility. You are neither a free workforce nor a charity. By all means, you should help people to achieve their goals in a reasonable way by reducing barriers, simplifying processes, and making tools reusable. But do not for a minute believe that you have to do it all for them, even if you think they have a great idea. Make sure you say “yes, you should do that” more often than “yes, I will do that."
This is very true, but I think it underestimates the many different forces that are involved in "doing work in OpenStack". These are, of course, very different from person to person, but I've got some observations (of course I do, everyone should). I suspect some of these are unique to my experience, but I suspect some of them are not. It would be useful (to me at least) to know where some of us have had similar experiences.
Most people work on OpenStack because it is their job or is closely related to their job. But because it is "open source" and "a community" and "collaborative" doing what people ask for and helping others achieve what they need is but one small piece of the motivation and action calculus.
Making "it" (various things: code, community, product, experiences of various kinds) "better" (again, very subjective and multi-dimensional) is very complicated.
And it is further complicated by the roadblocks that can come up in the community. In the other thread that started this Sean said:
the reason that the investment that was been made was reducing was not driven by the lack of hype but by how slow adding some feature that really mattered [1]
One aspect of burn out comes from the combination of weathering these roadblocks and having a kind of optimism that says "I can, somehow change this or overcome this."
Another is simply a dedication to quality, no matter the obstacles. This is tightly coupled with Sean's comments above. Improving the "developer experience" is rarely a priority and gets pushed on the back burner unless you dedicate the time to being core or PTL, which grants some license to "getting code merged". For some projects that is a _huge_ undertaking.
My relatively good success at overcoming the obstacles but limited (that is, constrained to a small domain) at changing the root causes is why I'm now advocating chilling out. This is risky because the latency between code and related work done now and any feedback is insanely high. The improvements we've made recently to placement won't be in common use for 6 months to 3 years, depending on how we measure "common". Detaching or chilling out now doesn't have an impact for some time.
That feedback latency also means figuring out what "better" or "quality" mean for a project is a guessing game.
Making cycles longer will make that worse.
A year ago when we started extracting placement I tried to make real the idea that full time cores should rarely write feature code and primarily be involved in helping "people to achieve their goals in a reasonable way by reducing barriers, simplifying processes, and making tools reusable". This only sort of worked. There were issues:
* There were feature goals, but few people to do the work.
* Our (OpenStack's) long term standards for what is or is not a barrier, good process and tooling are historically so low that bring them up to spec requires a vast amount of work.
To me, the Placement changes made in Train were needed so that Placement could make a respectable claim to being "good". 75% of the changes (counting by commit) were made by 4 people. 43% by one. [2]
The large amount of time required to be core, PTL or "get their code merged pretty easily" (in some projects) is a big portion of any job and given the contraction of interest in the community (but not in the product) from plenty of companies, there is lurking fear that the luxury of making that commitment, of being a "unicorn 100% upstream", will go away at any time. This increases the need to do all those "make it better" things _now_.
Which, obviously, is a trap, and people who feel like that would be better off if they chilled out, but I would guess that people who feel that way do so because making it better (whatever it is) is important in and of itself. Especially when the lack of commitment from enterprises is waning: they don't care, so I must, because I care.
In other projects, there's simply no one there to become core or a reluctance to get into leadership because it is perceived to be too time consuming (because for many people in leadership, the time consumption is very visible).
Similarly, when there's a sense of waning interest, the guessing game described above for determining what matters is pressurized. "If I get this wrong, the risk of our irrelevance or even demise is increased, don't mess this up!".
Also a trap.
But both traps are compelling.
I think we need to investigate changing our governance and leadership structures. We should have evolved away from them, but we haven't because power always strives to maintain itself even when it is no longer fit for purpose. TC, PTL, Core and even "projects" all need rigorous review and reconsideration to see if they are really supporting us ("us" in this case is "the people who make OpenStack") the way they should.
If we are unable or unwilling to do that, then we need to enforce "contributing" enterprises to contribute sufficient resources to prop up the old power structures. [3]
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009123...
[2] That is, assuming stackalytics is correct today, it often isn't.
[3] Perversely, I think this option (companies paying up) is the fundamentally right one from an economic standpoint, but that is because I don't believe that OpenStack is (currently and through the peak of its history) open source. It is collaborative inter-enterprise development that allows large companies to have a market in which they make a load of money. That takes money and people. If OpenStack were simpler and more contained and tried less hard to satisfy everyone, it could operate as an underlay (much like Linux) to some other market but for now it is the market.
The pains we are having now may be the signs of a need for a shift to being an underlay (k8s and others are the new keen market now). If that's the case we can accelerate that shift by narrowing what we do. Trimming the fat. Making OpenStack much more turnkey with far fewer choices.
But again, the current batch of engaged enterprises have not shown signs of wanting that narrowing. So they either need to change what they want or cough up the resources to support what they want in a healthy fashion.
What we should do is strive to be healthy, whatever else happens.
On 2019-09-06 13:27:53 +0100 (+0100), Chris Dent wrote: [...]
Most people work on OpenStack because it is their job or is closely related to their job. But because it is "open source" and "a community" and "collaborative" doing what people ask for and helping others achieve what they need is but one small piece of the motivation and action calculus.
[...]
I don't know that this captures my motivation, at least. I chose my job so that I could assist in the creation and maintenance of OpenStack and similar free software, not the other way around. Maybe I'm in a minority within the community, but I suspect there are more folks than just me who feel the same.
I don't believe that OpenStack is (currently and through the peak of its history) open source. It is collaborative inter-enterprise development that allows large companies to have a market in which they make a load of money.
[...]
Yes, making these tasks easier and less expensive for "large companies" like CERN, SKA, MOC, and all manner of other research and educational organizations is what causes this work to be worthwhile for me. I like that what we do provides a positive contribution to the sum total knowledge of our species. I personally think this aspect can't be overstated.
What we do matters beyond the desire and ability for some self-serving commercial enterprises to take and give nothing back. The nature of modern business is exploitation, but it's not as if the commons of free software is the only resource they're exploiting to their own gain. I'm all for the people of our planet coming together to fight injustice or abuse by corporate and political powers, but the problem extends far, far beyond our community and pretending we can solve such abuse and oppression within OpenStack without looking at the bigger picture is short-sighted and naive.
I'm disappointed that you don't think the software you're making is open source. I think the software I'm making is open source, and if I didn't I wouldn't be here.
On Fri, 6 Sep 2019, Jeremy Stanley wrote:
I'm disappointed that you don't think the software you're making is open source. I think the software I'm making is open source, and if I didn't I wouldn't be here.
I'm disappointed too, I hope I've made that obvious.
As I said at the start: everyone has different experiences. You and I have different ones, that is _good_.
The reason I have stayed in OpenStack is because I've wanted to make it more "open source".
So I think we're working to similar ends, but starting from different points. Again: that is _good_.
On 06/09/19 13:10 +0000, Jeremy Stanley wrote:
On 2019-09-06 13:27:53 +0100 (+0100), Chris Dent wrote: [...]
Most people work on OpenStack because it is their job or is closely related to their job. But because it is "open source" and "a community" and "collaborative" doing what people ask for and helping others achieve what they need is but one small piece of the motivation and action calculus.
[...]
I don't know that this captures my motivation, at least. I chose my job so that I could assist in the creation and maintenance of OpenStack and similar free software, not the other way around. Maybe I'm in a minority within the community, but I suspect there are more folks than just me who feel the same.
Me too, though I'm fortunate enough to have an employer who genuinely values open source work, including building and fostering open source communities. I've worked for others where open source work was always only an instrumental goal, not an end in itself -- indeed I think it was sometimes considered a necessary evil.
-- Tom
On Fri, 6 Sep 2019 at 15:14, Jeremy Stanley fungi@yuggoth.org wrote:
On 2019-09-06 13:27:53 +0100 (+0100), Chris Dent wrote: [...]
Most people work on OpenStack because it is their job or is closely related to their job. But because it is "open source" and "a community" and "collaborative" doing what people ask for and helping others achieve what they need is but one small piece of the motivation and action calculus.
[...]
I don't know that this captures my motivation, at least. I chose my job so that I could assist in the creation and maintenance of OpenStack and similar free software, not the other way around. Maybe I'm in a minority within the community, but I suspect there are more folks than just me who feel the same.
I think that the reality is that not everybody can "chose" his job. Maybe the foundation can start to employ people to take care of the projects with the money received from the sponsors, I'm sure that a lot of folks will step in, not having to take time from his family life and able to dedicate their full time to the project.
On 2019-09-07 11:49:57 +0200 (+0200), Antonio Ojea wrote: [...]
I think that the reality is that not everybody can "chose" his job.
That's a fair point. I've had the luxury of turning down much higher-paying jobs to accept one at a non-profit organization aligned with my ideals. I definitely understand that not everyone can afford to do that. On the other hand, I wonder how many folks who work on OpenStack because their employer tells them they have to, not because they're inspired by the project's goals, are compelled (through the sense of community Chris mentioned in his post) to spend extra unpaid time helping with commons tasks and assisting others... to the point that they're burned out on these activities and decide to go work on something else instead. I don't doubt that there are at least some, but perhaps no more than those who took their jobs because they wanted to help the cause.
I do feel for the part-time/volunteer contributors in our community, particularly since I've spent much of my life as a part-time/volunteer contributor in a number of other free/libre open-source communities myself. I continue trying to find ways to make such "casual" contribution easier, and to see it eventually play a much more influential role in the future of OpenStack. On the other hand, OpenStack is *very* large (the third-most-active open-source project of all time, depending on how you measure that), and whether we like it or not, full-time contributors are responsible for the bulk of what we've built so far. That reality creates processes and bureaucratic structure to streamline efficiency for high-volume contribution, with a trade-off of making "casual" contribution more challenging.
Maybe the foundation can start to employ people to take care of the projects with the money received from the sponsors, I'm sure that a lot of folks will step in, not having to take time from his family life and able to dedicate their full time to the project.
The OSF *does* employ people to help take care of projects with the money received from corporate memberships. If you think the proportion of its funds spent on staff to handle project commons tasks which otherwise go untended is insufficient, please find time to discuss it with your elected Individual Member representatives on the board of directors and convince them to argue for a different balance in the OSF budget. The total budget of the OSF could, however, be compared to that of one small/medium-sized department at a typical member company, so it lacks the capacity to do much on its own and the staff dedicated to this are already spread quite thin as a result.
On Wed, 4 Sep 2019, Kendall Nelson wrote:
To kind of rephrase for everyone (Chris, correct me if I am wrong or not getting all of it): What do you think we, as a community, can do about the lack of candidates for roles like TC or PTL? How can we adjust, as a community, to make our governance structures fit better? In what wasy can we address and prevent burnout?
That's a useful and sufficient summary. Thanks for extracting things out like this. Very good email hygiene.
- Longer release cycle. I know this has come up a dozen or more times (and
I'm a little sorry for bringing it up again), but I think OpenStack has stabilized enough that 6 months is a little short and now may finally be the time to lengthen things a bit. 9 months might be a better fit. With longer release cycles comes more time to get work done as well which I've heard has been a complaint of more part time contributors when this discussion has come up in the past.
As I said in my other message in this thread, in response to Doug, I think that this might be counterproductive in terms of easing burnout. It's probably good for providing more time to get some things done, but it aggravates the pressure and risks involved in trying to predict what matters.
Since I've already said enough over on that message, I'll not add more here.
participants (6)
-
Antonio Ojea
-
Chris Dent
-
Doug Hellmann
-
Jeremy Stanley
-
Kendall Nelson
-
Tom Barron