[tc] Campaign Question: Treating the Problem, not just the symptoms- Burnout, No Polling, etc

Kendall Nelson kennelson11 at gmail.com
Wed Sep 4 19:35:28 UTC 2019


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.html
[2]
http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009087.html
[3]
http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009101.html
[4] https://etherpad.openstack.org/p/PVG-u-series-goals
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190904/ae47801d/attachment.html>


More information about the openstack-discuss mailing list