The TC held meetings on 2 days at the Stein PTG in Denver. On Sunday 9 September, we met for a few hours in the afternoon to discuss introspective topics. On Friday 14 September, we met for a full day to discuss community topics. Below is a summary of my notes. Please let me know if I omitted or misremembered anything.
Agenda and notes: https://etherpad.openstack.org/p/tc-stein-ptg Backlog Review ============== We started the Sunday meeting with a review of all of the work that TC members are doing outside of the TC. This gave us a clearer view of what we could expect to be able to do as a group, given time constraints. With that grounding, we reviewed our backlog (https://wiki.openstack.org/wiki/Technical_Committee_Tracker) and removed many items that we either felt were completed, would not be completed, or were ongoing monitoring and did not need to be tracked as specific tasks. We also agreed to try to work together as a group on a smaller number of initiatives, rather than maintaining a long list of open items in the tracker. The python 2.7 deprecation timeline has been documented (https://governance.openstack.org/tc/resolutions/20180529-python2-deprecation-timeline.html) and we saw no need to be more formal about documenting expectations for new projects joining the community, so we removed that item from the tracker. We have discussed building a set of documentation around project constellations, but decided the information we hoped to convey in constellations would better be conveyed through the software section of the foundation web site. Now that the data for that section is being moved to a repository that anyone in the community can update, we no longer felt it was necessary for the TC to commit to writing constellation documentation (although we would support someone else picking up that work). We dropped this item from the tracker. We had completed the item to add a key manager to the base services list when we added "a castellan-compatible" service, but not removed it from the backlog because there was also some discussion about adding Barbican specifically. Work on that is on hold, so we removed the item from the tracker for now and will add it back in the future if we decide to move ahead with adding Barbican. We removed the item for improving the visibility of status updates because we considered it an ongoing task. We will still be working on the problem, but since it may never be done we didn't feel like tracking it as a "task" made sense. Doug, Thierry, and Jeremy talked with the Infra team about upgrading and adding tools later in the week. We removed StarlingX from the tracker because the work on that project are happening out in the open more so we felt the initial status check was sufficiently completed. We removed the item for clarifying the terms of service for hosted projects on openstack.org infrastructure because that work is now being done by the team soon-to-be-called OpenDev. We removed the item that called for a review of the status of the electorate. The election officials produce some statistics after each election and they offered to add any details we thought were useful. Since this is a recurring item managed by the election team, we do not need to track it ourselves. We removed the item for improving the help-wanted list because it wasn't clear that the TC was the best group to manage a list of "roles" or other more detailed information. We discussed placing that information into team documentation or hosting it somewhere outside of the governance repository where more people could contribute. The kubernetes community has set up a forum, for example. We removed the task of updating the PTI for translation and PDF support in documentation builds because we worked out a way to do that without a governance change. http://lists.openstack.org/pipermail/openstack-dev/2018-September/134609.html Joint Leadership Meeting in Berlin ================================== Alan Clark, chair of the Foundation board of directors, was present for the meeting, and asked that we include an agenda item to start planning for the joint leadership meeting with the board, UC, Foundation staff, and representatives from other projects being piloted by the Foundation. We spent a little bit of time discussing the previous meeting, including some feedback from TC members that the project announcements made that morning caused some distraction during the day. Jonathan Bryce indicated that they will time those announcements better to avoid that problem, and that with the new process being developed there should be fewer surprises in the future. Alan also gave us the feedback that with the ongoing evolution of the OpenStack project, the board is going to expect the TC to start providing more strategic planning information. He recommended that we be ready to discuss major themes of ongoing work and give the board members the information they need to project a positive image to the press when they are approached for interviews during the summit. New Project Application Process =============================== We wrapped up Sunday with a discussion of of our process for reviewing new project applications. Zane and Chris in particular felt the process for Adjutant was too painful for the project team because there was no way to know how long discussions might go on and now way for them to anticipate some of the issues they encountered. We talked about formalizing a "coach" position to have someone from the TC (or broader community) work with the team to prepare their application with sufficient detail, seek feedback before voting starts, etc. We also talked about adding a time limit to the process, so that teams at least have a rejection with feedback in a reasonable amount of time. Some of the less contentious discussions have averaged from 1-4 months with a few more contentious cases taking as long as 10 months. We did not settle on a time frame during the meeting, so I expect this to be a topic for us to work out during the next term. Team Health Review ================== We started Friday morning by reviewing the current health tracker process and results. A few TC members expressed doubts about the efficacy of asking teams to report their problems, but we agreed that the process was at least a good way to start building the relationships that would encourage teams to approach us in the future. Someone proposed that we draft a "welcome" email for new PTLs each cycle, to ensure that everyone understood the expectations and knew how to reach their liaisons, if needed. We did also discuss some specific issues uncovered during this term, although they were not the types of issues that led us to start the process in the first place. We reviewed a few of the teams that seemed to be in danger based on their affiliation diversity, review team size, or other reports. We decided that having limited affiliation diversity was not necessarily a problem for projects that were product integration points or deployment tools. We said that we should keep our eye on smaller teams, but not take any action to change their governance status if they were maintaining enough activity to keep up with goals and releases. The keystone team reported some concerns over contributor burnout, mostly caused by their central position in the community and the fact that several core team members have moved on from the project recently so they lost a good bit of institutional knowledge. We talked about ways to set reasonable expectations for folks outside of the team, as well as balancing expectations for folks inside the team who have been trying to address some long-standing technical issues with little traction. We also spent some time talking about approaches for on-boarding contributors, including mentoring. Mentoring presents challenges with investing time on folks who don’t stay with the project, but without the investment at all it is hard to see how teams are going to recruit and retain new members. We also discussed the changing nature of the community and the fact that no longer have a large pool of contributors looking for work - they either have little freedom in what they chose to work on or they have little interest in some of the areas where help may be needed the most. Several teams are addressing review bandwidth by allowing patches to be approved by a single core. Different teams have adopted different policies, ranging from applying the rule only to trivial patches, allowing one core to approve another’s work, or applying the rule to all changes. So far all of the teams experimenting with this approach report that things are working OK, and they have not encountered any major bugs as a result of the change in review policy. A few teams reported issues adding stable branch reviewers from project teams. Sean and Thierry are going to work with the stable maintenance SIG to ensure that teams are able to manage the members of their review teams, with guidance, so we can maintain healthy stable reviews. The Octavia team reported that the goals were not “helpful” to their team. This seems to have been triggered by the WSGI goal definition changing mid-cycle, after the team had nearly completed the earlier definition of the work. We should be able to avoid that problem in the future by doing more preliminary work to ensure the technical details of goals are resolved before adopting the goal. In our retrospective of the process itself we talked about standardizing the set of questions we ask and trying to minimize the amount of time it takes to review each team. I purposefully didn't describe a detailed process this time to see what sorts of things liaisons considered important, and the range was fairly wide. Some liaisons reviewed meeting logs and review statistics, while others simply contacted the PTL to ask a few basic questions. There was strong support for taking the email approach, with a set of common questions so that we have similar information from all teams. Global Outreach =============== We spent a bit of time talking about the need to communicate with parts of the community not active on the mailing list and IRC. The specific example of Chinese users and contributors who primarily use WeChat was raised and we talked about how to encourage those folks to join the rest of the community. Zhipeng Huang has proposed a TC resolution to encourage TC members to use social media channels to communicate with community members who are not active in our regular channels (https://review.openstack.org/#/c/602697/), and there is a mailing list thread (http://lists.openstack.org/pipermail/openstack-dev/2018-September/134684.html). Thierry also recommended attending events in China, if possible, because it offers a new perspective on that part of the community, and several of the TC members who have been able to do that agreed. Technical Vision ================ Zane presented his draft technical vision (https://review.openstack.org/592205) and we talked about gaps, such as the tension between services relying on integrating with each other versus running in "standalone" configurations and reusing components created by other communities. We also need to explain what the vision is for, and how it will be used by the TC and project teams. When the next draft is ready, we will publicize it more and ask for feedback from all of the project teams with the goal of having it ready to present at the joint leadership meeting at the upcoming summit in Berlin. SIGs, Working Groups, and Cross-project efforts =============================================== We closed out the afternoon with a request from the public cloud working group to help them with the feature requests they have identified, many of which would require work from multiple project teams. We talked about applying the community goal process to features like deleting a tenant from a cloud, and we talked about the idea that some other features may require multiple cycles of work, and therefore either multiple goals or some other approach. As a next step, we encouraged the SIG to add their suggestions to the community goals list (https://etherpad.openstack.org/p/community-goals) and to schedule forum sessions to talk about specific features, in addition to prioritization sessions for the SIG to review its list. We also talked about ways to find contributors willing and able to work on the ideas coming from SIGs and working groups. The original intent of setting up SIGs was to provide a way for people with common interests to work together. If contributors are not participating, that may indicate a lack of economic incentive or simply a lack of advertising of the SIG. Either way it makes recruiting folks to drive the work more challenging. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev