<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">Hello :) </div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">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. </div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">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? </div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">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:</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">- 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. </div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small"> </div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">- 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. </div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">- 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.</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">- 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: </div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">     -- To which projects does your organization contribute maintenance resources, such as patches for bug fixes and code reviews on master or stable branches?</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">     -- <span style="font-family:Arial,Helvetica,sans-serif">What prevents you or your organization from contributing more maintenance resources, or makes contributing difficult?</span></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small"><span style="font-family:Arial,Helvetica,sans-serif">     -- </span><span style="font-family:Arial,Helvetica,sans-serif">How do members of your organization contribute to OpenStack?</span><span style="font-family:Arial,Helvetica,sans-serif"> </span></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">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).</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">- 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. </div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">- 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. </div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">- 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. </div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">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. </div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">-Kendall (diablo_rojo)</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">[1] <a href="http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009084.html" style="font-family:Arial,Helvetica,sans-serif">http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009084.html</a></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">[2] <a href="http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009087.html" style="font-family:Arial,Helvetica,sans-serif">http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009087.html</a></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">[3] <a href="http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009101.html" style="font-family:Arial,Helvetica,sans-serif">http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009101.html</a></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">[4] <a href="https://etherpad.openstack.org/p/PVG-u-series-goals" style="font-family:Arial,Helvetica,sans-serif">https://etherpad.openstack.org/p/PVG-u-series-goals</a></div></div>