[tc] [all] Please help verify the role of the TC
Recently Thierry, with the help of other TC members, wrote down the perceived role of the TC [1]. This was inspired by the work on the "Vision for OpenStack Clouds" [2]. If we think we should have that document to help validate and direct our software development, we should have something similar to validate governance. Now we need to make sure the document reflects not just how things are but also how they should be. We (the TC) would like feedback from the community on the following general questions (upon which you should feel free to expand as necessary). * Does the document accurately reflect what you see the TC doing? * What's in the list that shouldn't be? * What's not in the list that should be? * Should something that is listed be done more or less? Discussions like these are sometimes perceived as pointless navel gazing. That's a fair complaint when they result in nothing changing (if it should). In this case however, it is fair to say that the composition of the OpenStack community is changing and we _may_ need some adjustments in governance to effectively adapt. We can't know if any changes should be big or little until we talk about them. We have several weeks before the next TC election, so now seems an appropriate time. Note that the TC was chartered with a mission [3]: The Technical Committee (“TC”) is tasked with providing the technical leadership for OpenStack as a whole (all official projects, as defined below). It enforces OpenStack ideals (Openness, Transparency, Commonality, Integration, Quality…), decides on issues affecting multiple projects, forms an ultimate appeals board for technical decisions, and generally has technical oversight over all of OpenStack. Thanks for your participation and help. [1] https://governance.openstack.org/tc/reference/role-of-the-tc.html [2] https://governance.openstack.org/tc/reference/technical-vision.html [3] https://governance.openstack.org/tc/reference/charter.html#mission -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
thanks for posting this Chris, i have one minor question On Thu, Jan 10, 2019 at 9:17 AM Chris Dent <cdent+os@anticdent.org> wrote:
Now we need to make sure the document reflects not just how things are but also how they should be. We (the TC) would like feedback from the community on the following general questions (upon which you should feel free to expand as necessary).
where is the best venue for providing feedback? i see these documents are published, should we start threads on the ml (or use this one), or make issues somewhere? peace o/
On Thu, 10 Jan 2019, Michael McCune wrote:
On Thu, Jan 10, 2019 at 9:17 AM Chris Dent <cdent+os@anticdent.org> wrote:
Now we need to make sure the document reflects not just how things are but also how they should be. We (the TC) would like feedback from the community on the following general questions (upon which you should feel free to expand as necessary).
where is the best venue for providing feedback?
i see these documents are published, should we start threads on the ml (or use this one), or make issues somewhere?
Sorry that I wasn't clear about that. Here, on this thread, would be a great place to start. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On Thu, 10 Jan 2019, Chris Dent wrote:
Now we need to make sure the document reflects not just how things are but also how they should be. We (the TC) would like feedback from the community on the following general questions (upon which you should feel free to expand as necessary).
* Does the document accurately reflect what you see the TC doing? * What's in the list that shouldn't be? * What's not in the list that should be? * Should something that is listed be done more or less?
Since nobody else is feeling inspired to respond, I'll respond to myself but whereas the original message was written with my TC hat, this one is not. Perhaps the TC is not doing what it should be doing, nor is it constituted to enable that. Since there is a significant and friction creating division of power and leadership between the TC and PTLs, what would it be like if we required half or more of the TC be elected from PTLs? Then the "providing the technical leadership" aspect of the TC mission [3] would be vested with the people who also have some responsibility for executing on that leadership. That would be like something we had before, but now there are many more PTLs.
[3] https://governance.openstack.org/tc/reference/charter.html#mission
-- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On 2019-01-14 17:56:09 +0000 (+0000), Chris Dent wrote: [...]
Since there is a significant and friction creating division of power and leadership between the TC and PTLs, what would it be like if we required half or more of the TC be elected from PTLs? Then the "providing the technical leadership" aspect of the TC mission [3] would be vested with the people who also have some responsibility for executing on that leadership. [...]
As someone who was both a PTL and TC member for a while, I think it's a lot to juggle (especially since I expect none of us has just our leadership duties on our respective piles of responsibilities). While doing both, I felt like I wasn't able to carve out enough time to give either group of constituents the attention and representation it was due. I know we have a few PTLs on the TC now, and I respect their monumental effort but personally don't know how they manage to stay sane. Kudos! -- Jeremy Stanley
Since there is a significant and friction creating division of power and leadership between the TC and PTLs, what would it be like if we required half or more of the TC be elected from PTLs? Then the "providing the technical leadership" aspect of the TC mission [3] would be vested with the people who also have some responsibility for executing on that leadership.
That would be like something we had before, but now there are many more PTLs.
I could see having something where to be an eligible candidate, one would either need to be a current or a past PTL. There's definitely value in bringing that experience and perspective to the TC. That could complicate the election process quite a bit. But it's an idea interesting enough that I think we should discuss it further. Sean
On 2019-01-14 14:16:51 -0600 (-0600), Sean McGinnis wrote: [...]
I could see having something where to be an eligible candidate, one would either need to be a current or a past PTL. There's definitely value in bringing that experience and perspective to the TC. [...]
In principle, our charter doesn't even require candidates for TC seats be recognized contributors to any project, only that they be OSF individual members in good standing. In practice, the most common way people get the visibility required to be elected to the TC is to have already held another leadership role in the community, frequently by serving as a PTL. While I haven't actually done the math, I would wager more than half the people ever elected to the TC have also been PTLs at some point, so I personally have doubts that making it a policy would actually change anything. A quick skim of the current sitting TC members, I believe 12 out of 13 are either presently or were formerly also PTLs. -- Jeremy Stanley
Hello :) On Mon, Jan 14, 2019 at 12:30 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2019-01-14 14:16:51 -0600 (-0600), Sean McGinnis wrote: [...]
I could see having something where to be an eligible candidate, one would either need to be a current or a past PTL. There's definitely value in bringing that experience and perspective to the TC. [...]
In principle, our charter doesn't even require candidates for TC seats be recognized contributors to any project, only that they be OSF individual members in good standing. In practice, the most common way people get the visibility required to be elected to the TC is to have already held another leadership role in the community, frequently by serving as a PTL.
There are many other leadership positions that we would exclude if we started restricting TC candidates to only current/past PTLs. SIG Chairs (formerly WG leads) for example. Some sort of leadership role prior to running is important, I agree. But we would never have had people like Colleen Murphy or Chris Dent who were and are, respectively, excellent members of the TC.
While I haven't actually done the math, I would wager more than half the people ever elected to the TC have also been PTLs at some point, so I personally have doubts that making it a policy would actually change anything.
A quick skim of the current sitting TC members, I believe 12 out of 13 are either presently or were formerly also PTLs. -- Jeremy Stanley
-Kendall (diablo_rojo)
On 2019-01-14 14:12:39 -0800 (-0800), Kendall Nelson wrote:
Hello :)
On Mon, Jan 14, 2019 at 12:30 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2019-01-14 14:16:51 -0600 (-0600), Sean McGinnis wrote: [...]
I could see having something where to be an eligible candidate, one would either need to be a current or a past PTL. There's definitely value in bringing that experience and perspective to the TC. [...]
In principle, our charter doesn't even require candidates for TC seats be recognized contributors to any project, only that they be OSF individual members in good standing. In practice, the most common way people get the visibility required to be elected to the TC is to have already held another leadership role in the community, frequently by serving as a PTL.
There are many other leadership positions that we would exclude if we started restricting TC candidates to only current/past PTLs. SIG Chairs (formerly WG leads) for example.
Some sort of leadership role prior to running is important, I agree. But we would never have had people like Colleen Murphy or Chris Dent who were and are, respectively, excellent members of the TC.
Absolutely. I happen to think that the representatives we've had on the TC who weren't previously PTLs have provided valuable insight.
While I haven't actually done the math, I would wager more than half the people ever elected to the TC have also been PTLs at some point, so I personally have doubts that making it a policy would actually change anything. [...]
And here I was more responding to Chris's original question, "what would it be like if we required half or more of the TC be elected from PTLs?" What I meant to say is that I believe half or more of the TC are already (and have always been) elected from current and prior PTLs, so mandating that wouldn't change anything for the better. Certainly if Sean's follow-up suggestion of requiring *all* TC candidates to have PTL experience were entertained, it would exclude the sorts of valuable contributions we've had from notable non-PTL members on the TC and I think that would be a significant loss. -- Jeremy Stanley
On 1/14/2019 4:33 PM, Jeremy Stanley wrote:
Hello :)
On Mon, Jan 14, 2019 at 12:30 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2019-01-14 14:16:51 -0600 (-0600), Sean McGinnis wrote: [...]
I could see having something where to be an eligible candidate, one would either need to be a current or a past PTL. There's definitely value in bringing that experience and perspective to the TC. [...]
In principle, our charter doesn't even require candidates for TC seats be recognized contributors to any project, only that they be OSF individual members in good standing. In practice, the most common way people get the visibility required to be elected to the TC is to have already held another leadership role in the community, frequently by serving as a PTL. There are many other leadership positions that we would exclude if we started restricting TC candidates to only current/past PTLs. SIG Chairs (formerly WG leads) for example.
Some sort of leadership role prior to running is important, I agree. But we would never have had people like Colleen Murphy or Chris Dent who were and are, respectively, excellent members of the TC. Absolutely. I happen to think that the representatives we've had on
On 2019-01-14 14:12:39 -0800 (-0800), Kendall Nelson wrote: the TC who weren't previously PTLs have provided valuable insight.
While I haven't actually done the math, I would wager more than half the people ever elected to the TC have also been PTLs at some point, so I personally have doubts that making it a policy would actually change anything. [...]
And here I was more responding to Chris's original question, "what would it be like if we required half or more of the TC be elected from PTLs?" What I meant to say is that I believe half or more of the TC are already (and have always been) elected from current and prior PTLs, so mandating that wouldn't change anything for the better.
Certainly if Sean's follow-up suggestion of requiring *all* TC candidates to have PTL experience were entertained, it would exclude the sorts of valuable contributions we've had from notable non-PTL members on the TC and I think that would be a significant loss.
Agreed, in my response to Sean's note hadn't meant that all TC members would need to have been PTLs but that some proportion having technical leadership experience in OpenStack would be good. Sorry for the confusion.
---- On Tue, 15 Jan 2019 07:33:52 +0900 Jeremy Stanley <fungi@yuggoth.org> wrote ----
On 2019-01-14 14:12:39 -0800 (-0800), Kendall Nelson wrote:
Hello :)
On Mon, Jan 14, 2019 at 12:30 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2019-01-14 14:16:51 -0600 (-0600), Sean McGinnis wrote: [...]
I could see having something where to be an eligible candidate, one would either need to be a current or a past PTL. There's definitely value in bringing that experience and perspective to the TC. [...]
In principle, our charter doesn't even require candidates for TC seats be recognized contributors to any project, only that they be OSF individual members in good standing. In practice, the most common way people get the visibility required to be elected to the TC is to have already held another leadership role in the community, frequently by serving as a PTL.
There are many other leadership positions that we would exclude if we started restricting TC candidates to only current/past PTLs. SIG Chairs (formerly WG leads) for example.
Some sort of leadership role prior to running is important, I agree. But we would never have had people like Colleen Murphy or Chris Dent who were and are, respectively, excellent members of the TC.
Absolutely. I happen to think that the representatives we've had on the TC who weren't previously PTLs have provided valuable insight.
While I haven't actually done the math, I would wager more than half the people ever elected to the TC have also been PTLs at some point, so I personally have doubts that making it a policy would actually change anything. [...]
And here I was more responding to Chris's original question, "what would it be like if we required half or more of the TC be elected from PTLs?" What I meant to say is that I believe half or more of the TC are already (and have always been) elected from current and prior PTLs, so mandating that wouldn't change anything for the better.
Certainly if Sean's follow-up suggestion of requiring *all* TC candidates to have PTL experience were entertained, it would exclude the sorts of valuable contributions we've had from notable non-PTL members on the TC and I think that would be a significant loss.
There is no doubt that having Leadership experience for TC candidates are much valuable but IMO PTL is not the only way to judge the leadership experience, it can be corporate experience, other past/current open source leadership or even from core member role also. There are many core members who are an excellent leader and leading certain area of the big project since long time. Nova, Neutron are good example where the project is divided into sub-teams and sub-leaders. As PTL, you need to do sort of management activity and not all core want to serve as PTL but they are a good leader and best fit for TC. -gmann
-- Jeremy Stanley
On 1/14/2019 2:16 PM, Sean McGinnis wrote:
Since there is a significant and friction creating division of power and leadership between the TC and PTLs, what would it be like if we required half or more of the TC be elected from PTLs? Then the "providing the technical leadership" aspect of the TC mission [3] would be vested with the people who also have some responsibility for executing on that leadership.
That would be like something we had before, but now there are many more PTLs.
I could see having something where to be an eligible candidate, one would either need to be a current or a past PTL. There's definitely value in bringing that experience and perspective to the TC.
That could complicate the election process quite a bit. But it's an idea interesting enough that I think we should discuss it further.
Sean
I think have a requirement of having been a PTL could be reasonable. Given the fact that I feel I have a hard enough time doing all I want to do as PTL, I wouldn't want to add TC at the same time. Would want to feel like I was doing it at a time where I could give it the appropriate attention. Jay
Been chewing on this thread for a while.... I think I should advocate the other direction. I think most folks will come from PTL as its an easier path to get votes. So I don't see that as underrepresented. Getting some diversity of ideas from outside of those from PTL's is probably a good idea for the overall health of OpenStack. What about Users that have never been PTL's? Not developers? Thanks, Kevin ________________________________________ From: Jay Bryant [jungleboyj@gmail.com] Sent: Monday, January 14, 2019 1:32 PM To: openstack-discuss@lists.openstack.org Subject: Re: [tc] [all] Please help verify the role of the TC On 1/14/2019 2:16 PM, Sean McGinnis wrote:
Since there is a significant and friction creating division of power and leadership between the TC and PTLs, what would it be like if we required half or more of the TC be elected from PTLs? Then the "providing the technical leadership" aspect of the TC mission [3] would be vested with the people who also have some responsibility for executing on that leadership.
That would be like something we had before, but now there are many more PTLs.
I could see having something where to be an eligible candidate, one would either need to be a current or a past PTL. There's definitely value in bringing that experience and perspective to the TC.
That could complicate the election process quite a bit. But it's an idea interesting enough that I think we should discuss it further.
Sean
I think have a requirement of having been a PTL could be reasonable. Given the fact that I feel I have a hard enough time doing all I want to do as PTL, I wouldn't want to add TC at the same time. Would want to feel like I was doing it at a time where I could give it the appropriate attention. Jay
On 2019-01-14 21:53:00 +0000 (+0000), Fox, Kevin M wrote: [...]
Getting some diversity of ideas from outside of those from PTL's is probably a good idea for the overall health of OpenStack. What about Users that have never been PTL's? Not developers? [...]
It's an interesting suggestion. I'm curious how you'd see user representatives on the OpenStack TC as differing from the OpenStack UC: https://governance.openstack.org/uc/ Those are the individuals who users in our community have chosen to represent their interests. Do you feel they're chosen poorly? Or simply lack influence over/a voice in topics for which the TC members are asked to provide policy and guidance? -- Jeremy Stanley
"Fox, Kevin M" <Kevin.Fox@pnnl.gov> writes:
Been chewing on this thread for a while.... I think I should advocate the other direction.
I think most folks will come from PTL as its an easier path to get votes. So I don't see that as underrepresented.
Getting some diversity of ideas from outside of those from PTL's is probably a good idea for the overall health of OpenStack. What about Users that have never been PTL's? Not developers?
Thanks, Kevin
It is already possible for any Foundation member to stand for election to the TC. They do not need to be a "developer" (or even "contributor") according to the election rules. I don't think it's especially likely that someone who isn't a contributor is going to do well in the election for more practical reasons, though. -- Doug
On Mon, 14 Jan 2019, Fox, Kevin M wrote:
Been chewing on this thread for a while.... I think I should advocate the other direction.
I'm not sure where to rejoin this thread, so picking here as it provides a reasonable entry point. First: thanks to everyone who has joined in, I honestly do feel that as annoying as these discussions can be, they often reveal something useful. Second, things went a bit sideways from the point I was trying to reach. I wasn't trying to say that PTLs are the obvious and experienced choice for TC leadership, nor that they were best placed to represent the community. I hope that my own behavior over the past few years has made it clear that I very definitely do not feel that way. However, as most respondents on this thread have pointed out, both TC members and PTLs are described as being over-tasked. What I'm trying to tease out or ask is: Are they over-tasked because they are working on too many things (or at least trying to sort through the too many things); a situation that results from _no unified technical leadership for the community_. My initial assertion was that the TC is insufficiently involved in defining and performing technical leadership. 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. Thus: What if the TC and PTLs were the same thing? Would it become more obvious that there's too much in play to make progress in a unified direction (on the thing called OpenStack), leading us to choose less to do, and choose more consistency and actionable leadership? And would it enable some power to execute on that leadership. Those are questions, not assertions.
Getting some diversity of ideas from outside of those from PTL's is probably a good idea for the overall health of OpenStack. What about Users that have never been PTL's? Not developers?
So, to summarize: While I agree we need a diversity of ideas, I don't think we lack for ideas, nor have we ever. What we lack is a small enough set of ideas to act on them with significant enough progress to make a real difference. How can we make the list small and (to bring this back to the TC role) empower the TC to execute on that list? And, to be complete, should we? And, to be extra really complete, I'm not sure if we should or not, which is why I'm asking. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
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). -- Jeremy Stanley
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.
On Fri, 18 Jan 2019, Zane Bitter wrote:
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"!
I basically agree with you that leadership is the key factor and my heart is with you on much of what you say throughout your message; however, as much as "executive power" makes me cringe, it felt necessary to introduce something else into the discussion to break the cycle. We keep talking about needing leadership but then seem to fail to do anything about it. Throwing "power" into the mix is largely in response to my observations and own personal experience that when a project or PTL is either: * acting in bad faith, contrary to the wider vision, or holding an effective veto over a positive change much of the rest of the community wants * feared that they might do any of those things in the prior point, even if they haven't demonstrated such the TC clams up, walks away, and tries to come at things from another angle which won't cause a disruption to the fragile peace. So, in a bit of reverse psychology: If the TC can't control the projects, maybe the projects should just be the TC? It's not a model I really agree with, but it is one that has managed to get some ideas and questions moving. In Jeremy's message he suggested that while the main action of the PTL is to coordinate and surface they do have one important power: the power to say "no" and then seems to suggest that's not a big deal. It's a huge deal. The TC has, by the current constitution, a similar power to say no, but it is a giant sledgehammer in the shape of making a project not official, and nobody wants to use that and:
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."
My goal with asking for the TC role document to be evaluated by the community was to survey around to what feelings people have about the extent people want the TC to tell people what they could do ("could", not "should") and find the boundaries and speed bumps. It feels like there are three groups being vocal, two that I mentioned before: * enable diffuse but vaguely related collaboration (the TC as it has acted for awhile) * lead with a much more strongly defined unified direction (something needs to change, methods differ) * PTL/Project driven direction is the right way (also the TC operating as usual, but with a different focal point) but I still have no clear idea what community members in general think. At least one person has suggested that if the TC is to continue as it has been for a few years, it might consider changing its name to get rid of "Technical". Is that the way to go? I hope not. I agree that we should reach and achieve higher, and let success be the fuel for still more. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On 2019-01-18 10:38:02 +0000 (+0000), Chris Dent wrote: [...]
In Jeremy's message he suggested that while the main action of the PTL is to coordinate and surface they do have one important power: the power to say "no" and then seems to suggest that's not a big deal. It's a huge deal. [...]
I certainly didn't mean to imply that it's "not a big deal." The context was that the PTL's ability to refuse work from individuals doesn't magically make them work on priority tasks for that team (and in my experience, more often simply causes them to go away); so rejecting proffered non-priority effort doesn't translate to getting priorities accomplished, though it can serve to reduce distractions for the remaining team members who actually do want to focus on those priorities, sure. -- Jeremy Stanley
On 18/01/19 11:38 PM, Chris Dent wrote:
On Fri, 18 Jan 2019, Zane Bitter wrote:
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"!
I basically agree with you that leadership is the key factor and my heart is with you on much of what you say throughout your message; however, as much as "executive power" makes me cringe, it felt necessary to introduce something else into the discussion to break the cycle. We keep talking about needing leadership but then seem to fail to do anything about it.
My point was that this happens at least in part because we too often conflate leadership with "telling people what to do".
Throwing "power" into the mix is largely in response to my observations and own personal experience that when a project or PTL is either:
* acting in bad faith, contrary to the wider vision, or holding an effective veto over a positive change much of the rest of the community wants * feared that they might do any of those things in the prior point, even if they haven't demonstrated such
the TC clams up, walks away, and tries to come at things from another angle which won't cause a disruption to the fragile peace.
We should assume that those kinds of situations come about due to people having different ideas about what OpenStack is supposed to be, rather than acting in bad faith or putting the wellbeing of their own project ahead of the whole community (which would be in contravention of our community principles: https://governance.openstack.org/tc/reference/principles.html#openstack-firs...). Under that assumption, I agree with you that it's important to force a conversation that leads to some resolution (after all, it's entirely possible that the project/PTL that is in conflict with the rest of the community is right!), rather than trying to paper over the issue. It's very difficult to tell somebody that they're acting "contrary to the wider vision" if you can't tell them what the wider vision is though. I'm hoping that having actually documented a vision for OpenStack clouds now, we have something to point to and ask "which part of this do you think should change?". It's... strange, if not exactly surprising, to me that facilitating those kinds of conversations (starting with making sure they happen) isn't something we have consensus on as being part of the TC's role.
So, in a bit of reverse psychology: If the TC can't control the projects, maybe the projects should just be the TC?
It's an interesting idea - and a great discussion - but ultimately if a PTL is not negotiating with the rest of the community now, what about putting them on the TC (presumably against their will, as many could run and quite likely win a seat already if they actually wanted) would prompt them to start? Noblesse oblige? I don't see a viable alternative to actually herding the cats, and getting the folks who are working in a different direction to articulate where they disagree and adjust course if necessary. (And if the TC does not do this, it will continue to remain un-done, because there is no other group that possesses the moral authority to try.) cheers, Zane.
Ah. Thanks for the clarification. You raise some interesting questions. Lets explore a bit. Like you, I have no idea what the right solution is. just thinking out loud. "What if the TC and PTLs were the same thing?" One risk of making them the same is what I was talking about before. But what about one way association rather then both ways? something like "All PTL's have a seat on the TC and are required to attend meetings if possible"? That would allow the PTL's to have a voice in the TC, to know what's going on at the greater level and more easily feed back such info to the projects? It also would not block non ptl's from having a voice too if elected. It might be easier to make decisions that effect all the projects? Would something like that have the effect you were thinking? You mention that there might not be time for PTL's to do both things. Is there a scope of what a PTL does somewhere we could look at? Maybe some of the scope could be moved to a different role to enable the TC stuff? A co-PTL or something? Thanks, Kevin ________________________________________ From: Chris Dent [cdent+os@anticdent.org] Sent: Tuesday, January 15, 2019 3:01 AM To: openstack-discuss@lists.openstack.org Subject: RE: [tc] [all] Please help verify the role of the TC On Mon, 14 Jan 2019, Fox, Kevin M wrote:
Been chewing on this thread for a while.... I think I should advocate the other direction.
I'm not sure where to rejoin this thread, so picking here as it provides a reasonable entry point. First: thanks to everyone who has joined in, I honestly do feel that as annoying as these discussions can be, they often reveal something useful. Second, things went a bit sideways from the point I was trying to reach. I wasn't trying to say that PTLs are the obvious and experienced choice for TC leadership, nor that they were best placed to represent the community. I hope that my own behavior over the past few years has made it clear that I very definitely do not feel that way. However, as most respondents on this thread have pointed out, both TC members and PTLs are described as being over-tasked. What I'm trying to tease out or ask is: Are they over-tasked because they are working on too many things (or at least trying to sort through the too many things); a situation that results from _no unified technical leadership for the community_. My initial assertion was that the TC is insufficiently involved in defining and performing technical leadership. 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. Thus: What if the TC and PTLs were the same thing? Would it become more obvious that there's too much in play to make progress in a unified direction (on the thing called OpenStack), leading us to choose less to do, and choose more consistency and actionable leadership? And would it enable some power to execute on that leadership. Those are questions, not assertions.
Getting some diversity of ideas from outside of those from PTL's is probably a good idea for the overall health of OpenStack. What about Users that have never been PTL's? Not developers?
So, to summarize: While I agree we need a diversity of ideas, I don't think we lack for ideas, nor have we ever. What we lack is a small enough set of ideas to act on them with significant enough progress to make a real difference. How can we make the list small and (to bring this back to the TC role) empower the TC to execute on that list? And, to be complete, should we? And, to be extra really complete, I'm not sure if we should or not, which is why I'm asking. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
Ah. Thanks for the clarification. You raise some interesting questions.
Lets explore a bit. Like you, I have no idea what the right solution is. just thinking out loud.
"What if the TC and PTLs were the same thing?" One risk of making them the same is what I was talking about before. But what about one way association rather then both ways? something like "All PTL's have a seat on the TC and are required to attend meetings if possible"? That would allow the PTL's to have a voice in the TC, to know what's going on at the greater level and more easily feed back such info to the projects? It also would not block non ptl's from having a voice too if elected. It might be easier to make decisions that effect all the projects?
Would something like that have the effect you were thinking?
You mention that there might not be time for PTL's to do both things. Is there a scope of what a PTL does somewhere we could look at? Maybe some of the scope could be moved to a different role to enable the TC stuff? A co-PTL or something? minor comment on this point, PTL are already playing typically 3 roles that of the PTL and that of a core reviewer and often that of an indivigual contributor. i do like the idea of PTLs haveing a voice on the TC but it may be asking a lot for them to take on 4th role in paralle to the 3 they already have. so rather
On Tue, 2019-01-15 at 16:52 +0000, Fox, Kevin M wrote: then mandate that a PTL must attend if they can they could be given an optional seat with the ablity to deleaget that to another core memember. simliar to project/release liasons each project could have a TC liason that can default to the PTL or anoter core team memeber that they nominate to take there place?
Thanks, Kevin ________________________________________ From: Chris Dent [cdent+os@anticdent.org] Sent: Tuesday, January 15, 2019 3:01 AM To: openstack-discuss@lists.openstack.org Subject: RE: [tc] [all] Please help verify the role of the TC
On Mon, 14 Jan 2019, Fox, Kevin M wrote:
Been chewing on this thread for a while.... I think I should advocate the other direction.
I'm not sure where to rejoin this thread, so picking here as it provides a reasonable entry point. First: thanks to everyone who has joined in, I honestly do feel that as annoying as these discussions can be, they often reveal something useful.
Second, things went a bit sideways from the point I was trying to reach. I wasn't trying to say that PTLs are the obvious and experienced choice for TC leadership, nor that they were best placed to represent the community. I hope that my own behavior over the past few years has made it clear that I very definitely do not feel that way.
However, as most respondents on this thread have pointed out, both TC members and PTLs are described as being over-tasked. What I'm trying to tease out or ask is: Are they over-tasked because they are working on too many things (or at least trying to sort through the too many things); a situation that results from _no unified technical leadership for the community_.
My initial assertion was that the TC is insufficiently involved in defining and performing technical leadership.
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.
Thus: What if the TC and PTLs were the same thing? Would it become more obvious that there's too much in play to make progress in a unified direction (on the thing called OpenStack), leading us to choose less to do, and choose more consistency and actionable leadership? And would it enable some power to execute on that leadership.
Those are questions, not assertions.
Getting some diversity of ideas from outside of those from PTL's is probably a good idea for the overall health of OpenStack. What about Users that have never been PTL's? Not developers?
So, to summarize: While I agree we need a diversity of ideas, I don't think we lack for ideas, nor have we ever. What we lack is a small enough set of ideas to act on them with significant enough progress to make a real difference. How can we make the list small and (to bring this back to the TC role) empower the TC to execute on that list?
And, to be complete, should we?
And, to be extra really complete, I'm not sure if we should or not, which is why I'm asking.
-- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
Ah. Thanks for the clarification. You raise some interesting questions.
Lets explore a bit. Like you, I have no idea what the right solution is. just thinking out loud.
"What if the TC and PTLs were the same thing?" One risk of making them the same is what I was talking about before. But what about one way association rather then both ways? something like "All PTL's have a seat on the TC and are required to attend meetings if possible"? That would allow the PTL's to have a voice in the TC, to know what's going on at the greater level and more easily feed back such info to the projects? It also would not block non ptl's from having a voice too if elected. It might be easier to make decisions that effect all the projects?
Would something like that have the effect you were thinking?
You mention that there might not be time for PTL's to do both things. Is there a scope of what a PTL does somewhere we could look at? Maybe some of the scope could be moved to a different role to enable the TC stuff? A co-PTL or something? minor comment on this point, PTL are already playing typically 3 roles that of the PTL and that of a core reviewer and often that of an indivigual contributor. i do like the idea of PTLs haveing a voice on the TC but it may be asking a lot for them to take on 4th role in paralle to the 3 they already have. so rather
Yeah. I think what I was getting at was that project leadership would be able to gather info about how they fit in the greater OpenStack via the TC, get a voice in how cross project issues could be solved, and feed back that information and prioritize cross project work on their project. If its optional, then that might not happen properly. Delegating that authority might be a good solution as you suggest. But then delegation of prioritizing of reviews and other such things might need to go along with it at the same time to be effective? The idea is for there to be a flow of leadership from the TC to the project for some of the cross project work, but if that flow cant happen, then nothing really changed. Not so sure a delegate can have enough power to really be effective that way? Thoughts? Thanks, Kevin ________________________________________ From: Sean Mooney [smooney@redhat.com] Sent: Tuesday, January 15, 2019 9:04 AM To: Fox, Kevin M; Chris Dent; openstack-discuss@lists.openstack.org Subject: Re: [tc] [all] Please help verify the role of the TC On Tue, 2019-01-15 at 16:52 +0000, Fox, Kevin M wrote: then mandate that a PTL must attend if they can they could be given an optional seat with the ablity to deleaget that to another core memember. simliar to project/release liasons each project could have a TC liason that can default to the PTL or anoter core team memeber that they nominate to take there place?
Thanks, Kevin ________________________________________ From: Chris Dent [cdent+os@anticdent.org] Sent: Tuesday, January 15, 2019 3:01 AM To: openstack-discuss@lists.openstack.org Subject: RE: [tc] [all] Please help verify the role of the TC
On Mon, 14 Jan 2019, Fox, Kevin M wrote:
Been chewing on this thread for a while.... I think I should advocate the other direction.
I'm not sure where to rejoin this thread, so picking here as it provides a reasonable entry point. First: thanks to everyone who has joined in, I honestly do feel that as annoying as these discussions can be, they often reveal something useful.
Second, things went a bit sideways from the point I was trying to reach. I wasn't trying to say that PTLs are the obvious and experienced choice for TC leadership, nor that they were best placed to represent the community. I hope that my own behavior over the past few years has made it clear that I very definitely do not feel that way.
However, as most respondents on this thread have pointed out, both TC members and PTLs are described as being over-tasked. What I'm trying to tease out or ask is: Are they over-tasked because they are working on too many things (or at least trying to sort through the too many things); a situation that results from _no unified technical leadership for the community_.
My initial assertion was that the TC is insufficiently involved in defining and performing technical leadership.
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.
Thus: What if the TC and PTLs were the same thing? Would it become more obvious that there's too much in play to make progress in a unified direction (on the thing called OpenStack), leading us to choose less to do, and choose more consistency and actionable leadership? And would it enable some power to execute on that leadership.
Those are questions, not assertions.
Getting some diversity of ideas from outside of those from PTL's is probably a good idea for the overall health of OpenStack. What about Users that have never been PTL's? Not developers?
So, to summarize: While I agree we need a diversity of ideas, I don't think we lack for ideas, nor have we ever. What we lack is a small enough set of ideas to act on them with significant enough progress to make a real difference. How can we make the list small and (to bring this back to the TC role) empower the TC to execute on that list?
And, to be complete, should we?
And, to be extra really complete, I'm not sure if we should or not, which is why I'm asking.
-- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On Tue, 15 Jan 2019, Fox, Kevin M wrote:
If its optional, then that might not happen properly. Delegating that authority might be a good solution as you suggest. But then delegation of prioritizing of reviews and other such things might need to go along with it at the same time to be effective? The idea is for there to be a flow of leadership from the TC to the project for some of the cross project work, but if that flow cant happen, then nothing really changed. Not so sure a delegate can have enough power to really be effective that way? Thoughts?
Delegation also simply spreads things around over a wider base, rather than addressing one of the core issues: there are too many things going on at once for there to be anything could be labeled a "unified direction". If we want (do we?) a unified direction, there have to be fewer directions. Positioning things as a "a delegate will do it" is a way of choosing to not limit the number of things being done. There are two competing voices around these issues, both have merit, but they remain in competition. One says: the role of the TC is to enable healthy contribution in all its many and diverse forms in the context of a community called OpenStack. Another says: the role of the TC is to help shape a product [1] called OpenStack. The first sounds rather positive: We're enabling lots of stuff, look at all the stuff! The second is often perceived as rather negative: That stuff could be so much better! None of these perceptions are complete or fully accurate, there are positives and negatives in all views, but what seems to come out of these conversations is that there are some very small and vocal minorities that care about these issues and have strong opinions, and everyone else doesn't care. Do they (you, silent readers!) not care, are they not interested, or is it a matter of "we've been over this before and nothing ever changes?" [1] I bristle at the term "product" because it sounds like we're trying to sell something. I'm thinking more in terms of "a thing that is being produced and has a purpose". -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On Tue, 15 Jan 2019, Fox, Kevin M wrote:
If its optional, then that might not happen properly. Delegating that authority might be a good solution as you suggest. But then delegation of prioritizing of reviews and other such things might need to go along with it at the same time to be effective? The idea is for there to be a flow of leadership from the TC to the project for some of the cross project work, but if that flow cant happen, then nothing really changed. Not so sure a delegate can have enough power to really be effective that way? Thoughts?
Delegation also simply spreads things around over a wider base, rather than addressing one of the core issues: there are too many things going on at once for there to be anything could be labeled a "unified direction".
If we want (do we?) a unified direction, there have to be fewer directions. Positioning things as a "a delegate will do it" is a way of choosing to not limit the number of things being done. well the delegate suggestion was more. if a PTL feels they are too busy with there other duties but in the comunity and in there company
On Wed, 2019-01-16 at 12:33 +0000, Chris Dent wrote: they could ask another core member to attend the TC meeting on there behalf so the number of voice would not change vs the PTL attending. i had assumed it woudl be the role of the TC liason be that the PTL or a delage to bring back a update to the project team e.g. nova in the nova team meeting. collectivly the core team would then discuss the direction form the tc and work with there contiubtors to determin if that direction is viable and either implement it or provide feedback to the tc as to why it is not viable for the project. i think a lot of the valosity of openstack has come form the fact that it has tradtionally been grass roots driven. it is true that it has also slowed progress on some cross project issue and in some cases internal project topic where different compaines or contiutors have differnet prioties but i also dont how the TC would ever truly mitgate company priorits conflicting with TC goals.
There are two competing voices around these issues, both have merit, but they remain in competition.
One says: the role of the TC is to enable healthy contribution in all its many and diverse forms in the context of a community called OpenStack.
Another says: the role of the TC is to help shape a product [1] called OpenStack.
The first sounds rather positive: We're enabling lots of stuff, look at all the stuff!
The second is often perceived as rather negative: That stuff could be so much better!
None of these perceptions are complete or fully accurate, there are positives and negatives in all views, but what seems to come out of these conversations is that there are some very small and vocal minorities that care about these issues and have strong opinions, and everyone else doesn't care. Do they (you, silent readers!) not care, are they not interested, or is it a matter of "we've been over this before and nothing ever changes?"
personally i have always seen the role of the tc in providing guidence on policies that govern openstack, its process and long term direction but not in providing direction to indiviual projects directly. e.g. engaging with all project to develop and implement a timely transtion to python3 first and python 3 only is tc role in my view, both in terms of makeing sure a timeline is cerated and a process to get there is formulated but i dont nessicarly think its the tc role to guide a specific project say swift or nova in how they should migrate to python3 specifically. e.g. if swift had a lib depency that only it used and it needed to change it to move to python 3 then the swift core team should be free to make that decision without tc guidence. as a counter point if the libary was used by several project say eventlet and supose eventlets was not going to support python 3 ever then i think the TC would have cross project role in determining a path forward so we can have a similar technology stack across our projects. so if i was to sumerise my personal view point i think the TCs role is largely in the form of facilitating cross project goals (enabling openstack to "power" the edge) and governace/policy like the PTI, but i think indiviual project should still have the freedom to priories there work and define how they achive that goal and if it is relevent to them. i dont think devstack for example need a dedicated effort to make it ready for the edge, nova and neutron might need just a tad more effort if they wanted to achive that goal.
[1] I bristle at the term "product" because it sounds like we're trying to sell something. I'm thinking more in terms of "a thing that is being produced and has a purpose".
i have a similar reaction to the term product.
With my operator hat on, my experience has taught me to consider user feedback very carefully. It is rare when users actually bother to report bugs. The majority of users tend to not report issues and then grumble about something being broken add just try and work around it. If it goes on long enough, they tend to find entirely different solutions, without ever telling you why you have an issue. Thus leading to your projects decline or even demise. So those users that actually report issues are great. They provide the opportunity to fix something before it is too late. So, its not that the silent majority doesnt care. They do. But tend not to be vocal. Those that do speakup don't tend to have many voices in and of themselves, but represent a great many other voices that don't tend to speak up. So few voices speaking doesn't mean your doing well and there are few real problems. Just that the feedback isn't happening with many voices. Just my $0.02. There may be other experiences out there. Thanks, Kevin ________________________________________ From: Chris Dent [cdent+os@anticdent.org] Sent: Wednesday, January 16, 2019 4:33 AM To: OpenStack-discuss@lists.openstack.org Subject: RE: [tc] [all] Please help verify the role of the TC On Tue, 15 Jan 2019, Fox, Kevin M wrote:
If its optional, then that might not happen properly. Delegating that authority might be a good solution as you suggest. But then delegation of prioritizing of reviews and other such things might need to go along with it at the same time to be effective? The idea is for there to be a flow of leadership from the TC to the project for some of the cross project work, but if that flow cant happen, then nothing really changed. Not so sure a delegate can have enough power to really be effective that way? Thoughts?
Delegation also simply spreads things around over a wider base, rather than addressing one of the core issues: there are too many things going on at once for there to be anything could be labeled a "unified direction". If we want (do we?) a unified direction, there have to be fewer directions. Positioning things as a "a delegate will do it" is a way of choosing to not limit the number of things being done. There are two competing voices around these issues, both have merit, but they remain in competition. One says: the role of the TC is to enable healthy contribution in all its many and diverse forms in the context of a community called OpenStack. Another says: the role of the TC is to help shape a product [1] called OpenStack. The first sounds rather positive: We're enabling lots of stuff, look at all the stuff! The second is often perceived as rather negative: That stuff could be so much better! None of these perceptions are complete or fully accurate, there are positives and negatives in all views, but what seems to come out of these conversations is that there are some very small and vocal minorities that care about these issues and have strong opinions, and everyone else doesn't care. Do they (you, silent readers!) not care, are they not interested, or is it a matter of "we've been over this before and nothing ever changes?" [1] I bristle at the term "product" because it sounds like we're trying to sell something. I'm thinking more in terms of "a thing that is being produced and has a purpose". -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On Jan 15, 2019, at 5:01 AM, Chris Dent <cdent+os@anticdent.org> 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.
Thus: What if the TC and PTLs were the same thing? Would it become more obvious that there's too much in play to make progress in a unified direction (on the thing called OpenStack), leading us to choose less to do, and choose more consistency and actionable leadership? And would it enable some power to execute on that leadership.
Early on in the development of OpenStack there was a lot of discussion about having a group of elected people act as a sort of BDFL (or, more properly, BDFT, where s/Life/Term). Remember, this was when there was Nova and Swift, and not much else. That approach was abandoned in favor of a more bottom-up approach, and as the number of projects and teams in OpenStack grew, so did the opinions on technical direction. As a result, OpenStack has attracted the sort of people who tend to bristle at the notion of a leader or group of leaders determining technical policy and direction. I always have been and still continue to favor a unified direction for OpenStack as a whole, but I recognize that that ship sailed a long, long time ago, and that trying to add some of that back now would not sit well with most of the community. -- Ed Leafe
On 16/01/19 12:01 AM, Chris Dent wrote:
On Mon, 14 Jan 2019, Fox, Kevin M wrote:
Been chewing on this thread for a while.... I think I should advocate the other direction.
I'm not sure where to rejoin this thread, so picking here as it provides a reasonable entry point. First: thanks to everyone who has joined in, I honestly do feel that as annoying as these discussions can be, they often reveal something useful.
Second, things went a bit sideways from the point I was trying to reach. I wasn't trying to say that PTLs are the obvious and experienced choice for TC leadership, nor that they were best placed to represent the community. I hope that my own behavior over the past few years has made it clear that I very definitely do not feel that way.
However, as most respondents on this thread have pointed out, both TC members and PTLs are described as being over-tasked. What I'm trying to tease out or ask is: Are they over-tasked because they are working on too many things (or at least trying to sort through the too many things); a situation that results from _no unified technical leadership for the community_.
My initial assertion was that the TC is insufficiently involved in defining and performing technical leadership.
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.
Thanks for clarifying this, it's a really interesting question to consider.
Thus: What if the TC and PTLs were the same thing? Would it become more obvious that there's too much in play to make progress in a unified direction (on the thing called OpenStack), leading us to choose less to do, and choose more consistency and actionable leadership? And would it enable some power to execute on that leadership.
I'm not sure we need to speculate, because as you know the TC and PTLs literally were the same thing prior to 2014-ish. My recollection is that there were pluses and minuses, but on the whole I don't think it had the effect you're suggesting it might. On the plus side there was in a sense more diversity of opinion, because every project had an ex officio representative on the TC. Direct election tends to favour the most visible members of the community and, because the most visible folks often have similar roles, for a while that led to a big chunk of the TC all looking at OpenStack from only a couple of different directions. That diversity was limited to existing projects though. That led to the TC effectively becoming a bottleneck for folks that were working on things it didn't need to stand in the way of, as already-overworked folks whose attention was by definition consumed with managing the details of their individual silos lacked the time to do deep investigation into the edges of the big picture. The project structure reform came about in large part to resolve this, which removed the bottleneck but didn't make it any easier for PTLs to focus on the big picture. I don't recall a time when the TC used the opportunity of having the PTLs as its members to manage cross-project goals, though I'd be interested in hearing examples if somebody has a different recollection. It doesn't seem that any of the various permutations of the PTLs-as-TC-members proposal in this thread are workable, for reasons that others have already covered plus a few more: all cause a perverse incentive to create new official projects; many rely on coercing people who are already capable of winning seats on their own merit to work as TC members when they have chosen not to for whatever reason.
Those are questions, not assertions.
Getting some diversity of ideas from outside of those from PTL's is probably a good idea for the overall health of OpenStack. What about Users that have never been PTL's? Not developers?
So, to summarize: While I agree we need a diversity of ideas, I don't think we lack for ideas, nor have we ever. What we lack is a small enough set of ideas to act on them with significant enough progress to make a real difference. How can we make the list small
I think I have more to say about this another day, but here is a crazy thought: what if the list is too big because the ideas are too small? What if we can't agree because the stakes are so low?
and (to bring this back to the TC role) empower the TC to execute on that list?
And, to be complete, should we?
And, to be extra really complete, I'm not sure if we should or not, which is why I'm asking.
On Thu, 17 Jan 2019, Zane Bitter wrote:
Thus: What if the TC and PTLs were the same thing? Would it become more obvious that there's too much in play to make progress in a unified direction (on the thing called OpenStack), leading us to choose less to do, and choose more consistency and actionable leadership? And would it enable some power to execute on that leadership.
I'm not sure we need to speculate, because as you know the TC and PTLs literally were the same thing prior to 2014-ish. My recollection is that there were pluses and minuses, but on the whole I don't think it had the effect you're suggesting it might.
Part and parcel of what I'm suggesting is that less stuff would be considered in the domain of "what do we do?" such that the tyranny of the old/existing projects that you describe is a feature not a bug, as an in-built constraint. It's not a future I really like, but it is one strategy for enabling moving in one direction: cut some stuff. Stop letting so many flowers bloom. Letting those flowers bloom is in the camp of "contribution in all its many and diverse forms".
It doesn't seem that any of the various permutations of the PTLs-as-TC-members proposal in this thread are workable, for reasons that others have already covered plus a few more: all cause a perverse incentive to create new official projects; many rely on coercing people who are already capable of winning seats on their own merit to work as TC members when they have chosen not to for whatever reason.
Yes to all that. I don't think there's an easy solution here, but it's useful to explore the problem space, even if it is simply to see if people think there's a problem.
I think I have more to say about this another day, but here is a crazy thought: what if the list is too big because the ideas are too small? What if we can't agree because the stakes are so low?
I don't think that's a crazy thought, and thank you for bringing it around to this, I hoped someone would get there eventually. This is in the camp of "stuff could be so much better". Which makes it pretty clear that the two voices I described are not actually in opposition. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
Chris Dent <cdent+os@anticdent.org> writes:
On Thu, 17 Jan 2019, Zane Bitter wrote:
Thus: What if the TC and PTLs were the same thing? Would it become more obvious that there's too much in play to make progress in a unified direction (on the thing called OpenStack), leading us to choose less to do, and choose more consistency and actionable leadership? And would it enable some power to execute on that leadership.
I'm not sure we need to speculate, because as you know the TC and PTLs literally were the same thing prior to 2014-ish. My recollection is that there were pluses and minuses, but on the whole I don't think it had the effect you're suggesting it might.
Part and parcel of what I'm suggesting is that less stuff would be considered in the domain of "what do we do?" such that the tyranny of the old/existing projects that you describe is a feature not a bug, as an in-built constraint.
It's not a future I really like, but it is one strategy for enabling moving in one direction: cut some stuff. Stop letting so many flowers bloom.
Letting those flowers bloom is in the camp of "contribution in all its many and diverse forms".
What would you prune? -- Doug
On Thu, 17 Jan 2019, Doug Hellmann wrote: [i wrote]:
It's not a future I really like, but it is one strategy for enabling moving in one direction: cut some stuff. Stop letting so many flowers bloom.
Letting those flowers bloom is in the camp of "contribution in all its many and diverse forms".
What would you prune?
I don't think it should be up to me to decide. That would be a thing "we" (in whatever form) would decide. But if pressed to make a list for the sake of conversation I would endeavor to limit things based on a couple strawperson criteria (below). As I said above I'm not clear that this is the right thing, to do, but it is a potential strategy. Being included in the examples below isn't a suggestion that the thing listed is no good, or should not exist. Rather that it _might_ be healthier with a boundary between it and OpenStack. A clear boundary could allow these flowers to bloom nearby, as well as others. Strategies to figure out what could be removed: * Stuff that could be done via existing non-openstack tools or more generic tools that address cloudy-stuff in general. Much of the stuff in telemetry or orchestration would fit here and some utilities: Telemetry, Cloudkitty, Freezer, Heat, Karbor, Magnum, Monasca, Zun to name just some. If the remaining services are produced in a way that provides suitable observability, then tools like Prometheus, the ELK stack, what have you can play a big part and ansible, terraform, related friends can too. * Deployment tooling (Tripleo, Kolla, Openstackansible, etc) and packaging. It all needs to exist, but it clouds the picture and direction of OpenStack, the thing you have once it is deployed or installed. In a very bad analogy: I make gabbi and I'm not responsible for it becoming an RPM, nor for maintaining pip which is used to install it, but RPMs and pip are very important. If we had a one-true-deployment tool, then having that in this new and smaller OpenStack could make sense, but if we want there to be many tools enabling them to be independent communities from each other could be refreshing. Do I think this is a good idea? I don't know. It's just thinking out loud with half-baked ideas for the sake of conversation with the ever-optimistic hope that it might inspire an actually good idea. Do I think something like this is likely to happen? Not really. Ship sailed. Could a hybrid that includes some of this happen? Potentially, especially if the idea of top-level projects in the foundation grows. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On 18/01/19 1:57 AM, Doug Hellmann wrote:
Chris Dent <cdent+os@anticdent.org> writes:
On Thu, 17 Jan 2019, Zane Bitter wrote:
Thus: What if the TC and PTLs were the same thing? Would it become more obvious that there's too much in play to make progress in a unified direction (on the thing called OpenStack), leading us to choose less to do, and choose more consistency and actionable leadership? And would it enable some power to execute on that leadership.
I'm not sure we need to speculate, because as you know the TC and PTLs literally were the same thing prior to 2014-ish. My recollection is that there were pluses and minuses, but on the whole I don't think it had the effect you're suggesting it might.
Part and parcel of what I'm suggesting is that less stuff would be considered in the domain of "what do we do?" such that the tyranny of the old/existing projects that you describe is a feature not a bug, as an in-built constraint.
It's not a future I really like, but it is one strategy for enabling moving in one direction: cut some stuff. Stop letting so many flowers bloom.
Letting those flowers bloom is in the camp of "contribution in, all its many and diverse forms".
What would you prune?
As a frequent and loud advocate for allowing all of those new projects in, I feel like this is a good moment to take stock and consider whether I might have been mistaken to do so, if only to reassure other folks that they can attempt to answer the question without me yelling at them ;) I do think Chris offers a valid line of enquiry, even though (like him) I don't really like the future that it leads to. I would identify two classes of project that we might consider for pruning in this scenario. * There are a number of projects that in a perfect world would arguably be just a feature rather than a separate service. The general pattern was usually that they had to do something on the compute node that was easier *socially* to get implemented in a separate project; often they also had to do something in the control plane that could potentially have been handled by a combination of other services, but again it was easier to throw that code into the project too rather than force multiple hard dependencies on cloud operators that wanted the feature. Pruning these projects could in theory lead to a more technically justifiable design for the features they support, and help build a critical mass of users for the more generic control plane services (I'm thinking of e.g. Mistral) that might have been used by multiple features, instead of being effectively reimplemented in various hard-coded configurations by multiple projects. * There are a number of projects that proceeded a long way down the path despite containing fundamental design flaws due to workarounds for missing features in services they depended on. In at least one case, multiple companies toiled away diligently for years taking over from one another as each, successively, ran out of runway while still waiting for features to build a sustainable design on top of. In the meantime, we added them to OpenStack and encouraged/demanded that they spend a good fraction of their time and effort on not breaking existing users from release to release. Pruning these projects might folks interested in them the opportunity to forego backwards-compatibility in favour of ensuring the features they need are present first, and then rapidly iterating toward a long-term sustainable design. The problem I still see with this it is that we made all of these decisions for good reasons, which were about getting feedback. We encouraged projects to guarantee backwards compatibility because that's needed to get users to use it for real and give feedback. We added projects that depended on missing features in part to provide feedback to other teams on what features were needed. We added projects that were really features because users needed those features, and there was no other way to hear their feedback. Clearly in some cases, that was not enough. But it's very hard to see how we can get the features users want done with even _less_ feedback. It could be that we don't actually want to get those features done, but interestingly (and slightly surprisingly) during the technical vision exercise nobody suggested we delete every design goal except for "Basic Physical Data Center Management". (If you *do* think we should do that, please propose it as a patch so we can discuss it.) It seems like we all actually kinda agree on where we want to get, but some of the critical paths to getting there may be blocked by other priorities. At this point I actually wouldn't be too unhappy to see a reset, where we said OK we are not going to worry about this other stuff until we've re-architected the building blocks to operate in such a way that they can support all of the additional services we want. Especially if we had a specific plan for prioritising those aspects. But how are we going to get feedback on what exactly it is we need to do without folks in the community building those additional services and features, and users using them? That's not a rhetorical question; if you have ideas I'd like to hear them. cheers, Zane.
On Mon, 21 Jan 2019, Zane Bitter wrote:
It could be that we don't actually want to get those features done, but interestingly (and slightly surprisingly) during the technical vision exercise nobody suggested we delete every design goal except for "Basic Physical Data Center Management". (If you *do* think we should do that, please propose it as a patch so we can discuss it.) It seems like we all actually kinda agree on where we want to get, but some of the critical paths to getting there may be blocked by other priorities.
Moving forward on "all actually kinda agree" is pretty much all we can do. I often fear that the lack of widespread engagement with threads like this one and with reviews like the original vision one or your (Zane's) clarifications [1] represent disinterest. Thus, who is the "all"? However, as you've pointed out, the nature of TC elections mean that the TC is the only community-wide representative body. If people don't speak up in the individual cases, then we don't really have any choice but to assume they have spoken when they elected the people they did. Do that many people vote? Thus my continuous pleas for input. But it's okay. We've had some interesting discussion here, and that's useful. I'm not sure I'm able to make any concrete conclusions about what people want the role of the TC to be other than the same people who have always wanted it to be a reactive governance org still do, and the same people who have always wanted it be an active leadership org still do. I guess those in the latter camp simply need to get on with it. [1] https://review.openstack.org/#/c/631435/ -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
I like the idea for which things to prune. Sounds reasonable to me. For the most part they were technological implementations around a social/governance problem. They can't be pruned until that is resolved. I was pushed that way too for my issues and rather then spawn a new project, I just gave up on creating a new project. So it has gone both ways. Either new projects sprang up or use cases were dropped. Either way, the governence/social aspect needs solving. I still think that is the TC's job to solve. How? Thanks, Kevin ________________________________________ From: Zane Bitter [zbitter@redhat.com] Sent: Monday, January 21, 2019 1:15 AM To: openstack-discuss@lists.openstack.org Subject: Re: [tc] [all] Please help verify the role of the TC On 18/01/19 1:57 AM, Doug Hellmann wrote:
Chris Dent <cdent+os@anticdent.org> writes:
On Thu, 17 Jan 2019, Zane Bitter wrote:
Thus: What if the TC and PTLs were the same thing? Would it become more obvious that there's too much in play to make progress in a unified direction (on the thing called OpenStack), leading us to choose less to do, and choose more consistency and actionable leadership? And would it enable some power to execute on that leadership.
I'm not sure we need to speculate, because as you know the TC and PTLs literally were the same thing prior to 2014-ish. My recollection is that there were pluses and minuses, but on the whole I don't think it had the effect you're suggesting it might.
Part and parcel of what I'm suggesting is that less stuff would be considered in the domain of "what do we do?" such that the tyranny of the old/existing projects that you describe is a feature not a bug, as an in-built constraint.
It's not a future I really like, but it is one strategy for enabling moving in one direction: cut some stuff. Stop letting so many flowers bloom.
Letting those flowers bloom is in the camp of "contribution in, all its many and diverse forms".
What would you prune?
As a frequent and loud advocate for allowing all of those new projects in, I feel like this is a good moment to take stock and consider whether I might have been mistaken to do so, if only to reassure other folks that they can attempt to answer the question without me yelling at them ;) I do think Chris offers a valid line of enquiry, even though (like him) I don't really like the future that it leads to. I would identify two classes of project that we might consider for pruning in this scenario. * There are a number of projects that in a perfect world would arguably be just a feature rather than a separate service. The general pattern was usually that they had to do something on the compute node that was easier *socially* to get implemented in a separate project; often they also had to do something in the control plane that could potentially have been handled by a combination of other services, but again it was easier to throw that code into the project too rather than force multiple hard dependencies on cloud operators that wanted the feature. Pruning these projects could in theory lead to a more technically justifiable design for the features they support, and help build a critical mass of users for the more generic control plane services (I'm thinking of e.g. Mistral) that might have been used by multiple features, instead of being effectively reimplemented in various hard-coded configurations by multiple projects. * There are a number of projects that proceeded a long way down the path despite containing fundamental design flaws due to workarounds for missing features in services they depended on. In at least one case, multiple companies toiled away diligently for years taking over from one another as each, successively, ran out of runway while still waiting for features to build a sustainable design on top of. In the meantime, we added them to OpenStack and encouraged/demanded that they spend a good fraction of their time and effort on not breaking existing users from release to release. Pruning these projects might folks interested in them the opportunity to forego backwards-compatibility in favour of ensuring the features they need are present first, and then rapidly iterating toward a long-term sustainable design. The problem I still see with this it is that we made all of these decisions for good reasons, which were about getting feedback. We encouraged projects to guarantee backwards compatibility because that's needed to get users to use it for real and give feedback. We added projects that depended on missing features in part to provide feedback to other teams on what features were needed. We added projects that were really features because users needed those features, and there was no other way to hear their feedback. Clearly in some cases, that was not enough. But it's very hard to see how we can get the features users want done with even _less_ feedback. It could be that we don't actually want to get those features done, but interestingly (and slightly surprisingly) during the technical vision exercise nobody suggested we delete every design goal except for "Basic Physical Data Center Management". (If you *do* think we should do that, please propose it as a patch so we can discuss it.) It seems like we all actually kinda agree on where we want to get, but some of the critical paths to getting there may be blocked by other priorities. At this point I actually wouldn't be too unhappy to see a reset, where we said OK we are not going to worry about this other stuff until we've re-architected the building blocks to operate in such a way that they can support all of the additional services we want. Especially if we had a specific plan for prioritising those aspects. But how are we going to get feedback on what exactly it is we need to do without folks in the community building those additional services and features, and users using them? That's not a rhetorical question; if you have ideas I'd like to hear them. cheers, Zane.
On 2019-01-17 20:41:49 +1300 (+1300), Zane Bitter wrote: [...]
I'm not sure we need to speculate, because as you know the TC and PTLs literally were the same thing prior to 2014-ish. [...]
Minor historical notes: the role now occupied by the TC was originally filled by a governance body known as the Project Oversight Committee which then later became the Project Policy Board (PPB). A description of our pre-foundation technical governance can still be found undisturbed and rotting in our wiki at the moment, should you be in the mood for a bit of light reading: https://wiki.openstack.org/wiki/Governance/OldModel The PPB was replaced by (but essentially renamed to) the Technical Committee in September 2012, as required in appendix 4 of the bylaws for the then-newly-formed OpenStack Foundation (note that the text there defining the initial TC election is slated for removal in the bylaws amendment currently up for a vote of the individual members): https://www.openstack.org/legal/technical-committee-member-policy/ The very first two TC elections did still include PTLs who had guaranteed TC seats: https://wiki.openstack.org/wiki/Governance/TCElectionsFall2012 https://wiki.openstack.org/wiki/TC_Elections_Spring_2013 But the subsequent election in late 2013 switched to the free-for-all model we've come to know today with the adoption of the new TC Charter: https://wiki.openstack.org/wiki/TC_Elections_Spring_2013 Now I'm wondering whether we should form an OpenStack Historical Preservation Society. ;) -- Jeremy Stanley
On 18/01/19 5:33 AM, Jeremy Stanley wrote:
On 2019-01-17 20:41:49 +1300 (+1300), Zane Bitter wrote: [...]
I'm not sure we need to speculate, because as you know the TC and PTLs literally were the same thing prior to 2014-ish. [...]
Minor historical notes: the role now occupied by the TC was originally filled by a governance body known as the Project Oversight Committee which then later became the Project Policy Board (PPB). A description of our pre-foundation technical governance can still be found undisturbed and rotting in our wiki at the moment, should you be in the mood for a bit of light reading: https://wiki.openstack.org/wiki/Governance/OldModel
The PPB was replaced by (but essentially renamed to) the Technical Committee in September 2012, as required in appendix 4 of the bylaws for the then-newly-formed OpenStack Foundation (note that the text there defining the initial TC election is slated for removal in the bylaws amendment currently up for a vote of the individual members): https://www.openstack.org/legal/technical-committee-member-policy/
The very first two TC elections did still include PTLs who had guaranteed TC seats: https://wiki.openstack.org/wiki/Governance/TCElectionsFall2012 https://wiki.openstack.org/wiki/TC_Elections_Spring_2013
But the subsequent election in late 2013 switched to the free-for-all model we've come to know today with the adoption of the new TC Charter: https://wiki.openstack.org/wiki/TC_Elections_Spring_2013
Now I'm wondering whether we should form an OpenStack Historical Preservation Society. ;)
Thanks for the history lesson! I started keeping up with TC business probably soon after that first election (Heat was applying for incubation, and was accepted in November 2012 - the same day as the US Presidential election IIRC), but I don't think I was aware (or at least I had completely forgotten) that that was the first election since the TC replaced the PPB. - ZB
On 2019-01-17 16:33:51 +0000 (+0000), Jeremy Stanley wrote: [...]
But the subsequent election in late 2013 switched to the free-for-all model we've come to know today with the adoption of the new TC Charter: https://wiki.openstack.org/wiki/TC_Elections_Spring_2013 [...]
And for anyone who found themselves scratching their heads over this, yes I meant to link https://wiki.openstack.org/wiki/TC_Elections_Fall_2013 instead. (Note also how back then we seemed to ignore the fact that naming things based on seasons excluded half of the World.) -- Jeremy Stanley
Jeremy Stanley wrote:
On 2019-01-17 20:41:49 +1300 (+1300), Zane Bitter wrote: [...]
I'm not sure we need to speculate, because as you know the TC and PTLs literally were the same thing prior to 2014-ish. [...]
Minor historical notes: the role now occupied by the TC was originally filled by a governance body known as the Project Oversight Committee which then later became the Project Policy Board (PPB). A description of our pre-foundation technical governance can still be found undisturbed and rotting in our wiki at the moment, should you be in the mood for a bit of light reading: https://wiki.openstack.org/wiki/Governance/OldModel
The PPB was replaced by (but essentially renamed to) the Technical Committee in September 2012, as required in appendix 4 of the bylaws for the then-newly-formed OpenStack Foundation (note that the text there defining the initial TC election is slated for removal in the bylaws amendment currently up for a vote of the individual members): https://www.openstack.org/legal/technical-committee-member-policy/
The very first two TC elections did still include PTLs who had guaranteed TC seats: https://wiki.openstack.org/wiki/Governance/TCElectionsFall2012 https://wiki.openstack.org/wiki/TC_Elections_Spring_2013
But the subsequent election in late 2013 switched to the free-for-all model we've come to know today with the adoption of the new TC Charter: https://wiki.openstack.org/wiki/TC_Elections_Spring_2013
Now I'm wondering whether we should form an OpenStack Historical Preservation Society. ;)
The history is actually documented outside the wiki: https://docs.openstack.org/project-team-guide/introduction.html#a-quick-hist... -- Thierry Carrez (ttx)
Thierry Carrez wrote:
Minor historical notes: the role now occupied by the TC was originally filled by a governance body known as the Project Oversight Committee which then later became the Project Policy Board (PPB). [...]
Actually no, we started with an Advisory Board, an Architecture Board, one Technical Committee for Nova and one Technical Committee for Swift :) The POC was introduced early 2011. -- Thierry Carrez (ttx)
On 2019-01-18 15:09:51 +0100 (+0100), Thierry Carrez wrote:
Thierry Carrez wrote:
Minor historical notes: the role now occupied by the TC was originally filled by a governance body known as the Project Oversight Committee which then later became the Project Policy Board (PPB). [...]
Actually no, we started with an Advisory Board, an Architecture Board, one Technical Committee for Nova and one Technical Committee for Swift :) The POC was introduced early 2011.
Thanks! I somehow missed that we had a similar overview in the Project Teams Guide which went back even farther than I could find in the old wiki reference articles (though it does still lack much of the detail retained in those older sources). -- Jeremy Stanley
On Fri, 2019-01-18 at 15:09 +0100, Thierry Carrez wrote:
Thierry Carrez wrote:
Minor historical notes: the role now occupied by the TC was originally filled by a governance body known as the Project Oversight Committee which then later became the Project Policy Board (PPB). [...]
Actually no, we started with an Advisory Board, an Architecture Board, one Technical Committee for Nova and one Technical Committee for Swift :) The POC was introduced early 2011.
by the way the fact that we can have these conversation openly in openstack and proide input regardless of if we are members of the TC or not i think is one of the strengths of the openstack comunity and governace model/process. so i just wanted to say im glad we are having this conversation as a comunity.
On 2019-01-18 14:20:47 +0000 (+0000), Sean Mooney wrote: [...]
by the way the fact that we can have these conversation openly in openstack and proide input regardless of if we are members of the TC or not i think is one of the strengths of the openstack comunity and governace model/process. so i just wanted to say im glad we are having this conversation as a comunity.
...and not only that, but the ability to also stand for election. We're less than a month from time for declaring candidacy for available TC seats. Anyone who's interested in these matters should run if they can swing it. Be thinking about your platform statements and let's get a great bunch of candidates on the ballot! -- Jeremy Stanley
On Tue, Jan 15, 2019, at 12:01 PM, Chris Dent wrote: [snipped]
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.
While I understand that the TC may feel frustrated that they do not always feel like they have sufficient insight and influence into the ongoings of individual projects, I actually believe that this is the better way to operate. If individual team leaders were also tasked with leading the entire community as well, there would be significant conflicts of interest. PTLs are responsible for doing what is in the best interest for their project, and the TC is responsible for doing what is in the best interest of the whole community, and in the places where those do not 100% line up there is discussion and compromise. It is hard and sometimes painful and it means progress is very slow, but it is healthy. If a single body was acting as dictator for the whole community, progress might speed up but we would be losing out on the diversity of opinion that makes this community great. But as others have pointed out, in reality the TC is already largely made up of people who do have influence and insight into a large part of the individual projects and I'm not sure it really helps. TC members are always trying to be very careful about taking one hat off as they put another on and it creates quite a cognitive burden. I'm fairly sure Jeremy, to take one example, could have a heated debate by himself from at least eight different perspectives on any community topic. Everyone on the TC has sufficient influence to enact whatever change they decide is needed. What's lacking is agreement on what to act on...
Thus: What if the TC and PTLs were the same thing? Would it become more obvious that there's too much in play to make progress in a unified direction (on the thing called OpenStack), leading us to choose less to do, and choose more consistency and actionable leadership? And would it enable some power to execute on that leadership.
Those are questions, not assertions.
Getting some diversity of ideas from outside of those from PTL's is probably a good idea for the overall health of OpenStack. What about Users that have never been PTL's? Not developers?
So, to summarize: While I agree we need a diversity of ideas, I don't think we lack for ideas, nor have we ever. What we lack is a small enough set of ideas to act on them with significant enough progress to make a real difference. How can we make the list small and (to bring this back to the TC role) empower the TC to execute on that list?
Indeed. There are very very many improvements that could be made. None of them are so critical that it's obvious what to start with. OpenStack has matured enough that the community and the software are working pretty well most of the time, there aren't really any emergencies.
And, to be complete, should we?
And, to be extra really complete, I'm not sure if we should or not, which is why I'm asking.
Returning to your original request for feedback, my expectation of the TC is much more passive than you imply it should be. I'm happy for the TC to do the work of approving new projects, acting as bridges to the board and foundation, mediating conflicts which can't otherwise be resolved and providing guidance as needed when the community needs it or asks for it. Grassroots change can start with any community member, whether or not they are elected to the TC. I don't think it needs to be the TC's job to drive grandiose changes for the sake of progress. Colleen
On 2019-01-17 17:46:47 +0100 (+0100), Colleen Murphy wrote: [...]
I'm fairly sure Jeremy, to take one example, could have a heated debate by himself from at least eight different perspectives on any community topic. [...]
So what you're saying is I spend a lot of time talking to myself? That would certainly explain why I'm always so hoarse. ;) [with my jester's cap on] -- Jeremy Stanley
On 1/17/19 11:11 AM, Jeremy Stanley wrote:
[with my jester's cap on]
Hey, Foundation folks, I have an idea for swag at the next summit. ;-) And so this isn't a completely content-less email, I will provide my perspective on the actual topic of the thread too. Reading the document, it seems to me that it describes less a "Technical" Committee and more a "Governance" Committee. It's right there in first two headings, and I would argue that the collaboration and maybe scope sections fit better with that too. I will grant that the release goals don't really fit my theory as those are technical first and foremost, but they're also sort of the exception not the rule. When I vote for members of a body with "technical" in its name, I expect those people to be driving the technical direction of the project. Per the document, and based on my past observation of the TC, I would say that it has actively avoided driving the technical direction of OpenStack in favor of the bottom-up philosophy mentioned elsewhere in this thread. That has always created some cognitive dissonance for me. I feel like a lot of the discussion in this thread has been around whether the TC should be a primarily technical body or a primarily governance body. While I don't want to get lost bikeshedding over naming, I hadn't previously considered that maybe the TC isn't (and shouldn't be?) an actual technical group. I'm not sure I have a definite answer for that right now though, so consider this a WIP opinion and maybe a useful alternate way of looking at the question. -Ben
On Jan 17, 2019, at 2:20 PM, Ben Nemec <openstack@nemebean.com> wrote:
Reading the document, it seems to me that it describes less a "Technical" Committee and more a "Governance" Committee. It's right there in first two headings, and I would argue that the collaboration and maybe scope sections fit better with that too. I will grant that the release goals don't really fit my theory as those are technical first and foremost, but they're also sort of the exception not the rule.
When I vote for members of a body with "technical" in its name, I expect those people to be driving the technical direction of the project. Per the document, and based on my past observation of the TC, I would say that it has actively avoided driving the technical direction of OpenStack in favor of the bottom-up philosophy mentioned elsewhere in this thread. That has always created some cognitive dissonance for me.
That observation has been made by many (myself included) in the past. The TC has actively avoided any sort of appearance of forcing or mandating any particular technical approach or solution. -- Ed Leafe
On 2019-01-17 14:20:10 -0600 (-0600), Ben Nemec wrote: [...]
Reading the document, it seems to me that it describes less a "Technical" Committee and more a "Governance" Committee. [...]
I mused similarly some time back (in an ML post I'm having trouble finding now) that I consider the choice of naming for the "technical committee" unfortunate, as I see our role being one of community management and arbitration. Section 4.13.b.i of the OSF bylaws describes the responsibilities and powers of the TC thusly: "The Technical Committee shall have the authority to manage the OpenStack Project, including the authority to determine the scope of the OpenStack Technical Committee Approved Release..." (the latter is specifically with regard to application of the OpenStack trademark for products) https://www.openstack.org/legal/bylaws-of-the-openstack-foundation/ So I guess a lot of it comes down to how we interpret "manage" in that context. If you don't see the TC as the appropriate body to provide governance for the OpenStack project, then who do you think should take that on instead? Section 4.1.b.i of the bylaws mentions that "management of the technical matters relating to the OpenStack Project [...] shall be managed by the Technical Committee" and also "management of the technical matters for the OpenStack Project is designed to be a technical meritocracy" but doesn't go into details as to what it means by "technical matters" (beyond deciding what qualifies for trademark use). It seems to me that by delegating subproject-specific technical decisions to team leaders elected from each subproject, and then handling decisions which span projects (the technical vision document, project teams guide, cycle goals selection, et cetera), we meet both the letter and the spirit of the duties outlined for the OpenStack Technical Committee in the OSF bylaws. But as noted, a lot of this hinges on how people take the somewhat fuzzy terms above in the context with which they're given. -- Jeremy Stanley
Jeremy Stanley wrote:
On 2019-01-17 14:20:10 -0600 (-0600), Ben Nemec wrote: [...]
Reading the document, it seems to me that it describes less a "Technical" Committee and more a "Governance" Committee. [...]
I mused similarly some time back (in an ML post I'm having trouble finding now) that I consider the choice of naming for the "technical committee" unfortunate, as I see our role being one of community management and arbitration. Section 4.13.b.i of the OSF bylaws describes the responsibilities and powers of the TC thusly:
"The Technical Committee shall have the authority to manage the OpenStack Project, including the authority to determine the scope of the OpenStack Technical Committee Approved Release..." (the latter is specifically with regard to application of the OpenStack trademark for products)
This comes back to the original foundation of the... ahem... Foundation. We used to have a "Project Policy Board" that covered it all. When the Foundation was formed, we wanted to make sure the open source project would be governed by its contributors, and not by the Foundation board of Directors. So the PPB's rights and duties were split between the Board of Directors (to stay out of technical matters) and a "technical committee". A better naming would have been "open source project governance group" or "upstream matters decisions group" (everything upstream from the release of the software). "Technical" is a pretty simplistic way of describing it, if only because there are "technical" things on the downstream side, like what the User Committee covers, or the interoperability programs. -- Thierry Carrez (ttx)
On 1/17/19 5:58 PM, Jeremy Stanley wrote:
On 2019-01-17 14:20:10 -0600 (-0600), Ben Nemec wrote: [...]
Reading the document, it seems to me that it describes less a "Technical" Committee and more a "Governance" Committee. [...]
I mused similarly some time back (in an ML post I'm having trouble finding now) that I consider the choice of naming for the "technical committee" unfortunate, as I see our role being one of community management and arbitration. Section 4.13.b.i of the OSF bylaws describes the responsibilities and powers of the TC thusly:
"The Technical Committee shall have the authority to manage the OpenStack Project, including the authority to determine the scope of the OpenStack Technical Committee Approved Release..." (the latter is specifically with regard to application of the OpenStack trademark for products)
https://www.openstack.org/legal/bylaws-of-the-openstack-foundation/
So I guess a lot of it comes down to how we interpret "manage" in that context. If you don't see the TC as the appropriate body to provide governance for the OpenStack project, then who do you think should take that on instead?
I didn't mean to imply that I thought the TC _shouldn't_ be providing governance. I was just observing that the TC's activity seems to be slanted toward governance and away from what I would consider technical. Based on my philosophy that things are rarely black and white, I suspect the best place for the TC is going to be some happy medium between technical and governance activity. Which I realize is a totally unhelpful stance to take because it basically means my answer to "Should the TC do X" is always going to be "It depends." Maybe it would be useful to revisit some specific historical situations where people feel the TC should or should not have stepped in? A lot of the discussion I've seen so far has been in the abstract, but some more concrete examples might help define what people want/expect from the TC.
Section 4.1.b.i of the bylaws mentions that "management of the technical matters relating to the OpenStack Project [...] shall be managed by the Technical Committee" and also "management of the technical matters for the OpenStack Project is designed to be a technical meritocracy" but doesn't go into details as to what it means by "technical matters" (beyond deciding what qualifies for trademark use). It seems to me that by delegating subproject-specific technical decisions to team leaders elected from each subproject, and then handling decisions which span projects (the technical vision document, project teams guide, cycle goals selection, et cetera), we meet both the letter and the spirit of the duties outlined for the OpenStack Technical Committee in the OSF bylaws. But as noted, a lot of this hinges on how people take the somewhat fuzzy terms above in the context with which they're given.
Chris Dent wrote:
[...] Since there is a significant and friction creating division of power and leadership between the TC and PTLs,
I'm not sure I follow you there... the division of power is between keeping an eye on the big picture and caring for OpenStack as a whole (TC) vs. rubber-hits-the-road, being responsible for a specific set of deliverables (PTL). The same individuals can care for both concerns, but those are different tasks... I think the division is clear. The only friction I've observed recently is when it comes to driving cross-project work -- an area that TC members and affected PTLs care about. We need more people driving that type of work, and as we've said in other threads, TC members (as well as other respected members of our community) are in a good position to help drive that work.
[...] what would it be like if we required half or more of the TC be elected from PTLs? Then the "providing the technical leadership" aspect of the TC mission [3] would be vested with the people who also have some responsibility for executing on that leadership.
That would be like something we had before, but now there are many more PTLs.
I don't think PTLs have any difficulty getting elected when they run, so I'm not sure a provision that the TC must have reserved seats for PTLs would have a significant impact, beyond complicating the election process. In terms of increasing TC efficiency... As others said, being a PTL for a large project is already a lot of work and that leaves little to do "TC work". And if the goal is to get more TC members to drive cross-project work, the main reason TC members don't drive (more) cross-project work is generally that they don't have enough bandwidth to do so. Mandating more PTLs to be TC members is unlikely to result in a TC membership with more available cross-project work bandwidth... I agree that it is important to have representation of classic developer teams on the TC, but I feel like today's TC membership is a good mix between horizontal teams and vertical teams, including deployment concerns and adjacent communities perspective. We should definitely continue to encourage TC candidacies from vertical/classic project teams, but I don't think that should be reduced to PTLs, and I don't think that should be reserved seats. -- Thierry Carrez (ttx)
Friction between PTL's/projects and cross project work is not a new thing. It has been a major issue for OpenStack almost since inception. There were some hurtles I had when trying to make any progress on cross project work that ultimately caused me to give up. (I'll make some generalizations here... not saying everyone has these issues) * PTL's (and the whole project really) tend only to look at their corner of the OpenStack and not so much how their project fits into the greater picture. * PTL's have been good about discussing cross project issues when directly raised, but push back that their project should be part of the solution. The other project is always the better place to solve it, or a new project should solve it. That needs to stop being the go to answer. * PTL's don't go out and actively look where their project does not play so well in the grater OpenStack. They focus on solving their own problems. This leads to architecture that work for a project but fails for the overall OpenStack. * The way code gets into a project mostly involves getting enough capital (reviews) on a given project to get attention when needed. But cross project work doesn't get you enough capital in enough specific projects to ever really progress. There needs to be a cross project review score or something that says, this dev is working on cross project goals and submitting work of that type. give attention to their pr's because their work is important too! PTL's could prioritize this kind of work. So, I kind of like the idea that PTL's need to focus more on the whole, not just their own project, so that they can help lead in the right directions. Right now each project is going in its own directions without much thought to the whole. I'm not trying to blame the folks I've interacted with in the PTL role. They have by and large been very helpful. But the Role of PTL, as well as the TC, have not enabled significant progress on the cross project issues due to these gaps. Maybe part of the solution is tweaking the responsibilities of the PTL's to focus more on cross project issues. Thanks, Kevin ________________________________________ From: Thierry Carrez [thierry@openstack.org] Sent: Tuesday, January 15, 2019 1:49 AM To: openstack-discuss@lists.openstack.org Subject: Re: [tc] [all] Please help verify the role of the TC Chris Dent wrote:
[...] Since there is a significant and friction creating division of power and leadership between the TC and PTLs,
I'm not sure I follow you there... the division of power is between keeping an eye on the big picture and caring for OpenStack as a whole (TC) vs. rubber-hits-the-road, being responsible for a specific set of deliverables (PTL). The same individuals can care for both concerns, but those are different tasks... I think the division is clear. The only friction I've observed recently is when it comes to driving cross-project work -- an area that TC members and affected PTLs care about. We need more people driving that type of work, and as we've said in other threads, TC members (as well as other respected members of our community) are in a good position to help drive that work.
[...] what would it be like if we required half or more of the TC be elected from PTLs? Then the "providing the technical leadership" aspect of the TC mission [3] would be vested with the people who also have some responsibility for executing on that leadership.
That would be like something we had before, but now there are many more PTLs.
I don't think PTLs have any difficulty getting elected when they run, so I'm not sure a provision that the TC must have reserved seats for PTLs would have a significant impact, beyond complicating the election process. In terms of increasing TC efficiency... As others said, being a PTL for a large project is already a lot of work and that leaves little to do "TC work". And if the goal is to get more TC members to drive cross-project work, the main reason TC members don't drive (more) cross-project work is generally that they don't have enough bandwidth to do so. Mandating more PTLs to be TC members is unlikely to result in a TC membership with more available cross-project work bandwidth... I agree that it is important to have representation of classic developer teams on the TC, but I feel like today's TC membership is a good mix between horizontal teams and vertical teams, including deployment concerns and adjacent communities perspective. We should definitely continue to encourage TC candidacies from vertical/classic project teams, but I don't think that should be reduced to PTLs, and I don't think that should be reserved seats. -- Thierry Carrez (ttx)
participants (15)
-
Ben Nemec
-
Chris Dent
-
Colleen Murphy
-
Doug Hellmann
-
Ed Leafe
-
Fox, Kevin M
-
Ghanshyam Mann
-
Jay Bryant
-
Jeremy Stanley
-
Kendall Nelson
-
Michael McCune
-
Sean McGinnis
-
Sean Mooney
-
Thierry Carrez
-
Zane Bitter