 Hello. Welcome to the community operations workshop here. You're going to be stuck in a room with me and Sumantro for 90 minutes. But before we get you into the trap, we'll do some quick introductions. I'm Justin. Many of you were just here in the last session. Thanks for coming back. If you haven't seen me, I work at Red Hat as the Fedora community architect. I joined Red Hat about about a year ago, but I've been in the Fedora community for eight years or so. And one of the very earliest things that I did in the Fedora community, with the first Fedora community architect, Remita Cosmaker, was launch a community operations team, often shortened to ComOps, which was a team of kind of people who did this interesting work of working across multiple teams and kind of were connectors in the community. And that was eight years ago. A lot of things have changed in eight years. But part of what we're wanting to do today is to restart that conversation. So I'm looking forward to some activities planned, some discussion as well, but I'm looking forward to hearing from all of you around this idea and getting your feedback too. So I'm Sumantro. Most of you know me as Sumantro M over IRC. I work for the Fedora QA team, but since last seven years or so, I used to work for or rather assist few of the ComOps members. One of them I would highly name as Sachin Kamath, if you have ever seen him on IRC, you know who he is. So most of these guys used to develop matrices and data points and crunch numbers. And I was more interested into that thing to get community matrix, to have an understanding of how the quality of life of a contributor in Fedora would go about. And ComOps was one of my very starting points. So I am here to start this conversation and gather feedbacks. So I think to kick things off, we're going to do another sticky note activity, if you were just in here in the last session. And yes, I have got the pad here. I know you all already have pens. If you want to go and distribute those out, I'm going to deviate from our playbook a little bit here because I really, there's a question that I'm... Let's do like, we might use them again. So you can give like three or four per person. We can always share more if we need to. But the question that I'm going to pose to you all is when you think of community operations, what things come to mind for you? What does this term, what do you think this kind of work in open source community looks like? So you can write it all on one sticky note. You can write different things on multiple sticky notes. Format is totally up to you. But we'll take, let's see, so it is 11.08 now. We will come back around 11, 13, 14 or so and then we'll have everyone come and put their sticky notes up here in the front and we'll take a look at what, what do people think community operations is and what does it mean? Yes, so we're all we're doing is, what do you think community operations is in an open source project? What does someone who does comm ops do? Or what does this team, what kind of tasks do you think or give us your feedback? When you hear community operations, what do you think of? So we'll take five minutes, we'll come back around 11, 13, 14 or when everyone looks like they're done writing. Sticky notes, you can come to the front and put them up here and in a minute or in a few minutes we'll start to do some groupings. All right, do we have anyone? We've got one more person coming up. Anyone else have some sticky notes left? Written ones, I like that one. All right, so feel bare with me. I am gonna read through some of these just for the benefit of our virtual folks who are here and to help me remember when I look back at this recording in two months. So what we have up here, some of the things people wrote, what is community operations? What do you think of when you hear that? There's definitely some common ones, care and nurturing of the community. So I think generally a community health and wellbeing is something I'm hearing a lot, health and belonging in the community. And on that same one, ensuring member safety. This might fit into this one, creating spaces for community discussion and interaction, kind of community health one, having safe spaces for discussion. Contributor journey, kind of in that, I think that one might be different. Like how do people move through the project? That's what I think of with that one. I don't know who wrote that one, but maybe they feel different. We have organized the community, have inclusion programs, code of conduct and maintaining harmony in the community. Some I think are kind of on their own. So under the contributor journey, we have supports, community members who are getting started in the project, technical and resources, et cetera. Communication, transparency and coordination of community goals. I'd say that's kind of in the contributor journey, newcomer support bucket on the right side. So also in the care and nurturing of community, creating, I think that one would fit here. So we have one for creating and updating governance processes. And under that, we have some that are, this one's a lot of them, infrastructure, contributor user experience, politics and diplomacy, sociology and group dynamics, swag and funding, governance, partnering with bigger contributors. I might leave that one on its own. No, those are all good things, but it covers a lot of the different. Let's put, no, let's put this one, I think that's a new category here. So we have building and maintaining systems and workflows for the community releases and also creating and updating governance processes. Maybe organizing the community fit in this one, maybe. Events, I think, is its own bucket. That's one that's on its own. Same as statistics, I'd also put that on its own bucket. Community advocacy towards Red Hat or maybe Red Hat advocacy towards community. So we'll put that in the events bucket for now. This was another multiple one. Yeah, statistics is its own. Yes, we have some great chaos representation in here. We were just talking in the last session about chaos, which is a community of practice around measuring and understanding community health and open source communities. They do, they create metric definitions as well as create software to help people measure those metrics. Group this one, it is kind of in that bucket, but I would group it. So we have one that's manages chat platforms behind the scenes so people can meet and work with anyone in the community. And then this one that I really liked is the cement between the bricks or the oil that keeps the engine running. I love that one, actually. So it's kind of in the care and nurturing of the community bucket. So the statistics, then identifying the needs that are common across communities and addressing them from that broader perspective. Kind of like, yeah, it's kind of in the middle of the care and nurturing and contributor journey one. And then I'm holding this one, coordinating projects across multiple teams and making connections, event planning and promotion, facilitating meetups and processes for teams and conflict resolution. I wanna put that on the other one with a lot of ideas. Check-ins with groups, follow-ups, establishing standard operating procedures or SOPs, finger posting, manned or unmanned. I don't know what that is. I don't know what you want. Directing people, I love that. So for the stream finger posting is kind of a way of directing people through the community, like, oh, go over here for this thing or over there helping kind of help people. We're putting it in the contributor journey bucket here. And then also she had up here, driving transparency and general give work. Glue work, glue work. No problem, glue work is an important one. I think that fits in cement between the bricks too. So let's see, we've got one, two, three, four, five, six, and then a lot. So roughly six-ish groups that are up here. So I'm gonna turn it back to the audience. As we were reading these out and sorting them into different groups and buckets, did any of these things that you heard from other people surprise you? Or did this all just make sense when we were talking? It was all like, oh, yep, that sounds like commops community operations. Or were there any other, anyone have like a surprise or thing that they didn't expect to hear when we were reading off these stickies? What do one and two? I kind of thought I'd hear more about advocacy and kind of the ambassador program kind of activities and I didn't see that. And I was kind of surprised by that, so. I had a couple of questions I found myself asking because there was a lot of sort of organizing, bringing people together, these sort of things. And I kept on asking myself to what ends, on behalf of whom, and like these sort of questions, because I think oftentimes it's like, well, what are we organizing for and in who's interests? And like. So would you say it's like, who are the team members or who are the stakeholders of this team? How would you describe that? I would be like, who are like this team, who are they representing? Who are they beholden to? What are the incentives that drive like their focus? Coming from other organizing backgrounds, it's very different. You could think of something like human resources in a company versus maybe a union organizer. Oftentimes have logistically very similar tasks, but because of the nature of like where they're suited, situated within their organization, have like very different goals, even though they're doing like practically very similar things. Not that like it maps directly here, but I found myself thinking about that. Yeah, those are good questions. In the back, or yes, okay. So I was pleasantly surprised to hear when you said define what community operations means to you, to me, I went to the very mechanical, technical button-pushing stuff. So I was very surprised to hear how much the soft skills come into this particular function of the Fedora project. It's very nice to hear that, that that's focused very, actually I would say probably even higher than the technical button-pushing, but that was all. Thanks for that. Anyone else, surprises, observations, questions that you had when you were hearing these groupings? Someone, I suspect it might be Greg. Someone said sociological, I would love further expansion on that, please. All I really meant was that I've been reading a lot of books recently. But no, but seriously, there's a lot of study around online communities of all types, right? Not just software, but gaming, support groups, review sites, et cetera, and how they form and what we learn from that, from psychology, sociology, economics, et cetera, and I'm finding it fascinating and putting a lot of it into practice. And so really, for me, getting a chance to think about that is one of the really great things about the job that I do within my communities in Red Hat, right? It's really good fun. And it does help a lot. This is one of the things that I think is great about open source. You can go read a bunch of stuff and then be like, and learn a lot of things and you're like, all right, let's build a team for this, let's do it. So thanks for that. Any other observations, questions, or surprises? Again, in the front here. I guess I was thinking more, to expand on who we are here to be for, like if you think about the funnel of people coming into Fedora, are we here to represent the post-join sig kind of function, like keeping contributors in Fedora? Because I saw some of the comments were more around kind of users or bringing folks in, but it's kind of unclear, I guess, as I look across it, where do you sit in the contributor journey of you coming into the project, you being mentored and then being converted from just a new member into somebody who's doing actual, let's say, packaging, right, or documentation or anything like that, like where do you go in that funnel, so. The answer is yes. So when I said care and nurturing, where in the journey do you see this? Is it once you're in, are you new? For me, care and nurturing is almost everything that's on that board because it doesn't start when someone joins and it doesn't really even end when someone leaves the project. So I'm unclear, I might just need explanation because I'm extremely jealous of Fedora's multiple teams of people doing stuff. Be careful what you wish for. So I don't always necessarily know where, so from the perspective of bringing in community members, I think maybe some of that outreach and talking to people before they're in might be part of Mindshare for Fedora. And I'm not clear on where the, I don't have those, I don't have separate teams doing these different things with Encento, so I'm not sure where the boundary is between these different kind of community oriented teams that you have. That's a great question and I also want to know these things too. So I think, do we have any last ones as well? I kind of got a three prong approach here, which all, I'm kind of improvising a little bit here, but any last observations, groups about what is come ups? Going once, going twice. So, okay. So I think what I'm thinking might be helpful to kind of set the stage for the heart of this workshop I think, is sharing a little bit on where is come ups in the Fedora project today? How did it get there? And what we're thinking about now for rebooting this team. So I'm gonna try and not put that one, but this one. So I would be, it would be a shame for me not to mention this amazing organization chart that was just updated by someone who I wish could have been here but was unable to. Marine Norden just updated this a month ago. So this is very fresh since the last update it had in November, but this is our organization chart, the map of the Fedora community. And if you've never seen it before, you're probably feeling overwhelmed. That's a pretty natural first reaction, but I do, quick question or? Remark. That would be, I would endorse that. Do we have, you don't have a design team. Wait, how about Emma and. Maybe four. I'm not sure whether that was audible for the remote audience. My suggestion was to have that as the default wallpaper in Fedora. It would be a cool wallpaper. Default, a cool wallpaper. I would use that wallpaper. So, borrow the handheld. So if you look at this chart and maybe I should zoom in here, I always like, I don't know if other people feel this way, but I feel this way about the org chart is kind of a left brain, right brain way of thinking about it. So at a high level, how Fedora is structured, you have the Fedora council as the top level leadership in the community. We also have two other leadership bodies that also play a significant role in the community. So on the left brain side, which you could say is the more engineering, probably more engineering side of Fedora, at the top, the governance for that side of the community is the Fedora engineering steering committee or FESCO. So these are the folks who review all the changes that are coming in from all these other places and little bubbles in the community. The FESCO is the group that reviews technical changes and kind of helps provide technical leadership around the direction of the distribution. And we come over to the right side, to the right brain. We have what, for lack of a better term, I would say is like our non-engineering groups, although there is engineering work happening in some of those places, but more generally they're not usually code and software work. So the mind share committee, which if you were in our last session, we talked a lot about that. So I'm not gonna harp on it too much here, but it's kind of a, again, a decision-making body that kind of helps represent all these other bubbles and teams in the right side of the project and also helps manage a lot of our budget and spending priorities for the project. So this has changed recently in the last couple of years. Conops has moved, kind of moved around a bit in this chart, but in our current situation of where community operations exists, it's one of the groups under the mind share committee. So kind of like a SIG or a working group, I guess would be the parallel. And then the ambassadors, the advocate program and the ambassador emeritus groups are kind of a subgroup of community operations, which it's a nice, nice concept, but I'm not sure if it has quite worked out that way because again, if you were in the last session, ambassadors carries a lot of baggage in Fedora community. It comes with, because it's a group that's been around in Fedora for longer than commops, so it was 15, 16, 17 years ago. Ambassadors have been around for a while. And operationally, it's, I mean, and I don't think in practice it's ever been under commops. I mean, maybe according to the org chart, but it hasn't been really. Operationally, I mean, stuff just goes from ambassadors to mind share. So there was some restructuring work that happened in the last couple of years during COVID when we weren't really doing in-person events and travel. So we tried to, there's been challenges in these areas of trying to revive those groups even before COVID started. And I think I'd still say it's a work in progress. There was a lot of great structure that was created in the last couple of years, but I don't think it's been fully realized or implemented. So that's where things are right now. But how did commops get up there in the first place? How did this team come to be, what's the origin story, Marvel Cinematic Universe origin story of community operations? So, well, before I open the docs, I think the context here is that in 2015, that was the year that we had the first, well, different title back then, but the Fedora community architect role was created at Red Hat to try to take some things off of the Fedora project leader back when he was doing a lot of things. So it helped diversify or spread out some of that work to be a little more balanced for the role. And the person who was the first community architect, Remy DeCosmaker, kicked off the community operations team with the, he had this vision of heat, light, and love. Which maybe I can pull that up, because he went to Twitter later and I'm not gonna get twitter.com on this, but twitter.github.io, if I can hit it, that would be great, but I can't, yeah, move permanently. Oh no, it's still here, amazing. I don't know, I would probably assume this is not the operating procedure at Twitter today, but X, yeah, here we are, it's Twitter, so obviously. But his vision that he put here for Twitter, he kind of actually built out in Fedora. And so the vision for this community operations team back in 2015 was to provide these three roles in the community. Was to provide heat, which means work. Upstream, I will say this definition is a little more code focused, but I wouldn't limit your imagination to code on this. So he wrote here, it's like upstream contributions, bug fixes, designs, documentation, the rigorous work that drives the community. Light, which means visibility. So for the projects, contributions, opportunities, challenges, and people that impact the community, and love, that means culture and support, why we care, how we work, actions that grow the community. So Kamaz was created as a team to help serve these goals in Fedora, because if you looked at that org chart, there's a lot of stuff happening in Fedora all the time, every day. Nobody, I'd like to find the person who makes the claim that they know everything in Fedora. I don't even, I don't even think, yeah, Matthew's shaking his head here. So if you find someone, I'd like to meet them. But Kamaz was trying to fill this gap of like, okay, we have all these teams, everyone's doing all this work, but how are we coordinating it? Of like, oh, we have an ambassador going to an event, and then they would create a sticker sheet on their own with a local vendor, and then it's the weird, if you look at some of the older history of Fedora, there's some very funny looking Fedora colored logos, things that, you know, so the design team input maybe came too late, or they weren't even consulted, or there'd be people who were doing their own documentation and could actually been very useful for everyone else. But, you know, everyone's kind of plugging away doing their thing, and you might have a few of these people who are kind of doing the glue work, but there was no structure for these kind of people in the community. Well, there was a community working group that was actually before my time, but I don't know how successful they were with that either. So, ComOps started with this, and some of the origin back in 2015, you know, coming back to what we just did with this exercise, well, what did we think ComOps was in 2015? We have these kind of high level concepts, but like, okay, let's drill down and actually think around what does this work mean? So in 2015, it's N16, really, we developed, I'd say, the five main buckets of things that ComOps focused on at the time. One of those things was culture, really trying to promote the community culture that exists in Fedora, that I think if you spent much time at Flock this week, you hopefully have been feeling some of that feeling as well. But we have all the rest of the year, that's not Flock, and making sure that we're sustaining that culture and people feel connected and we're all on the same page as like the values of our community, that's really important. So things that ComOps did, we do interviews with Fedora community members about things they're working on or things that they're interested in. We launched the community blog in 2015, was ComOps that launched the community blog website that we have now. We did a Fedora appreciation week for the anniversary week of Fedora. We had a week where people could just go and reach out to their, I could be a package maintainer or someone else you work with in the project, users even came in to just say thank you and be like, hey, you're doing great work or some people would be like, I love, come and do very general, oh, Fedora's great or then there'd be people who would be like, oh, Kevin Finsey got my thing, my ticket fixed. Thanks, Kevin, for more individualized kind of feedback. So we built a structure for that for a whole week, people coming in and really appreciating each other and calling out good things that people are doing. And we also did a series Top Badgers of the Year. So we'd look at the leaderboards of who the top five badgerners were in 2016 or 17 and then we'd interview them. How'd you get here? How did, what have you been up to in Fedora? What's your story? Another thing that Comops did in the beginning was elections. So these days, well, Ben Cotton had it down to a system. We did have some bumps on the way in the last election or two, but even before Ben took that on, it was actually always been a community, it was election wranglers is what we used to call these people. And usually, I think Ankur Senha was usually the person who drove a lot of that. Someone else who couldn't be here from Flock, even though he's been in Fedora for so long and he's literally just on the other island adjacent to us, but he says, but anyways, so we would help do some of the coverage. So we'd be doing interviews with folks, helping collect those interviews and publishing them on the community blog, doing the infrastructure plumbing for the elections app and also just trying to do automation for the calendar. So everyone's like aware, like, hey, here's the deadlines, here's the expectations of what's gonna happen. The third bucket was storytelling. So I think it kind of goes close to the culture piece, but being able to go out in the community and talk about, like, hey, here's the things that we're doing as a project, as a community. Here's the things that we're caring about and making sure that people, I would say this isn't as much of a outreach as it was an in-reach, trying to talk to other Fedora people about things happening in Fedora because it's huge. As you saw on the org chart. So things that we did back then was we interviewed, there was the Python 2, Python 3 migration back in the day and the Python SIG was doing a mass migration of trying to update Python 2 packages to Python 3. So we interviewed some of the maintainers for their hack fest that they were doing and how people could help. We did calls for nominations for the server working group when they were trying to find new chairs and new governance for the server working group. At Fedora events where people would be going, like I think this was FOSDOM specifically, we would do an overview of like, hey, you're gonna go to FOSDOM, here's the Fedora report out of all the things happening. Here's the Fedora content and sessions. We did help-wanted columns. So say like, hey, you're trying to get help on something, a community operations person would jump into your chat or hang out in a meeting, ask where you needed help and then we'd do a column on the community blog like, hey, here's some things people are looking for help with right now in the community. I missed this one, but we used to do year and review with different teams to help different teams create a structure like at the end of the year. What was marketing up to this year? What were ambassadors in EMEA doing that year? What was community operations doing that year? The other one is metrics, which I don't wanna make this exclusively a metric session, but we have some really cool things in Fedora that most communities don't have. There's some age in some of those tools, but it's still really cool. We have this, if you don't know, we have the Fedora messaging bus, which is this bus of activity. Every time someone does a contribution of some kind in the community, get leaning more on the engineering side of things. So I'd say a git commit or a package gets built or tested or a comment is made on a pagore or GitHub issue that gets reflected into the messaging bus and we can query all those things and take a look at what's happening in Fedora. So the commops team back in the day, we did a couple of things. I'm gonna guess that first one, analyzing Fedora contributor activity. Promise we're not doing spying or those things, but what we did was looking at, I think that was FOSDEM 2016. So we had Bagishri Padalkar who was doing this work at the time in commops who looked at people who took the badge at FOSDEM 2016 and she looked, have these people who scan the badge, have they ever shown up before or are they newcomers who just showed up and then what happened after FOSDEM? Did they go on to do other things in the community or do they drop off? She also looked at Flock 2016, she presented on the life cycle of a Fedora contributor which seven years ago we found out that roughly 50 or 60% of people who came into the messaging bus would drop off after three months. Some people would be shorter, some people would continue on for a longer term, but at the time that opened up other questions and things that were interesting. I'm like, okay, well, why are people dropping off after three months? Is it that they hit a barrier or were they just trying to do one thing and they got it and they're done? It opened up those deeper questions that we wouldn't have been able to ask without looking at it. There's also release party metrics. Back when we were doing more in-person release parties and the virtual end of things kind of leaning on the badges end of stuff as well. I also have to mention Alberto BT0 from the Fedora Mexico community who is also a big part of all the metrics work that we were doing at the time and has created some really cool scripts around geographic activity as well. So that was a big pillar of commops and there were some key people who really drove and owned that and used our tools to tell interesting stories feeding back to the storytelling piece. And then lastly, in 2015, what was commops? We wrote out supporting sub-projects or other teams, other SIGs. So that might have been like wiki gardening. We were working with the Fedora Join SIG. We were helping Fedora modularity get started back in the day. We helped the Fedora.net SIG launch when they were trying to get established, when.net just went open source and we wanted to get that onto Linux. And a handful of other things like mentored projects. We did some of the plumbing for GSOC 2016-17. And so that was what we started off with. In practice, people come and go and there were changes in the community. And also I think we had the first founder, Remy DeCosmaker, left the role. Brian Axelbeard came into the role and he had a different approach for it. And some of the way that team functioned wasn't as documented. I think what happened was scope creep kind of. People were like, oh, well, commops can do this. Commops can do that. And suddenly commops was doing all these things and then the people slowly dwindled and the team kind of, I won't say went away completely, but it's definitely not, it kind of fizzled out after a while. And then COVID didn't help any of that either. So this is kind of the lay of the land eight years ago. And so why we're doing this workshop today and what we're gonna switch to here to have more of a discussion in a little bit is trying to reboot or revive this team in a sustainable way. Because even though, even if we don't do all of these things again, I still think there's a huge value in having a structured place where people can jump in and if you wanna do storytelling, you wanna talk to other people and help do that in reach, making sure that other contributors are on the same page and aligned. I still think there's a place for this kind of work. So the last thing I'll mention here before we transition over is where we've been at in the last couple of months. If you've seen on Fedora discussion, we've had a conversation already for, it was like June or like May or June that we kicked this off, trying to figure out like, what will this look like again? And if we try to revive this and reboot this team, what is it going to look like? We have a few folks who've already, some folks who are also in the room who have listed their interests. So the idea that I came out with the original proposal, well what should ComOps be now? I've put out there's three things, just three things that ComOps should, that I think ComOps should do today, which is again the data science piece coming back to that metrics part. I don't know what to call this one, but I've leaning into product operations. That's definitely not what I, there's better things to describe it, but kind of that glue work that came up earlier, being able to jump between multiple teams and to have a place for people who do that cross team work to connect and kind of be organized with how we do that. And then the storytelling piece, all the old blog posts that we used to do, the interviews with other contributors and doing that kind of in reach work. But what should ComOps not be? This time I was like, all right, we probably need to lay out some things that we're not going to do in this iteration. One of those is the community blog. Back in 2015, when we launched it, it was the ComOps people, I guess that did kind of fit under our storytelling thing at the time. The team managed it, and it was largely, I mean, it was a lot of me, I guess, but we had, we did have a team of editors there. And I think now with how the blog has evolved and changed, it's not a test, not an experiment anymore. The Com blog is here to stay, but I don't think ComOps should be the team to own the editing workflow for that anymore. I think we've got other processes that work, and I don't want to undo that. The system that is working. The other one is app development, which a comment from Matthew that right now, Ben Cotton is doing the Com blog. The challenge is that we'd still probably need to have a team. It is a one person. Right, do you want? Yeah, that's okay. So Com blog still probably needs some love and attention, but. Yeah, so one thing we could actually do is call for editors. We actually did not ever do that, right? But I'm sure, like I am one of the editors of Com blog, so I keep publishing my own stuff, but yeah. Are you cheating right now? Yeah, yeah. I do it too. Yeah, so, but yeah, if we actually call for editors, I think there would be people who will show up and then we can do something, yeah. And then the last thing, coming back to why the ambassadors were kind of boiled up under ComOps, I actually don't think, the community operation should own ambassadors. Whether it's its own thing or it's somewhere else, it's still a good discussion. So a little bit of history. In the last, about one year during COVID, we kind of launched this revamp operation to get ambassadors somewhere from a dormant phase. So we actually phased out most of the information that was unnecessary, not there, would not ever be updated and was mostly bit rotting. We kind of took care of that, moved everything to this docs, shiny page on the website, but we decided to move ambassadors under ComOps and that was not a very great way to start things. So I guess, yeah, we would not want to have that there at all. If you were in the last session, you know that that's still something we need to fix, but probably not in the scope of at least this session and what we're trying to drive here. So that was a lot of talking and history lesson, hopefully I didn't put, well, okay, I don't need to sleep, just making sure. But just want to see before we kind of transition to a more interactive part and thinking around what people are interested or would be like to see from a new revived ComOps, are there any questions or comments people want to add in? I see two here, we'll start with Robert. So kind of going back to earlier, I think the, you know, and especially going to some of the sticky notes, I think there's maybe again some confusion of is community operations more inward facing into Fedora or is it outward facing and outside of Fedora, right? Cause I think there's a lot of, and there's a lot of overlap, right? Because it's that funnel of getting new contributors in, in some cases is events, right? Awareness and things like that. But I think also at the same point, the bridge of bringing everyone together is kind of also what CommunityOps does too, so. Yes, and ComOps is not Fedora marketing and would not take over that work either. I think that's a very clear distinction is the marketing team and Joseph are doing awesome things and we don't want to, feel like we're taking that away from them. You know, I see it as different work. In the back. Did we not just find the distinguishing part between the ambassadors and ComOps? ComOps looking inside, ambassadors looking outside. Say like to elaborate, ambassadors are there to promote Fedora, to get the word out on Fedora, to get people from who are not part of the community yet to join Fedora, whereas ComOps would look more to the inside of the community and help them to collaborate. I actually would be curious for Sumontro to take that one and get his take on that. All right, so I guess my quick comment there is I feel like it's tricky with ambassadors because on one hand, yes, like going out to events, doing kind of the outreach arm of talking to the general public and open source world about Fedora, but I also have seen ambassadors do this role of doing kind of that inward stuff. I don't know if we have any of the Fedora, Mexico, I don't see any of those folks here now, but they do a lot of like, I mean, in one hand, maybe it is kind of that outreach, but they do a lot of like community building in their region. I always get the idea that my voice is hard enough to be heard, but it's more the definition part that I'm after. I mean, it doesn't prevent you to be an ambassador and be part of the ComOps team at the same time, but the definition part would be ambassadors are focused on spreading the word, whereas ComOps would be enabling ambassadors or enabling parts of the communities to get stuff done. And it's more the definition part I was looking at, not that you cannot be part of both or that there is no interaction, but the definition part for me would be ambassadors are looking outside, they are spreading the word and the ComOps team would be looking at the inside, where do you need help? What can we do for you to improve the situation? That's what I was thinking of. Yeah, I think that's a fair assessment. So one thing that I would always add to this and this came up multiple times, this exact same definition came up multiple times. Oh, so basically- I wanna see you on the camera. So basically all I wanted to specifically point out is, see ambassadors belong from the federal project on multiple teams, right? So think about it like if I am an ambassador and I work for the QA team, so I basically have some working knowledge of what QA does, right? So when I go around and do advocacy and that's probably the next part of our talk, which is Fedora Advocates, that was created to basically do advocacy for Fedora. And most importantly, do advocacy in such a way that we could get and retain contributors to a specific part of Fedora. So if you're good at, let's say design, you would onboard somebody to design team and you would help them maintain that retention period. And that would drive or help ComOps get the matrix out to understand if that is what a contributor sustainability story would look like for us. Yeah, that's one of those things. So I like the idea of making, I think it makes a clear line, both with the marketing and ambassadors and all those things to say ComOps is internally focused. That might include supporting teams in their externally focused roles. And you know, things are fluid. There's no like, you can't talk to people, someone who's not part of the project yet, you're in ComOps. But I think, yeah, as part of that, I think it might make sense to move the ComOps bubble from underneath Mindshare to actually directly under the council. I think we talked about this a little bit before as well because it's something that is supposed to operate on both sides of that project. And part of the reason Mindshare exists as a thing is because previously everything on the left side there, the engineering side basically, was connected up through Fesco, at least nominally. Whereas all the other groups were just kind of bubbles floating around the project and it didn't feel like there was a place to connect. So that's kind of where the idea of, it was originally outreach and then Mindshare and ComOps kind of grew out of that. So that's why there's a thing there. I'm not sure that it's had its own challenges, but I think ComOps doesn't fit under that. And I think moving it to council and making the whole org chart get redrawn is probably the best thing. Which would kind of match the program. It made John make a very confused-looking face. But I wanna hear what that's about. All right, I guess, and I feel like I'm gonna derail the current conversation. So please feel free to jump back in. But I guess my question is, what's the point of this reorganization? Cause I'm hearing a lot of different discussions. Some of it feels like, it's like, well, ComOps doesn't have enough capacity to do these sort of tasks and we wanna move them into some other part of the community or organization that we feel might have more capacity to do these things. Maybe the blog or something. Some of it feels like maybe because we're situated here within the organization, we don't have as much easy access to groups in other parts of the organization. So maybe we should move somewhere or we don't have the capability to standardize certain processes across these groups. And then, and this is purely like, I'm not saying it is or it isn't, but some of it might feel like just kind of organizational bike shedding where it's like, well, are we gonna be like this color or that color? Are we internal or external or that sort of stuff? Which I'm not saying are invalid, but I'm curious from everyone else's perspective, like what is the goal if this were to move, like what are people hoping to do? I could respond to that, but I'd actually really like to hear from, in response to that point specifically from Mike or did you want to make a reply to Mike's comment? I think the question to be asked then to move away from the bike shedding is is there a need for a commops team? You know, what would be the purpose of the commops team? And basically what we already defined is to enable different teams to work together and or to bring teams together basically to help people out. And I think that need is there, that is real. And there is no good, I need to choose my words carefully, toes along these days. There's no good part in the community where you can turn to if you get stuck. Then it's usually asking different people around until someone steps in and gets unstuck. And I think that's exactly the idea behind the commops team to have a body to turn to. We need to bring people together to keep things going. And that's also what I was trying to refer to with my analogy to the cement in the brakes and the oil in the engine. Sometimes stuff gets stuck and it needs to get unstuck. And that's usually a hard part within the community currently. Kind of feeling like maybe the why commops part hasn't been clearly articulated. I'm not sure if that's. So I guess we need to emphasize more on why the value for commops to the entire contributors. Like why would we want to have contributor investment in commops? To make more sense, think about it this way that when we add anything in this org chart it is to either expand the project in a direction or get quality of life better or in some ways make a meaning out of this particular group. So one of those things that we probably need to understand or talk about is how commops can actually benefit the larger community. So if we are doing storytelling, should we be doing storytelling for like an approach how to get the pieces out? Do Robert come back to Sean maybe? And then Eva? So one thing I would just add and I'll think of it in my DEI mind. So some of the things that commops is doing is very much around about contributors. So I'll think of it from Fedora Pride. We wanna make sure that everyone has a safe space who is in our community, right? The same thing for the accessibility team or indoor women or anyone in DEI. It's kind of an overlap. It's making sure contributors have a safe journey. It's kind of in a different mindset. It's more about the work you do at Fedora, like what you're volunteering and contributing in. But in the DEI side it's kind of a little bit different. Our focus is more about specific community issues. But in some cases commops is more about the community as a whole. So I'd actually kind of agree with what Matthew was saying just a moment ago is commops and DEI are kind of in some cases an overlap because I would care from a Fedora Pride perspective, are we losing contributors? I wouldn't wanna know how many of those joined the Fedora Pride SIG and was contributing and then they're leaving. Was it a contribution issue somewhere, right? They struggled to get information or something like that, right? And maybe could as DEI could be have provided more support. I'm gonna take a look at Matrix. Okay, now my confused face was just about the like whether it should be under here or under here. I guess I just don't know what logistically it means for it to be, like I know what it means for me to be under my manager in ASPO in Red Hat. Like I report to him, he gives me performance reviews, he reviews my budget. Like what is it, what's the logistical difference of commops, do they report into Mindshare Committee versus reporting to council? Do they, like what's different in? So yeah, although we have, it's been a challenge to do it this way, we have had efforts to have like reports of what's going on in the project wrap up in this structure. So there is actually that literal reporting structure not in terms of like who does your paycheck but where the reports go. Like that, there's, it's very hard to do that even when your paycheck is on the line. But even for volunteers it's been hard to do it but that's the idea of reporting. But also I think just for the like where that group is supposed to have impact. I think I'm just putting it there on the chart makes a little bit of a difference. Part of this of the why to me is, there's two things. One is from the Fedora Council point of view. The Fedora Council is comprised of people, a couple of people like me and Justin who are hired to do our jobs there but also people who come from these other parts to kind of connect things together at the top which is good but it also means it's people who don't have a lot of time to do things. So when we've got like the council should do this or we often have ideas or people come to us ideas and then we have no actually doing it branch of the council. So to me, in some ways, commops could be the, I don't know what's the right term but the actual. Yeah, I didn't want to get too much, I didn't want to get too much into like the structure of the US government into it but yeah, it's the implementation arm of the council or the council, here's some things we'd like to do and somewhere we can hand them where there's people like, oh yeah, we'd like to work on this or else tell us that can't do that or whatever but just like some place council can delegate things. That would be a really strong why for me because we don't have that. And the second one is actually more personal for Justin which is when Ben and Justin and I were kind of talking about the role when he was first hired that we did some white boarding about how our roles exist and overlap and we did, there was a comment somewhere that I'm not the CEO of Fedora which is absolutely true but in terms of analogy of where my job sits and what I do, it kind of is like that chief executive officer position where it's everything that happens is my fault ultimately in some ways and it's kind of that's a lot of those sort of roles and Ben saw the program manager role as a basically chief operations officer and that's actually why we went with Fedora operations architect for the possible new job like that and this has got some secret stuff on it Justin so don't show that with everybody don't read it with fine print but yeah, that role was fairly well focused much more than mine and far much more than Fcake or FCA role which in the corporate analogy is chief people officer, chief marketing officer, CFO, chief financial officer, like there's like I don't know five or six imaginary C-level titles we could put on this role so that's a whole lot so it felt like wow that's too much and maybe it would be nice to have a team that could help support some of those things it doesn't necessarily need to be commops but that's just all that stuff kind of needs support and that's much more vague than the first thing but that's part of the why from my point of view also and maybe commops is an answer to all of them but commops hopefully can be the answer to some of it so we're gonna shortly get into the last interactive portion of this so we will go I think is it Mike, Ifa, Penguin, P? We'll do those last few and then we'll- Mike has declined his questions, he's sick of being ignored I'm joking, just a short observation and maybe as a possible output for this session so we began the session like with people giving what they think that the commops team does and I said that it surprised me that I was expecting it to be more technically mechanical focused and there was an awful lot of the soft skills which is a wonderful team to have but it's quite hard to scale which sounds like it's one of the core problems not to say you should reduce your soft skill mentoring and support but sometimes it's hard to be both and if you're missing your main primary focus how are people supposed to know what you do in every other kind of governing body that we saw on that diagram you can tell Fedor Council is governance you can tell that Fesco is technical steering or engineering or technical steering, et cetera we now know mindshare is more administrative and budgetary, et cetera if you can't list what your group does in one sentence you're doing too much so maybe as an output for this is would it be feasible to get some sort of like a mission statement or vision or a simplified this is who we are and this is what we do and then obviously there are layers down to that so operations might be, there's many meanings to that but a main core tenement of the group that's a great point and you are all gonna help us draft that in just a couple minutes here thanks for the idea I just wanna check, Penguin, Peter, Mike Peter, do you have any, all okay? All okay Okay I still wanna know The why? Yeah, the why So a comment about moving the commops team around and like, does it make sense to have it under something else or on the higher part? Part of that being about a visibility and making some of that work more supported at higher levels of the project if I'm summarizing that right? Yeah So Amy mentioned about the OpenStack governance board and how they've structured it with some of their teams so I know you wanna be mindful of time we're in the last 15, 20 minutes here so what we're gonna do is by show of hands how many of you know what a community initiative is formerly known as objectives? It's like okay, like 25% I would say okay so if you don't know what these are we are gonna ask you to help us draft some of the mission statements or high level goals of a initiative for community operations. If I can remember the, it'll redirect me. Yes, so what are community initiatives? I will summarize this for you in that whenever we're trying to do a big thing in Fedora that usually involves working with lots of teams and lots of people and might take anywhere from 12 to 18 months we encourage people to do it as a community initiative formerly objectives put, is that better? Okay, thanks for that. So again, every community initiative has a designated community initiative lead it can be a group of people we've had co-leads for these before the logistics aren't so important but the important thing to take away is this is like a 12 to 18 month timeline for doing work, doing like big work in the Fedora community. So without getting into the nuance here I'm just pointing this out as what the structure is but what I'd like each of you to help us draft is what are based on all this discussion we've been having in here what are top level goals or objectives that you would like the community operations team or you feeling the community operations team should address in this reboot revival? So I think do we still have we maybe do some more sticky notes I don't know if everyone is exhausted on their sticky notes or see a few do we have the big pad? Where did the big pad of stickies go? I do not have it. Do you still have the big pad? So Montreux? So it is 12, 11 right now we'll take, this one might be a little more thoughtful so we'll take like six, seven minutes we'll come back at 12, 18 or so we'll give us seven minutes to kind of discuss what we all have here. So what? Really? Did I mis-type it? We won't hold you for lunch we won't keep your appetite but we'll just take like six to eight minutes here and just write down what things based on our discussion today what things do you think should be top level goals or objectives of a community operations community initiative? If you do have any questions just pop your hand. These you can come up and if you're done you can come and put them up on the flip chart in the front. Oh. I'm done causing leg injuries. Okay. We're gonna bring it back up five, we got five minutes. So we're gonna do five minutes to go through the future destiny and fate of commops in five minutes, let's go. So while there was the chatter Sumantro and I were going through and grouping the stickies again we've got a few that we wanna ask some questions about but we were roughly able to put them in four buckets of work and then life advice column of general tips and tricks. I don't think, we probably don't have time to read all of them but the four buckets we came up with was the one common theme was around processes. The creation, documentation and maintenance of how collaboration works and making sure that those things are clear. The second theme is around, I'd say outreach and engagement making sure that you're not just having processes that people know about them and are empowered to do things with those. There was the metrics one, metrics and data science piece and then one that was kind of on its own which we did wanna ask on that one. So in the first one we'll start, we'll go left to right on these. We've got three under the processes how to do things bucket and I'm gonna read out the sticky note and all we wanna know for these ones is like just clarify what you wrote just to get your perspective on this. So the first one we wanted to ask someone wrote managing organizational and project processes. That was EFA. So give us the juice and because we're tight on time, a few sentences. Be as quick as I can. Hang on. Stop interrupting me. Okay, so the Fedora project has many processes and things like that and it's basically just around standardizing on them making sure that either they all like there's wiki pages if that's what we're using or Fedora docs or something and they have a coherent kind of template and they're up to date. They don't go stale. So just managing that upkeep. The maintenance work. Yeah, not necessarily writing them but making sure they're written correctly. Yes. The next one we had was execution on strategic plans. Parentheses, project management, PGM. That kind of goes to what Matthew mentioned around the Fedora council needing a group of our team to execute on plans and stuff. So I have a triage one as well so if you want me to run through that one too, I can. But basically it's if the Fedora council has some initiatives or objectives that they want to execute on then the community operations team does seem like a logical choice to execute on those plans. Again, not doing the work but shepherding the work, overseeing the work, making sure the work is happening and that there's like a reporting structure in place or accountability. They're just that linchpin that a project manager or a program manager would often play. Perfect. Next one is determine and quantify the roles and responsibilities of commops so as to remain focused and head off scope creep. Is that a familiar? Who is our author of this one? Unless they... It wasn't me but I agree. I think we were curious on that one because there was the quantify keyword in there and we just wanted to understand that but maybe our author was too hungry. So, all good. The next one, so in the second column around which was general ones around engagement. This one, I think we wanted to understand the diversity piece on it. It just says enhance engagement and diversity. Do we have the author of that one in the room? Dang, should have front loaded all of these stickies. All the people had the controversial ones. I wrote it and then they left. Damn. And then the last one that we just wanted to clarify is manage cross organizational infrastructures, bullet points, community metrics, Fed message, Fedora blog, Fedora policy docs. That was mine. So, in a few sentences, commops is a cross organizational team. It's kind of meant to work, be the glue, someone said, right? So, any infrastructure that is assisting in that, whether it's like whether it's Fed message or if you're running for more lab or if you have other infrastructures, like technical infrastructures that kind of are helping glue all these communities together, I would say across organizational team like commops would be a good place to put that. I know there's probably a lot of that and to like dump it all on your labs would probably make your brain explode and be bad, but that was sort of my thought. Well, that's really interesting because I would say that from my perspective that commops should own those things, but perhaps we should find a CPE friend to be our co-objective lead or someone who could help us rep that side of the house. I had exactly the same thought. That sounded more like the definition of CPE. So, it seems like working with the right stakeholder is a key part, right? Because that infrastructure is important. It's a community platform engineering team at Red Hat that basically is the... We should not be saying CPE here. We should be saying Fedora infrastructure. So, CPE is a Red Hat team that one of their remits is to work on Fedora infrastructure, Fedora incentives infrastructure. And there's been a little bit of conflation not badly intentioned, but just over the last few years and I wanna make sure we keep that separate. So, let's not accidentally do that and add more confusion. Yeah, in for a team, that's what's meant. Yeah, it wouldn't necessarily have to be somebody, for example, who is a Red Hat or on the CPE team to do this. So, one of the comments I wanted to add over there is, I think I attended a talk yesterday. So, some of these apps that was mentioned over there, they already fall as a part of critical one or two. In that case, any which way Fedora takes care of it. But if there is something that is not, like a Grimmar lab would not probably fall under it, but CentOS and Fedora can both benefit from it. That's the ecosystem stuff. In that case, yeah. So, we'll do IFA, Robert and lunch. This would be really quick. Just to kind of like... Just to compliment what Samantha was saying and where that help would lie. Yeah, the CPE team, the community platform engineering team that Red Hat sponsors pays for, there's a couple of us on the salary. We do take care of a lot of those applications, but the Fedora infrastructure team is not just CPE, it's community folks, but the ComOps team would be a very interesting team to be able to know the processes to get tickets opened in the CPE team that the infrastructure is failing for whatever reason in that. So maybe there's just a bit better synergy needed between maybe the ComOps and the internal Red Hat teams. All right. Well, we are pretty much at time, so I don't want to hold you from your lunch, but before we wrap, I did just want to give a huge appreciation and thanks to my co-presenter because I was buried in all the flock things and did not get to put a lot of time in the organizing end of this, and Sumantro owned a lot of that. And in addition to this session, he's also been doing a lot of it for the last two years with the outreach revamp, together with Mariana Bala and Marie Norden. So I just wanted to acknowledge that all the work that Sumantro has done, yeah, and Sumantro, Mariana and Marie specifically, because as you saw on the org chart, there's a lot of history. It's a very big thing and it's hard work, and I'm appreciative of the work that people like Sumantro is doing. I'm thankful for all of you, for spending, some of you have been here since nine with me, others of you joined for this session. So thank you for your time and enjoy your lunch.