Open Stack

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.