 Good to go. Are you recording? Okay. Thank you for coming to the session about the stewardship working group. How many of you went to the cross-project session earlier today? Okay. Those of you who didn't go to the cross-project session, what are you expecting to get out of this session? Shout. Yeah, shout it out because we don't have microphones for all of you. Okay. Someone just said they wanted a summary of what happened in the earlier cross-project session and maybe some extra stuff if we have time. Anyone else? The TLDR, as it were. Okay. So you guys are here to hear these four folks talk. So in general, I like to do as little as possible. So after this introduction, I'd like you to engage with the panel and the panel to engage with you and I'll just shut up. Works? Okay. So with that as a starting point, what I am going to do is kick off a couple of questions and then let you engage with the panel. The first one is for Colette. Would you tell us what the stewardship stuff is all about? Sure. So I started having conversations about the sticky people problems of OpenStack with a bunch of people in the leadership positions, various ones, two or three years ago. And when I started doing research around external models of leadership that we might be able to sort of look at and learn from within the community, one of the first things that stuck out to me was servant leadership. And so a quick recap of servant leadership for anyone who doesn't know what servant leadership is. I'm going to do like a YMCA thing here. So there's a triangle with the pointy thing at the top. It's a traditional corporate model of leadership structures that starts with the CEO at the very top. And then below the CEO is like an executive layer. And they sort of serve at the pleasure of the CEO. And then below them are kind of managers of frontline workers. They serve those executive groups that are in theory detailing strategy and all of these things for them. And then the frontline workers and then the customers are at the bottom of the pyramid, I guess is how you look at it. In servant leadership, the servant leadership model flips that triangle on its head. And it says that the sort of top layer, the people who are in charge, as it were, are the customers and the frontline folks. And the managers are in place to serve the frontline folks who are talking to customers and serving them every day. And below the managers are executives who are there to serve managers, frontline customers. And then finally, the CEO serves everyone. And they're at the bottom. So when I saw that, it struck me that that corresponded really interestingly to some of the leadership models that I had seen at OpenStack, largely because we come from a ton of different companies. And why on earth would somebody from a different company listen to a PTL from another company? Well, it turns out that's because they're sort of serving their project in this role. So that's a quick explanation of servant leadership. The stewardship working group came out of a kind of leadership training that revolved around that model of leadership. And we thought, well, if we want to start tackling some of these people problems in OpenStack, we should probably start learning the language and understanding what models we have internally and sort of propose governance repository changes that reflect our principles and things like that. So some of the work we've done recently kind of proves what we're about. Musical chairs with a microphone, which you talked about leadership models in OpenStack. So Terry, would you tell us something about how this relates to the TC? Because three of you relate to the TC. The training was most related to the TC. How does this relate to the leadership model of the TC? And what's the connection there? So in OpenStack, we end up growing organically a governance model that has that is pretty close to what Collette just described, which is we can't really rely on traditional carrot and stick strategy to actually get things done. And that's what was powerful in those things we learned when we went to that training. Because I mean, I'm usually very skeptical of leadership training because it doesn't apply at all in open source projects and having kind of a framework where they thought out what it means to invert that pyramid was really interesting because we are basically fumbling in the dark. We're trying to do get things done and trying to push people to walk in the right directions but without any kind of traction. And I think operating under a more defined framework helps us really look into the things with new eyes. We realize that we are missing some vocabulary. We realized we were missing some tools. And that drove some of the TC members that attended that training to reconsider the way we've been trying traditionally to get things done in OpenStack. I'll ask the question without the microphone. I can repeat the question when he asks it. What are some of these problems that you've seen? How do you think? So, Monty, you've been around OpenStack for a while. You're going to say, you have? Great. So, I got my cue. Calle talked about some of the problems which the people problems. Terry is talking about the leadership structure. What are some of these problems and how do you think this whole model may be appropriate and how does it fit in? Where do the pieces come together, especially with the TC? Yeah, so, you know, and Terry mentioned this a little bit in his last response, but we have a wide constituent agency that all come from a bunch of diverse backgrounds. And most specifically, we are a collection of people who work for a bunch of different companies that may be in competition with each other, may be partners with each other, may be partners with each other and in competition with each other. There's a great combination of those things. And we also have a different set of, even outside of sort of company relationships, either inside of companies or just across the different use cases that they're doing. We have people trying to run public clouds. We have people trying to run enterprise, you know, private clouds. We've got people doing NFV. We've got people who think that the only thing that you should ever do on clouds are cloud native apps. We have people who think that clouds are really good at doing traditional things on bare metal. Like we have a bunch of different viewpoints of the world. And in our world, because we've sort of decided on this inclusive and collaborative way to do things, we kind of need to synthesize a lot of those different things into a whole. We're not just saying, yes, we in fact do believe that cloud native apps are the only way to do things. Clearly, if you look at OpenStack, we do not believe that. We have not written software that believes that. It can do that, but it can also do other things. We have humans, because we are a collection of humans. We have humans who have different goals and priorities, because we have a lot of them. We have, you know, the cycle 2,500 humans that are involved that have different primary objectives. Some people are working on this just because they were told to by their boss and have no primary objective other than doing a good job. Some people are in this to liberate humanity from the shackles of tyrannical single company products. That would be me. We have people who explicitly want to take OpenStack and make billions of dollars with it selling their product. And that's just a mechanism to them. We have people who are just concerned with what's an interesting technical solution to a problem. You know, the sort of JFDI folks. And all of the, and many more. Like I could probably sit here if you give me enough beer and come up with, you know, like 100 more types of those people. And we, all of those voices wind up being useful, but in a lot of cases they're in conflict with each other. They have different motivations for doing things. Different motivations often times result in different outcomes. And, or no outcome, as Gleit says. So these are all just the inputs into this crazy pie that we've got going on. When you combine that with, as Thierry says, we don't have some of the traditional tools. Like we don't, if you were just working at a company, oftentimes you vet the people you hire. That's a normal practice. We don't do that. We don't get to do that. You can fire people. We haven't figured out how to do that. These are sort of normal. So we have to take the humanity that we've got. And something has to come out of that. And at the end of the day we need to produce software that people can make a billion dollars with that also liberates humans and is operationally good. And also, like all of these things. So it can't just be about one answer. It's never about one answer in almost every single circumstance. We have to solve five conflicting things at once. So let's maybe look at an example where we actually could do this. Because it seems very good on paper. It always does, doesn't it? Triangle, upside down, right way up, whatever. It looks very great. But how do you actually make this work? Okay. Where am I going to? How do we, how do we, how do we just solve that problem? Which by the way is a people, like we can build, write all the code that we want. But if people are avoiding each other and running into their own corners and not working together towards a thing, it's going to get messy when it does get messy. And part of the group creation is the realization that we have a lot more people problem than we have technical problems. And we have a lot of people trying to solve people problems with technical solutions. So I would, and I want to reiterate that I don't think, I don't think that that's because we're like incapable of solving the people problems. I feel very strongly that, that a lot of times people get, for example, elected to PTL and are like told, cool, have fun with that. And given no resources to help them figure out what that job means. And how to do it well and how to not kill themselves doing it. Right, so two practical things that came out of that, that training and the discussions that we had over the summer were the new goals process for cross-project collaboration and the set of principles that the TC has started writing down. And both of those really came out of the need to better communicate. And I think communication is really the fundamental solution to the people problems. So the goals process is organized to communicate the desires of the end users and operators and the community as a whole for things that we want all OpenStack projects to do. And there's a process that it goes through for selecting things and then we'll pick one or two items to focus on each cycle, work on those things, talk about, you know, how we did, how the work went, whether it's complete or not, whether we need to keep going and do more work. And then we'll be able to celebrate at the end of each cycle that we did a big thing in that cycle. So the first one this time around to bootstrap the process is focused on cleaning up some technical debt, removing some old incubated Oslo code and using the newer libraries. And that was selected just because it seemed like it would be an easy one to agree to and an easy one to implement. It would give us some practice with the whole process. And then the other thing that we did this summer was to take the list of principles that we've had sort of internalized the folks that have been doing leadership roles within OpenStack for a while, kind of understand each other and work based on the same set of assumptions. And my mantra has always been to write it down. One of the things that, you know, really came out of the communication was the need to write stuff like this down. And so Monty and Thierry started working on writing that stuff down and putting together a list. We all had input into it. There was a lot of refinement and everything. And now that's landed in as part of the governance site and part of the documentation that the technical committee has produced. And that's an evolving list of principles, but it's things like we are one project and we want things to work in a similar way. The stuff about like elections and how one person gets one vote. It doesn't matter how big your contributions are. You don't get more votes and things like that. So if I heard that correctly, you mentioned, Colette started mentioning communication. You picked up on communication. So it seems like a big part of this is communication. So maybe all of you will start with Thierry and then go around. Where do you think this communication thing is today? Where would you like it to go? And how does all of these changes which you have, how are they going to relate to the project? It's one thing for the TC to lead. It's another thing for them to be able to get the projects to follow. So what changes are you making in the area of communication which might facilitate this? I'm sorry, we did lots of preparation for this thing and we said, what are we going to ask? But this one wasn't one of those questions. And I'm the lucky one that has to answer it first. So first of all, it's a good question. I'm right. And communication is hard, because it's not as if we weren't doing it before. We publish a lot of things, whether it be blog posts or explanations of what we're trying to do, meaning these threads. And we put a lot of resources out there, but people don't necessarily read or read past the subject line or in however amount of communication you put out there is not enough. You kind of need to put a bit of structure around those communications. So for example, the goals stuff, it's not as if it's not issues we already recognized as being critical to fix in our community. We all know that Python 3, I mean, Python 2 is going away and we need to migrate to Python 3. The problem is, unless you expose it as something that we should have a common effort to make progress on, nobody is actually like on a deadline to fix it. So it's always priority two and in open stack things that are priority two tend not to get done at all, because there are so many things that are priority one. And so you had progress. Some projects did really, really well, like Victor Stiner has been pushing patches crazy in so many projects to make progress on that. But we're at a point where unless you kind of herald that goal as a common thing that as a community, as the open stack community want to achieve together, we will not make further progress to all that goal. And so that's what I mean by putting some structure on it. Totally, but then like what I would sort of point out about not to not summarize today's session, but we'll sort of maybe get to that. But to talk about the goal session and how it went yesterday, right, like what people were bringing up. You know, the communication in the room largely centered around a lot of people saying, well, you can't make me plus two stuff in my project. How are you going to make me plus two a thing? So I was wondering how you got like there is this moment of I saw a real lack of trust in that communication, right, and a real lack of like, like everyone's like really worried people are going to make them do stuff. And then there's also people being like, well, how are you going to make someone else do stuff for me? Because man, I'm so frustrated. And and sometimes those are the same people and they don't always realize it. So what do you guys think about sort of that that space? What is your two sizes? Just just a short comment. I think there's a question of timing. There is a lot of negativity around the developer community right now due to various external factors. And there is also a more traditional resistance to any kind of a top down mandate. So there are like two two things. It's also bad timing. It's also we probably did not get the communication completely right. And and so we're like imperfect beings, obviously. There's a there's a thing that came out in the in the earlier session that that resonated with me partially, I think, because I said it, so I'm just going to that that must make it be an accurate thing. But but if we if we think about that inverted pyramid and what we're what we're theoretically doing here, I think part of the problem, like here, you just said there's traditional pushback against sort of the top down top down edicts, except that these aren't actually supposed to be that. Because we are the especially the way that our sort of governance works. We're we're a we should be a representative like a funnel point of the of the things that that already exist in the in the community. And rather than saying, hey, everybody in a dark room, we decided that Python three is important. What actually we haven't figured out how to frame this well for people. And I think this is one of the one of the failures. But I think that that hopefully if we identify it, we can we can move forward is is that that actually in what we should be saying is that we're we sit we happen to sit in a position where where we've got visibility into across across the open stack community and ecosystem. And we would like to reflect back to everybody that that this is an important thing, not not that we would like to make it an important thing. But we would we would like to surface for people that there there are there are some important things to do that need to be named and pointed out. And and as rep as your representatives, like as as the people that you've you've elected to kind of watch over things, we've we've noticed something. And when we'd like to we'd like to we'd like to surface this in a way that is potentially actionable by all of you. So rather than saying, hey, you all need to do this. And then people like, well, how are you going to make me do that? So actually, we're sort of pointing out a thing that we should, you know, but let's hear quickly from Doug and Colette, because I have a question for the audience, which I think is going to relate to this. So let's talk about the communication thing very quickly. And then I'll push the question to the audience. I think my impression of that session yesterday was a little more positive. There were a few very vocal people, but it was a big room. And there were a lot of quiet people who seemed just sort of to be nodding. And I don't mean to say like, it wasn't positive. I actually think it was a deeply awesome session. But I also think the fact that we proposed that Python three goal and that failed to be approved is the process working correctly, because it triggered the communication about how we thought we were in a certain state and we're not in that state. And there's some other things that have to happen before we can actually take that to the next step. And so I count that as a success. I mean, it's frustrating. I wish we had actually been in the state. I thought we were in. But there's more work to be done. And that works going to have to be done. And we're working on that. And to you know, I started off the cross-project session this afternoon this morning. Morning. I don't know. It's pain. So I started it off by asking you know, how many of you in this room have ever had an interaction and code review IRC in person design summit session where you've encountered somebody who is really upset and making you feel uncomfortable and kind of maybe being a jerk. And instead of sitting down with them and trying to move through it and go through it with them, again on the same page with them you just sort of quietly walked away and avoided them. Show of hands. Right. So one of the things that I think is really important is to start talking with one another about and create a space where we can talk about how we can move past this stuff together instead of be avoidant. Because you know, there's a lot of avoidance in this community culturally. And I don't think it helps us. It points to a lack of trust. And we need to rebuild that trust. And part of the like rationale for splitting the design summit events is also to recreate a venue for less people to be present so that you can actually bond with your fellow developers across multiple groups. Because that's something we had in the beginning and we lost along the way. And I think it's very difficult to build trust relationship in the middle of 6,000 venue where like it's first time I see a few people in a room that I haven't seen yet. It's like the third day we're here. And so it's really, really difficult to get that kind of a bonding experience and trust and we lost that trust. And the other sign we saw in that go room is like now you won't make me plus to your patch is well you should be agreeing when you should trust us or me to like if I think it's important and you should at least try to understand why I think it's important or like natural distrust when in a natural trust. Exactly. And it's one of the you know one of the pluses to our extremely distributed model is that we get to have people from all over the world which means we have you know all sorts of interesting perspectives. And it means I get to sit outside by my pool and hack which is great. But it also makes some forms of communication like things can come out of you know seeing Brian in the front row and a year ago we were all arguing about glance image uploads right. And in the spec and in the online discussions about it it felt very tense. And then we got in the room in Tokyo and are able to all look each other in the face and realize that everybody is actually trying to solve the same goal. And it winds up being very easy to sort of come to a place to go. And that's a specific example of a thing. But like having that space to be able to make some bonding things then makes further subsequent conversations on the topic easier. So I agree with Thierry like the theory of what we're trying to do with the PTG is amongst the toolbox that hopefully we can use to start to rebuild the connections because yeah I've barely seen the infra team. There are people on the infra team that I have not seen yet by Wednesday. Much less random people from other teams right. So the opportunity for me to arbitrarily make connections with people that I didn't already have connections with is diminished. I'm optimistic that with some more ability for interaction with our fellow people we can build some better trust relationships which can then feed into a culture of trust rather than the natural distrust. It's more about PTG but let's stick this to it. How will this group help that? So I actually want to throw that out to the audience. How can we help you? Because like one of the things that we didn't quite get to in the cross-project session because I think a lot of it was a little bit about like we're not some you know this is a group for everyone. It's specifically not just for the TC. We will make recommendations to the TC and talk with them about things but it's not it's A question is how is this corrupt different from the TC? The question is how yeah we're devoted to leadership in all its forms and open stack and the TC is a leadership group right? I mean I view the TC as like in my mind one of the first customers we have to deal with in terms of helping them get through some of this but there's leadership exists in all places in open stack and it's not even just elected leadership as you all know showing up is like 75 percent of the battle. If you can manage to write an email to the mailing list and get some people to agree with you that's that's a thing. So there every single person who participates in this community is is a leader. That's how it's different. There's a well there's a thing that that you said earlier in the in the earlier session about that that I think you've alluded to but to say it slightly differently the the the the stewardship working group exists to be a resource for other people not to not necessarily to be a another set of people over tossing out edicts and like that but actually to be a set of people who are interested in reading and learning and thinking and and and doing that and and responding. So if there's a if there's a person with a leadership challenge and they want to come and be like hey can you help me figure out how to how to do this. That's a thing. It's also it's a it's extremely important to point out that it's a it is a group comprised of the people who are interested in in working on this. So it is not a subset of of of the T.C. There are T.C. members who are participating in it because that's a thing that they've they've decided to spend some some energy on. There's also people who are not on the on the T.C. or in any particular elected role who are in it. It's a it's a it's a willing coalition. So a coalition of the willing right like it's people who want to come and and and examine some of these things and and surface potential tools or approaches to people as as they as they find the need for them. So as we come up with things that we think are broadly applicable will come to the T.C. and say hey we think this is maybe some useful language that that could be used and the T.C. may go neat or the T.C. may go nope that is not interesting to us and those are both those are both fine. It's almost like a research or or here's a framework for understanding a problem that came up in your meeting last week right that you might not know about or but it could help you think about it differently. I don't know I mean like something that simple right and some of the things that we've already started doing we've sort of done ourselves because we're in both groups. So the goals thing and the principles things but that that's coincident because half the people at the leadership training were not T.C. members. So yeah. So what are some other things which people here in the audience. I had to anyone else have any ideas. I had to come here so the microphones didn't blow up on me but are there other things which you would like this group or you would like help with from the perspective of leadership in OpenStack in general realizing that this is not specific to the T.C. Yeah. I have one question look for my management how how how can we communicate with like my personal manager that to make sure this issue that is understood at their level right because they're going to I think it's not just me but other management will look in at this and see what's going on down there from the outside and how do we communicate that correctly to people that have one of the suggestions or the asks from the cross project session was that we put the servant leadership triangle up on like the stack.org website which I don't think is wrong right like I think there is generally a lack of understanding of how open source works when it's working in a governance model like this and a leadership model like that. So I mean do you think that would be helpful. I think so I'm just going to have a published resource online that you could give some of the summary of I think so I think so because others have to be done carefully so it doesn't like because people may already be like what's going on with an OpenStack and why are they trying to resolve these things. And why are we trying to solve problems? Well, why not just let them pester? Yeah, or others or other type of requests like why aren't you pushing more leadership like more hard decisions on top of their those damn developers that don't want it or the opposite. Why are you pushing so many decisions? I mean we've been blamed for both. I think if we are in the situation where we have to make a choice between like too much leadership or not enough leadership it's that we are asking the wrong question. And I think we're in a mode where we are facilitators to make the like the common basically what Monty said earlier like we're in a good place to identify actually things that the majority or the consensual group of people think it's the direction should be doing. And then once we make that truth emerge it kind of it's so much easier to just push in that direction. But if you're there's a thing that a similar topic came up in the board TC meeting Monday I guess that was two days ago. Weird that was that was that it was sort of a request that came out of that of of asking how we can do a better job at the at the at the foundation level the the board of the constituent companies to to communicate to the companies better. What does it so we've got a lot of documentation on how do you become how does an individual become a OpenStack contributor like how how does what's the mechanics of that. But what we don't have a lot of documentation on is things that are aimed at the management structure in the company. What does it mean to what does it mean to employ people who are working on OpenStack. How do you if you're if you're crazy C-suite person has decided that all of a sudden your company is all in an OpenStack and you're like I don't even know what that is. Like what is what does your life mean. How does how do you manage your your employees who are involved in this and and how can you how can you like so resources for for them. So so honestly I think that that from like from your question and that like it's I'm not sure that anybody has an actual full answer for what that exactly looks like but that might be something that the that the stewardship group could work on some ideas to bring back to the T.C. to bring to the board of hey so we we spent some time thinking about this and here's some ways in which we can help you because as the T.C. we should be serving you right we should be making your life better. How can we help you by by by helping facilitate communication up the chain in your in your respective orgs right. I think it's not quite understanding like yeah sir. So I think thanks I think it'd be helped me and other people that are managers that aren't quite understanding what's happening down in the OpenStack land for this kind of stuff and helping them figure out where it's going and what the thoughts are. I just wanted to second that because one thing I've heard from my managers is that right there's there's this model of a benevolent dictator and so there's this thought if we had a benevolent dictator here we could really get stuff done. Yeah which I don't think and what I really like to shoot down is I so so there's so be helped. Yeah there's this perception that OpenStack's weakness is that it doesn't have a benevolent dictator right and I like to flip that on its head which is that its strength is actually that it does not. Yeah but we need to make explicit why that is. Yeah because it. Exactly. Yeah exactly. Yeah and but yeah I think communicating that and and also because because yeah like I mean for the love of all the toly that the in theory people had the impression that the that the TC collectively came to the decision that that that we should support Python 3 which is not particularly all that I mean and like the world exploded and and people are like why are you telling me what to do man. So so for anybody that any of the constituent companies that things would be more effective. I think what all of them actually think is if there's a benevolent dictator we know who to go squeeze to get our fancy feature that was really important to us in and what they forget about is that also means a person who's going to be much more empowered to say no to their crazy feature that all of us think is about idea in the first place. And also that that will end of killing the diversity of con contributors and contributions. We've got two people here. Let me just I just want to say with the I'm glad you're doing the session because I read your first patch for the goals and was just horrified because but but I thought well you know it's it's the role of the TC to show leadership so understood that but it's like this is going to be a really hard sell. But can I ask you what were you feeling when you were horrified like what are the things well because it was like we're going to tell us what to do and I'm thinking yeah good luck with that. And we're going to get this done by the you know by the certain deadline. It was like yeah good luck with that too. There was no. So I put the comments and we needed some to build up some stuff. And then on the patch you explain no no the ideas that these are organic goals that are going to rise up and then we'll help. There's I guess they're all so far the backlog is there's maybe 10 things maybe somewhere around a dozen things on the backlog. There are all things that we've been talking about for years. I think the difference literally for years. Right. And that came out on the patch but I think the you all had the context of being at the leadership seminar. Right. And yeah. And trust. And that's her serious point earlier about failing to communicate fully about where that was coming and after you know after I went back and read it it's like oh yeah I get. And what's. Here are a few tweaks and now this is fine but then you can see some people still don't know what it's also. Well what's funny is that there was a change process that was introduced to us in that training as well that was like sort of like here's how you manage change in a servant leadership model and we didn't follow that. So I you know I mean I think there's a lot of like we're still figuring out how to do this right and figuring out because because I think Terry said this also earlier in the session. There's there's a bunch of stuff there and there's a bunch of stuff that that was applicable. There's also stuff that wasn't applicable in the in the stuff and so sort of sorting through because it's a it's a set of words and tools and whatever and you can look at and be like oh God it's a mismatch of like so trying a couple of things and it turns out a couple of things really resonate. A couple of things were like maybe like I could see but maybe it's not that important and it's like I think as we stumble through this we discover OK well this bit did apply this bit didn't apply and like that's part of and we'll figure out how to make it the communities. So to follow up on Monti's comment about the possibility of providing infrastructure or instructions for a company contributing to OpenStack as opposed to an individual. Are there any areas of the culture and policy and politics in general superstructure of OpenStack that are specifically excluded from the stewardship working group remit for research and recommendation. I don't I don't think so. I think that I think that the stewardship working groups goal in life is to be helpful to people. So in the areas where people need help then those are the areas because this isn't this isn't a binding kind of you know like it's not a thing over off the inside restructuring things it's somebody says hey not really sure what to do about this particular thing. So some people will go and talk about it and think about it and that there may be productive results out of that. There may not be but I think that in any of these cases as long as it's related to our you know our technical community even even broadly like because talking to talking to managers at companies is clearly not actually I don't think the stewardship working group should talk to managers at companies like that's outside of but but brainstorming and researching some ways in which that might be done that can be bubbled up to the people who that is their job I think would be and then those people can take that take that information or not as they as they as they see fit but but at least because a lot of these things are things we're like it would be really great if somebody thought of a way to do that and then like crickets you know like like nobody is like nobody so it's more of a forum to to to bolster and support people that want to think about some of those harder problems. But the issue there was also that we need not have a venue for those kinds of discussions before and to Brian's point earlier I think if we had more shared context and he had a better idea of what what are the things we're trying to to achieve he would have had trusted us more by default rather than and so I'm happy to I hope that we will we set up tools that we will be able to use to share more context about all those initiatives so that they they are not like taken first of all as as potential attempts to do something wrong but whether to do something right and I hope we'll rebuild that trust that's been broken and I and I mean if I could pick a tagline for our t-shirt it would be like you know we're here to have the conversations you're afraid of having right no I'm serious like there is like the the thing is is like if we can't create a supportive space where everyone feels like they can come and talk about the really hard stuff then then I would be upset if if if we still existed in a year so well actually you guys kind of and I'm feeding back you guys hit part of the the issue just recently they're like three questions that feed into this whole issue of you guys are exercising the process but you managed to do it improperly with the Python 3 and there are other times where I've seen not quite enough how follow-through and so maybe perhaps as an organization you come up with a checklist of what we need to do to make sure we've we're actually proactively not only walking the walk but advancing it so have you scheduled a post will you schedule a postmortem of how you can do it better in the future there are things along the lines of when there are TC decisions especially hard ones that have lots of inks built around them if there's a process that says we do this we do this and this is our follow-through lead by example so whether a decision is a yes or no what are the next steps to maybe turn it into something positive or continue the positive and so I don't I was personally frustrated with the outcome of the decision but only by timing so I don't feel like the Python goal discussion was actually a failure the the initial discussion around the goal process itself was also a bit tense but resulted in a successful outcome and so we do have conversations you know retroactively about what went on and how we can do better next time all the time that's how all of the people involved in the group started and we did an event to which a working group meeting following the email reaction we actually did so did and I want to bring there's a there's a thing that there's a sort of set of potential you know tools that we we didn't poke at to this time that the club mentioned in terms of of of prepping for rolling out change and one of the things about that involves sort of some some clear clear descriptions of of the thing but also what the outcomes like how how the outcomes can be can can be measured later on so that's why I think that's so so yes like that has that happened and also I think there's potentially some some some more structured things that we can we can try in the future to to enhance and make it even more transparently clear that that those things are are going on which is I think really important I also want to point out before I let Terry cut in that the thing that Colette was talking about about there being a safe space to dig into the hard problems you you glanced over a known hard problem that we all in this room know is the one that you glanced over and it it was obliquely referenced in the earlier session and we are in fact not in a space where I'm going to reference that by name on on the thing because it will derail us at the moment we need to be able to to to dig into we need to be able to have more productive follow-up conversations about that without without everybody needing to tiptoe around the those sorts of things so I think that's a really great example of exactly why doing work on being able to have a safe place to talk about the and not necessarily the safe room to talk about that problem but we even have a hard time right now talking about talking about that problem right and I know that's super meta and like I know we love to talk about talking about talking about problems and then make a structure in which we talk about talking about the structure that we're going to talk about the problem but but in this particular case I think it really shows systemically that we we we we do have a loss of of how to really functionally dig into that and I think that's a hopefully one of the things that we will work on and come up with some some suggestions I like I like to call that cultural avoidance in action everyone we're getting pretty close to time and so I'm going to say the word back but so is that okay yeah okay we have five minutes left so yeah I just wanted to answer like a compliment to the question that we just asked I don't think you should look into the goals and principles stuff as an example of the way things will be going in the future it's more the thing that the things that we had in our backlog that we never got around to do and that that leadership training actually opened our eyes in the necessity to make it to advance really fast it's not as if the goals and the principles were started up and then there were already things that Monty wanted to write forever or that me and and and I wanted to push at the release management team level it's just that we the training basically spurred us into action say well we should actually like take a step backward and try to improve things rather than bitch about things not getting in the wrong in the right direction and and it also highlighted some ways that we could do something that we had been talking about for a long time so I'd have the idea of having released goals you know back a year ago and some of this stuff about communication and communicating expectations and clearly Documenting and having the contract to go back and forth with agreement That's built into the goal process that came directly out of the the training sessions and the material that was there so it made it Not obvious, but it gave a path to create a system where I wasn't seeing a way to do that before So so say One question sort of around the health of the community like for example like at a company or I've been at one And that where they send out these like quarterly like surveys of all the employees to gather how the feedback is going on Like it's sort of I don't know the gauges the company's Culture or whatever emotional state. I don't know those kind of things that could like is it anything thought about for like open Stack for that I would love to have a cultural measurement It's maybe something similar to what the yeah It's going to be based on participation much like voting It's difficult in our community because the the constituency is moving so fast like that like if you just survey developer per developer I would say we have Like a lot of people that submit one two three patches and those change a lot and so in the end It's difficult to have those kind of analysis, but I think it's still variable Yeah, I would just not put too much trust in it. Okay. Yeah, another question was like it's an anonymous dropbox for like people to like Ask questions that were tried. I don't know It's something seems like a form or something that could let people complain on that would be like just anonymous somewhat That's like you just ping me on IRC Okay Just making a known place where people can just be like I have problems with XYZ and the team does have an IRC Room to But I mean I can take a PM anytime But but but part of what I'm trying to do is sort of get some of these conversations out in the open Okay, and develop the skill set so that we can have them together so that we're not so afraid of one another anymore That makes sense. I think you know to your point about goals and potentially being a failure Whatever one of the things I pointed out in the earlier session was There's a there's a distinct lack of trust in the community that I think I want to sort of It involves bringing it forth before we Before we start to heal it, right? And sometimes you want to start those conversations in private But you need to get them into the public sphere at some point To repeat that you I'm not gonna Rocky's proud of us Rocky said nice things. She's specifically proud of Doug. I'm proud of I said I wanted to congratulate the group for getting the the goals and and other aspects out there because Now you have a way forward to actually find a way to Get the better participation Okay, thank you And it is definitely meant to be iterative and and we had Suggestions this week about improvements that we could already make to that process that we'll be working on Probably not next week, but maybe the week after So I've been back here. Apologize for fighting jet lag. I've been really enjoying the panel discussion I was wondering if you could talk about what's on the agenda next for this stewardship working group and What people can do to to help and join with that? It's gonna largely be determined by who shows up at our meetings, which I would love for everyone here to show up at Hey, when when and where are the meetings are on? Are they even Tuesdays? They're every other Tuesday, and I don't know if they're odd or even and there was a whole thing about it at 1500 UTC And open-stack meeting three we also have an IRC channel. That's open-stack hyphen SWG And I'm got the mind food on IRC if you're curious, but but nervous I'll I'll I'll be like cool story. Don't be nervous And so a few of the things that got thrown out the cross-project session were creating Some resources on some of the sort of modules of learning that happened at that training There will be another training the foundation has has agreed to fund one more this next coming calendar year So we will be doing another training But I also want to make it much more available to the community in general probably in more bite-sized pieces So I'm gonna be working on that. I think we've decided that we want to untangle the list under etherpad for the cross-project session was untangle the ball of Crazy that is our communication system and try to make it like more efficient and better and easier for people to use So I think that's been suggested and that was specifically since that's kind of shorthand in the room Language that we used to write that down that that was specifically about how to make sure people see the messages that they need to see Right so the volume on the mailing list is really high people are all in different time zones And so in asynchronous communication is challenging and specifically coming up with some ideas to improve those That part of the communication. Yes, so I'm getting nasty looks from the back So I think so let's say this conversation also whatever you show up with at the meeting and want to do No, so let's just this conversation just started. Please come to the meetings and You know where to find these folks. You know where to find me and we'd love to hear from you. Thank you