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
__________________________________________________________________________
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
