[tc] [all] Please help verify the role of the TC
zbitter at redhat.com
Fri Jan 18 06:56:16 UTC 2019
On 16/01/19 4:30 AM, Jeremy Stanley wrote:
> On 2019-01-15 11:01:09 +0000 (+0000), Chris Dent wrote:
>> Then I implied that the TC cannot do anything like actionable and
>> unified technical leadership because they have little to no real
>> executive power and what power they do have (for example, trying to
>> make openstack-wide goals) is in conflict (because of the limits of
>> time and space) with the goals that PTLs (and others) are trying to
> Maybe I'm reading between the lines too much, but are you thinking
> that PTLs have any more executive power than TC members? At least my
> experience as a former PTL and discussions I've had with other PTLs
> suggest that the position is more to do with surfacing information
> about what the team is working on and helping coordinate efforts,
> not deciding what the team will work on. PTLs (and TC members, and
> anyone in the community for that matter) can direct where they spend
> their own time, and can also suggest to others where time might be
> better spent, but other than the ability to prevent work from being
> accepted (for example, by removing core reviewers who review
> non-priority changes) there's not really much "executive power"
> wielded by a PTL to decide on a project's direction, only influence
> (usually influence gained by seeking consensus and not attempting to
> assert team direction by fiat decree).
This seems like a good lead in to the feedback I have on the current
role-of-the-TC document (which I already touched on in the review:
https://review.openstack.org/622400). This discussion (which we've had
many times in many forms) always drives me bananas, and here's why:
It is *NOT* about "executive power"!
Think of it this way. If you drop a bunch of humans in a field in the
middle of nowhere, the chances of them arriving together at some
destination - any destination! - are approximately zero in the absence
of some co-ordination. This is true even if you assume they all have the
same destination in mind, which is already pretty unlikely.
The minimum requirements for success would appear to be:
1) One or more people to stand up and say "I think we should go this
way" and explain why;
2) A reason for each person to expect that everybody else is going to go
in the same direction; and
3) When the going gets tough, a sense within each individual that they
were part of making the decisions, even when they don't agree with them.
In short: leadership.
But not "executive power"! In fact, executive power is to be avoided,
because exercise of executive power is inimical to #3.
Where the action is at is #2. Generating #2 is the meatspace equivalent
of the Byzantine Generals problem in computer science. It's a hard
problem, but a problem to which we have instinctively known the solution
for a long time (long before it was solved in computer science, even
though it's essentially the same solution): you somehow bootstrap a
positive feedback loop in which confidence begets confidence.
In OpenStack we choose to bootstrap it by using elections. People
generally expect other people to follow the elected leaders because they
believe that those other people voted for them, which at least in the
aggregate is true. Other projects have chosen the BDFL model, which is
inherently unsustainable as I believe the recent experiences of the
Python community have shown. I think we made the right choice.
But, having elected a group of folks to the TC - the only body that is
elected by the community as a whole, and therefore the only folks that
can set the direction of the project as a whole - what do we then say?
"Well, we can't tell anybody what to do, so we have no choice but to
just leave 'em in this field and hope for the best."
Friends, I have feelings about this, but propriety precludes me from
expressing them fully here. You're welcome to ask me about it some time.
Suffice it to say that I believe this is a false dichotomy.
Note that we don't need the TC to supply #1. But nobody else can supply
#2. For these purposes you can think of "governance" - the stuff that
the TC does consistently do - as being the guardian of the process that
The false dichotomy does not appear to exist at the level of individual
projects, and IMHO the result is kind of what you'd expect: a bunch of
projects that are individually successful but that struggle to cohere
Positive feedback loops are a funny thing: they're inherently unstable,
so sometimes it doesn't take much to make them runaway in the wrong
direction. Confidence begets confidence, but disappointment begets
disappointment. (That's why e.g. I'm opposed to project-wide goals where
we expect from the outset at least one project to fail to complete it in
a single release cycle.) It is to this - the fact that the TC does not
have a great track record of convincing the community to all move in one
direction - that I would attribute the substantial group of people who
are, as Chris says, simply tired of this sort of navel-gazing. I'm sure
those folks would say that we should just stop trying. I think the
actual solution is to start succeeding. It remains to be seen who is right.
More information about the openstack-discuss