OpenInfrastructure Summit Denver Technical Committee Summary
Here are some of the notes I was able to capture from TC-related discussions during the OpenInfrastructure Summit, Forum, and PTG. Disclaimer, this report isn't inclusive of all topics and discussions.
The TC has been performing health checks over the last year. Each TC member gets assigned a set of projects, and it's their responsibility to reach out to each and assess the health of the project. For the most part, collecting information and documenting a health check is straight-forward, but each TC member is free to procure that information however they see fit. Some TC members attend project meetings and linger in IRC channels, while others parse contributor statistics and reach out directly to PTLs. Looking at the value of health checks over the last year, we were able to distill a couple of essential pieces of information.
First, health checks are a hard thing to measure. What makes a health check useful? Do people use them? So far, the time invested in curating or maintaining health checks hasn't generated much feedback. Second, the act of reaching out to PTLs every release, which is when we conducted health checks, turned out to be very useful. Some PTLs used the open lines of communication with their TC liaison to ask questions about process and governance (e.g., transferring PTL responsibilities from one person to another.)
Ultimately, the TC is going to reduce the amount of effort put into monitoring the pulse of each project but maintain the effort every cycle to communicate with PTLs. The TC is going to formally document the process of reaching out to project teams in the governance repository, so the practice continues as the TC evolves.
Evolution of Help Most Needed
This topic has been a hot button issue for more than a year. Before the OpenStack Summit in Vancouver (2018), the TC received some feedback from the board during the joint leadership meeting. The suggestion was to reformat the list to include business value, appealing to decisions makers who can staff resources upstream because it provides a fundamental part of their business. In other words, we referred to this as a way to motivate organizations to take care of the commons. This discussion spanned the joint leadership meeting and a separate time slot the following Saturday during the PTG. The content was dense, but the following is what I took away.
First, I noticed that many people in the joint leadership meeting weren't aware that the TC worked on this initiative. Or that we were attempting to revive it yet again. Their feedback on the initial pass to add business value to each item on the list was positive. Some people at the board meeting even took actions to put people on various initiatives as a result. I think this showed that the list is either hard to find, undiscoverable, or only referenced by people who are familiar with it. We're not socializing it in a way that gets it in front of the right audience.
One suggestion was to work with the Foundation to incorporate an item or two from the list in the community newsletter. The newsletter gives us several opportunities a year to plug new initiatives that need help, especially using a medium that is likely to expand outside our tight-knit circle of contributors who are already aware of the list. The list is also going to be renamed from "Help Most Needed" to something that better reflects the business impacts we're trying to communicate.
Maintaining the List
One of the concerns about putting together lists of projects or initiatives that need help is that they are susceptible to continual growth. Once an item is on the list, how do we remove it? Does each item need a definition of done? We agreed that a long list doesn't impart the best impression on readers because it's overwhelming and doesn't positively reflect community health. Instead, we decided to implement a buoyant cap of five items, give or take two. If we have three items on the list, we shouldn't stress about adding two more. If we have seven because we're having a hard time cutting one or two, we shouldn't sweat it. In addition to a less restrictive cap, we're also going to implement expiration on each item. Whenever an author adds an initiative to the list, it receives an expiration date. Authors can reapply for a spot on the list if it has reached its expiry and isn't complete. This process allows the TC to review items alongside new proposals and introduce rotation if needed.
Another thing that we agreed upon is that business cases are hard to write. We attempted to write some, and they seemed to get the point across during the board meeting, but it would be great to have a polished approach. As a result, we have an action to reach out to folks from the Foundation who are skilled in this type of writing.
Train Goal Selection Retrospective
As a group, we talked through things that went well and things that didn't go well while selecting Train community goals. If I had to describe the goal selection process this release with one word, I'd chose turbulent.
We had a great forum session in Berlin that focused on a list of potential goals for the upcoming cycle. We found champions to drive the work and continued to discuss possible solutions. As the OpenInfrastructure Summit approached, so did the deadline we set for having goals approved (we wanted to have cycle goals merged six weeks before the event to give teams time to plan and discuss them in-person.) We didn't end up agreeing on the goals we thought we were going to target for Train, but we did come up with two excellent alternative goals instead.
To be clear, I don't think this was due to the goals themselves or the people reviewing them. If anything, I think it speaks to a deficiency we have in the community goal process. It wasn't the best tool for what we were trying to do with unified support of python-openstackclient or cleaning up project resources. If there is a silver lining outside of finding two goals on short notice, it's that we were able to identify a gap in our process that doesn't necessarily enable specific initiatives — more on this below.
U Release Goals
With the changes to the OpenInfrastructure Summit and co-locating the PTG with the Forum, we're going to have to find a new schedule for selecting goals. Previously, the TC would hold Forum sessions to kick start the community goal process, allowing us to go into each PTG with community goals decided. We did this at the Forum in Berlin (November 2018) for goals in the Train cycle. With the PTG and Forum co-located, that specific schedule is going to be harder to achieve. We either need to discuss cycle goals during the current cycle (short notice), or discuss goals for the next cycle at the start of the current cycle (long lead times). We're still trying to figure out what approach is best if we want to continue discussing these topics face-to-face.
We also noticed positive feedback about the goals we decided on last minute. Most people were surprised because they didn't fit the mold for previous community goals (PDF support and IPv6 testing). This feedback reinforced the idea that we need to do a better job of documenting what qualifies as a community goal, which might help the goal selection process since it could turn up other potential items.
As noted above, the TC conversations about community goals highlighted a deficiency in enabling cross-project collaboration that didn't fit the format of a community-wide goal. These initiatives are important, but using the existing goal infrastructure is analogous to pounding nails with a screwdriver. Instead, the TC decided to find ways to enable people working on these initiatives with minimal process and bureaucracy.
First, we need to write down a set of best practices for accomplishing work that falls into this category. Several people in the community have successfully facilitated and pushed cross-project initiatives over multiple releases. Attaching multiple volumes to a virtual server is one example that required close communication between teams. The TC should consult people who have experience driving these initiatives and distill the information into a concise document that others can use for guidance.
Second, we need to be verbose in explaining how this approach differs from community-wide goals. Without clear distinction, people will be confused as to which process they should use. We don't want the process to be more complicated. Determining which approach to use should be easy.
Third, we need to document existing pop-up teams and the efforts they're driving. This list is going to be maintained regularly, possibly each release, for accuracy. Image encryption is an excellent example of an existing group.
Finally, we should create a document that describes pop-up teams and how to identify them. We should also document the process for adding and disbanding pop-ups teams. The bar for adding and removing teams should be low. We don't want the process to get in the way of people doing important work. On the other hand, we want the formalization to be helpful if people need it to justify the time working upstream.
The last thing we discussed as a group before I left to catch a flight was what to do with leaderless projects. The TC requires a point of contact for each project team, which usually falls to the PTL. If a project is leaderless, do we remove them from governance? I thought it was important that each project needs a PTL, but that bar can be low if the project is in maintenance mode or feature complete. In that case, the PTL is a point of contact in the event the TC needs to signal the project directly. The PTL title doesn't need to carry the same weight as it does in more active projects. That said, we as a community could do a better job describing all the possible duties of team leads. Project teams can apply those to their project as they see fit, but it should help people get a better idea of what is required of them if they decide to run. We should also encourage shadowing. PTLs can delegate responsibilities to shadows, which helps distribute load across the team and grooms others for the role. We are hoping this results in less leaderless projects and a clear protocol of what to do with truly leaderless projects.