Open Stack

On 23/04/18 09:27, Doug Hellmann wrote:
> [This is meant to be one of (I hope) several conversation-provoking
> questions directed at prospective TC members to help the community
> understand their positions before considering how to vote in the
> ongoing election.]
> 
> We frequently have discussions about whether the TC is active enough,
> in terms of driving new policies, technology choices, and other
> issues that affect the entire community.

I guess you can put me in the camp of wanting the TC to be proactive as 
well as reactive. I don't want to say it's not being active enough, but 
I do think it's valuable to proactively consider other ways in which we 
can be proactive.

> Please describe one case where we were either active or reactive
> and how that was shown to be the right choice over time.

A couple of examples that come to mind of the TC being actively involved 
in driving changes would be the addition of etcd3 to the required set of 
base services (alongside RabbitMQ and MySQL/MariaDB), and the 
project-wide goals initiative.

Those are both examples of decisions that need to be co-ordinated across 
the whole of OpenStack. Since the TC is the only elected body that 
represents the whole technical community, it needs to have a role in 
decisions such as those - either by making them directly or by 
delegating them to some group of experts. If it doesn't, we'll generally 
be stuck with the status quo by default. In my experience, major 
decisions getting made by default is a common failure mode in a lot of 
bad products.

> Please describe another case where the choice to be active or
> reactive ended up being the wrong choice.

This is a difficult one to answer, in part because being purely reactive 
need not be a choice - it's the default.

One example, that's closely related to the other thread, might be the 
way we've chosen to define the scope of OpenStack. That's largely been 
by reactively approving or rejecting projects as they requested to join, 
rather than by attempting to lay out a vision in more detail than our 
mission statement and correcting course when necessary in response to 
new project applications.

The picture that has emerged from that process has essentially been one 
of a full-featured cloud (which, for the record, I fully agree with) - 
most projects were approved. But as Chris pointed out there are plenty 
of folks out there who disagree with that. By not having a proactive 
debate we've missed an opportunity to gain a deeper understanding of 
their concerns and address them as far as is possible. I believe there 
are a lot of folks still working at cross-purposes without a unified 
vision of what we're trying to build as a result.

> If you think the TC should tend to be more active in driving change
> than it is today, please describe the changes (policy, culture,
> etc.) you think would need to be made to do that effectively (not
> which policies you want us to be more active on, but *how* to
> organize the TC to be more active and have that work within the
> community culture).

One of my concerns is that the dropping of the weekly TC meeting with a 
published agenda in favour of the unstructured office hours has 
diminished the TC's ability to be proactive. For example, the 
constellations initiative was adopted by the TC as a goal to get 
underway by 2019 (barely more than 8 months away). Who is working on it? 
What is the status? What are the open questions requiring feedback? I 
don't know, and I follow #openstack-tc and the TC mailing list fairly 
closely compared to most people.

I definitely don't want to get rid of office hours, and I think the 
reasons for dropping the meeting (encouraging geographically diverse 
participation) are still valid. I'd like to see the TC come up with a 
program of work for the term after each Summit, and actively track the 
progress of it using asynchronous tools - perhaps Storyboard supported 
by follow-ups on the mailing list.

Perhaps we can also do more to, for example, empower SIGs to make 
recommendations on community-wide issues that the TC would then commit 
to either ratifying or rejecting within a fixed time frame. One reason 
that I think the TC is (correctly) wary of promulgating too many edicts 
is that they're perceived as difficult to change as circumstances 
demand. So reducing the cost of changes is key to allowing the TC to 
take a more active role without stifling the community.

cheers,
Zane.

> If you think the TC should tend to be less active in driving change
> overall, please describe what policies you think the TC should be
> taking an active role in implementing.
> 
> Doug