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 enact. [...]
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 ensures #3. 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 together. 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. cheers, Zane.