Roll call! Rebuilding a Community Ops team in 2023?

Note: This post is cross-posted to Fedora Discussion and as a Pagure ticket in order to reach a wider range of people.

Hi folks, I am writing this as an “open letter” because I want to start a conversation and see who else out there wants to join in.

CommOps was born in Fedora eight years ago. A lot has changed in Fedora since then, and so has CommOps. My goal in this conversation is to think out loud about what a successful and healthy CommOps team looks like in 2023. I’m looking for ideas, thoughts, and opinions on what CommOps should be, should not be, and whether you want to be a part of building the new CommOps.

What is the ask?

I’m asking you for some of your time:

  • To answer: What should CommOps be? What should CommOps not be?
  • To brainstorm: What are important types of work that are not well-supported in the Fedora community today? What ways could be better support those important types of work?
  • To participate: To join in, for a little time or a lot of time, on rebuilding a new CommOps team in 2023.

What do I think CommOps should be?

I challenged myself to pick only three things:

  • Data science: In the simplest terms, looking at our large pool of data and making insightful and actionable observations about Fedora, our community, and our software. This includes programmers (to use and build tools for data analysis), designers (to devise a publishing format and outreach strategy), writers (to document and write summaries and articles about the data), or anyone with a mix of these skills.
  • “Product operations”: A team to handle unique requests that involve coordinating and working together with two or more community teams. Basically, a role for contributors who work in several different groups; Community Ops is a place where a wide network in the community becomes a superpower. A new Community Ops better enables cross-sectional collaboration. “Product operations” in quotes here because this may not be the best name for this kind of work.
  • Storytelling: Making sure the important messages and stories about the Fedora community are being captured and told. This is a “culture” type of role that helps create a type of documentation that describes what it means to be in Fedora and who are the people behind it. There are some examples of how CommOps did this in the past, here and here.

What do I think CommOps should not be?

I challenged myself again to only pick three things:

  • Community Blog (CommBlog): The CommBlog editors should be an independent team from CommOps. Looking back, I think our team’s purpose was washed out by the success of the CommBlog. People only knew CommOps as the team of people who reviewed CommBlog posts. The blog grew and others took ownership of it, but CommOps was still tied to it. Instead of CommOps owning the CommBlog, CommOps would help build a small team to help out with editing.
  • App development: This is a better fit for the Websites & Apps Team. CommOps should avoid any app development and limit coding/software development only to explorational data science work. This ensures the Websites & App Team remains the best place in the project to go for working on websites and apps in Fedora, and CommOps keeps “tech” contributions narrowed to data science work only.
  • Fedora Ambassador “owner”: CommOps should not be the team responsible for Fedora Ambassadors. CommOps may have a role to play in the administration of the Ambassadors program, but decision-making authority should rest with the Mindshare Committee. Since the 2020 Ambassador revamp, CommOps is the supervisory team for the Fedora Ambassador and Advocate programs.

Why now?

CommOps is special to me because I helped launch the team in 2015 with then-FCA Remy DeCausemaker and several others. When the team began, it had a specific vision on helping us work more effectively as a community and make sure that important areas of the contributor experience did not go unaddressed. In many ways, CommOps was a working group for community issues in Fedora. However, people came and went and processes were forgotten. Over time, CommOps began to mean something different to different people.

CommOps was important and unique in its beginnings, because it was a team where both the Fedora Community Architect did many essential tasks and responsibilities in the public, but also together with a team. It was a unique team because anyone could help and contribute on community issues and make high-profile contributions in Fedora. (Heck, that is something I attribute to why I am in the role I am now.) I want a new CommOps team because Fedora needs it now more than ever. We need to help each other collaborate and work together effectively and efficiently as a community of communities. This ties to our Four Foundations, which were the backbones of CommOps from the beginning: Freedom, Friends, Features, First.

So, I have been in my role for just over six months. A lot of my time was spent listening, watching, and observing (in addition to hidden admin work required in the job). Now, I feel confident that we need a new CommOps more than ever. But the question I have is, how do we do it? What does the community already know about CommOps? Are there common needs across the community that a new CommOps could serve? The first step in this process is to have this public conversation.

Let’s discuss!

Here are my “pencil notes on a napkin”. The thoughts are not fully developed. But I hope folks might help develop them by sharing feedback, so we can make this important team healthy and vibrant again.

What do you think about all this? Is anything unclear?

2 Likes

The Marketing Team Angle

My first thought with reading this post is that a lot of what CommOps is supposed to be doing sounds a lot like what a marketing team would be doing. Data science is market research. Product management is about enabling product development where we wouldn’t be doing the implementation work ourselves. Storytelling has to do with brand management at a high level.

Then I came back down to reality and remembered that a lot of things can be considered marketing in an academic or business sense. Technically the Design Team is marketing. So is Ambassadors, Fedora Magazine, and even Mindshare. Despite how one might want to categorize things, you gotta draw the line somewhere. That said, I do think that there might be more collaboration and overlap between CommOps and the Marketing Team than with other teams.

In this frame of reference, I think that CommOps should be a high level marketing minded team. From a market research perspective, we’re analyzing data that comes from outputs from our marketing channels (at least some times) to make high level inferences. From a product management perspective, it’s about taking the feedback that marketing receives and essentially doing the follow up where it makes sense. From a storyteling perspective it is providing high level direction to the marketing team. With these connections, I don’t mean to constrain CommOps to these things, but rather highlight the back and forth relationship that they’re likely to have with the Marketing Team.

To that end, CommOps should not be a low level marketing team. If high level marketing is dealing with broad and strategic ideas, the implementation details should be left to the Marketing Team to finish off the intention. The Marketing Team can be the ones to execute and maintain the concrete connection to the community with defined, tactical deliverables. We can help put together and publish polls that can be analyzed. We can help organize or summarize feedback that can inform product management. By slicing responsibilities in this way, we can divide and conquer on action items.

Based on what you’re thinking, it seems like CommOps would be doing more than just the top three things you describe, so I don’t mean to restrict the idea by implying CommOps is the yin to the Marketing Team’s yang. However, I think it’s likely that Marketing Team members will be interested in CommOps contributions and vice versa, so it’s valuable to define the difference. For example, I would be interested in data science and storytelling conversations, and you are literally in the Marketing Team. I think I’ve made my point about synergies, lol.[1]

Please let me know if I’m misinterpreting anything about this!


The Mindshare Committee Angle

This one is shorter, I promise! If the Mindshare Committee is the decision-making body for non-engineering initiatives, then CommOps is the action-oriented team to work on tasks that we don’t have a team for (or may not need a team). Is this part of the vision for the team?


  1. To be honest, depending on how things go, I could see these teams merging at some point in the future based on the similarities. ↩︎

I top-posted this quote above my full reply because I thought it was the best summary.

CommOps would be an action-oriented team to complement both the Mindshare Committee and also other mindshare teams in Fedora. The scope of CommOps is internal to our community. However, anything a new CommOps commits to today should be focused and narrow. We have to get good at a few things before we can get good at many things.

There can be functional overlap of skill sets. But the focus and direction of the work is different. When CommOps began in 2015, our team described it as an “inner”-marketing team. While the Marketing Team focuses more on interactions with end-users, consumers of Fedora, and keeping up with wider media channels, the CommOps team works primarily inside the community.

I see a different way of slicing CommOps:

  1. Data science is our community health and sustainability research.
  2. Product management is about facilitating collaboration between multiple teams for various release-driven and non-release-driven tasks.
  3. Storytelling has to do about the Fedora community culture and how we do what we do together as a community.

I agree!

A team like CommOps would complement a team like Marketing. CommOps also provides a pathway for folks in the Marketing Team to go deeper into the Fedora community by bringing their feedback and insights closer to the development.

I believe these are roles suited to the Marketing Team and I think it should remain this way. These are important tasks to get a pulse on the perception of Fedora outside the community and also share key messaging to those who do not closely follow the contributor community.

Sometimes there might be skill overlap because CommOps could do similar tasks as the Marketing Team in function, but they will be focused inside our contributor community.

Does this make sense?

Theoretically, CommOps could be many things. But I think that is also the challenge! In the past, I believe CommOps came to mean too many different things for people. The things CommOps was originally structured to do well were not supported as well as they could. This time around, a CommOps team should be disciplined and firm on what is considered “in bounds” and “out of bounds”.

So, for this proposal, I contend it must be only three things!

I agree. One challenge is to find a better way of sharing these skills so that experienced contributors can access support on these three things, and newer contributors can better establish themselves meaningfully across the Fedora community.

Ah, ok, I got confused, my bad. I imagined CommOps as ‘communications operations’ when it really seems to be ‘community operations.’ From that point of view, I totally understand what you’re saying about being internally focused for the team, so we can probably scrap a lot of the marketing angle I said. I think I’m following now!

1 Like

This is a good observation to catch now, because CommOps is not a conventional team. This was a challenge we faced then in 2015 and will also be a challenge now in developing a team identity. :slightly_smiling_face:

Thanks for sharing feedback here!

The three things you listed are good, but I don’t see that they’re well connected. A team should have a singular focus, and I’m not finding that here. What you describe feels like three separate teams that might have some overlap.

1 Like

Yeah, I think Ben has a good point. Particularly, I don’t see the data science / metrics skillset and interest as having much intersection with the others. Maybe there’s an angle I’m not seeing?

We should definitely avoid saying “product management” because that’s going to confuse some people who work for our dear primary sponsor in unproductive ways. Can you give some examples of what this work might be?

And, isn’t Storytelling definitely Marketing? It’s not (ahem, sorry to our primary sponsor) “product marketing”, but it is marketing for the project and community. (Analogy: Life at Red Hat - YouTube)

That’s exactly what I had when I read CommOps. Somehow my brain translates comm to communication first. Even though the context made it clear this is about community, my synapses are still strongly objecting.

Since first impressions count[1], I would suggest coming up with a different acronym. While I cannot think of something right away, I’m sure the creative folks (Marketing?) could provide some input.

With that said, the three main topics/branches sound interesting, as does the goal, empowering the community. I would be most interested in contributing to and learning from the Data Science team. I will let all the information sink in and follow the discussion.


  1. One of the universities over here some time ago used to be known as Katholieke Universiteit Tilburg (Catholic University Tilburg). As is common for universities, their names get abbreviated, which resulted in KUT. That’s a loaded word in Dutch, to put it mildly. The university is now called Katholieke Universiteit Brabant (Brabant being the province, where Tilburg is located). Yet everyone still knows it as kut universiteit. :thinking: ↩︎

Just to refresh what CommOPs is and is not, I re-read the CommOps team page here, which is well tied into ‘what is’ question.

What are important types of work that are not well-supported in the Fedora community today? What ways could be better support those important types of work?

I presume the objective of this thread is to drive CommsOps across different teams. Is it correct?

We need common sets of data analyzing Fedora contributor activity that needs to be summarized as dashboard. Operations in any domain/industry start from data and how to share the results internally and externally. At the moment, some project teams have micro level metrics that are well established and published like CPE. We need high level metrics that tell us how we are doing.

In case of docs contributions, I look at various data points (Google Analytics, Pagure repo, GitLab/GitHub analytics) and wonder if we can consolidate common data sets into some sort of data warehouse and push it to dashboard tools using a connector or datagrepper. I could participate in ‘brainstorming’ sessions and early stage of rebuilding project.

Thanks all for the helpful comments and questions!

The common thread to these three areas is that they are positioned to understand and advocate for the Fedora community. I suppose that could be the basis for a vision statement. Each of the three areas contributes to this vision in its own way:

  1. Data science vision: To know and understand the ground truth of the Fedora contributor experience.
    • Questions of inquiry[1]: What is the Fedora contributor experience? How do people interact and engage with the Fedora community? What appear to be successful and unsuccessful areas, looking at available data? What are hypotheses to test where if we made a change, it would impact the results we measure? Are there important kinds of community work that we should be better represented in our data?
  2. “Product management” vision: To facilitate collaboration and innovate on our best practices.
    • Questions of inquiry: Based on what we know, are there common bottlenecks that are faced by many contributors? How can those bottlenecks be improved? Is there important work that could be better represented inside and outside the community? How can we help facilitate conversations and working together between teams on the different “sides of the house” (i.e. Engineering and Mindshare)?
  3. Storytelling vision: To communicate our culture and make the implicit into the explicit.
    • Questions of inquiry: What does it mean to contribute to Fedora and to be a Fedora contributor? Why do we do what we do? What brings us together as a community? What are examples of these things? How can we make the Fedora contribution experience both relevant and interesting for newcomers (whether that is to Linux, open source, or both)?

+1. I am using quotes because the term isn’t right to me either, for what I am describing. Perhaps just calling it “operations” work is better, but somehow that does not feel exciting to me. Maybe I worked too long in the public sector though. :slightly_smiling_face:

My view towards community work could be summarized as story-driven. I feel stories are more impactful than letting data/numbers speak for themselves. This gives me a biased view of storytelling, but I could see it being confusing. It feels like a buzzword.

Perhaps “documenting and maintaining the Fedora culture” would be more appropriate.

Is “Community Architecture” (shortened CommArch) more or less confusing? Or is the shorthand for “Community” -> “Comm” the confusing part?

I’m not sure what you mean by driving CommOps across different teams. Could you ask another way?

Generally, I do see CommOps as driven by contributors who often work across multiple Fedora teams already.

I agree. There is past work with great examples of this. Bee Padalkar wrote this report about FOSDEM 2016 and how our participation there reflected in the community. Bee later presented this 2016 study Flock 2016. The study found that if you watched the fedora-messaging events by contributor who had never appeared before, the average time spent by a new contributor was three months. At the time, this was an actionable insight that let us ask deeper questions about why a typical newcomer would only participate for three months, and then drop off.

It has been a long time since we pulled data like that, so it is hard to know if these patterns changed or not since COVID-19.

I have noticed you are working on that lately with Fedora Docs. Thanks for your help with this!

I am curious, when you say the early stage of rebuilding project, do you mean with a “CommOps” team (or whatever we call it in the end) or on a data science sub-team specifically?


  1. This definition is not exclusive of packaging activity but I would not look at that data first for new analysis efforts. ↩︎

1 Like

What I mean by driving CommOps across different teams chimes with your ‘why now?’ paragraph and the vision when the team began, particularly this line.

“common needs across the community that a new CommOps could serve? The first step in this process is to have this public conversation”.

I mean a data science sub-team specifically that I’m more suited to.

Annual contributor survey could reveal more about difficulties faced by contributors, or maybe by their choice - casual contributions, which isn’t necessarily a bad thing.

I think that shortening it to “Comm” is that part that tripped me up.

From what I’ve read, I know we want to avoid this term because it doesn’t really fit, but it seems like “Community Management” is the term to use. If you used this term to someone outside of Fedora, they would most likely understand what you mean. I know that Fedora doesn’t really manage contributors, but I also think folks understand that you don’t manage a community in the same way that you manage employees. They’re not the same thing and so folks won’t apply the negative connotation to the “management” in Community Management. At the very least I think it immediately helps to ground the team and its purpose in a way that people considering to join the team can understand.

To me at least, “Community Management” implies a Company :arrow_right: Community “push” activity. Someone in that role steers the community towards the company’s best interests, and (I know this is a little cynical) “manages” emotional reactions and outbursts from community members so they have minimal impact on the company.

Maybe that’s too cynical, though. What would a community management team that works for the community look like?

Yes. I want to know what others think of the team concept now at this early stage. The feedback informs ongoing work together with other folks in the Fedora community on addressing different friction points.

My bias is that I also believe a team structure provides a way to be more transparent about things that the Fedora Community Architect is working on to the community. It is better (and I think easier) to work together openly with others than working in a vacuum.

Good to know. What area of the data science work would you be interested in helping with? I could think of three ways that we could divide the efforts in the data science team:

  • Data collection and cleaning: Use existing tools to fetch raw data from fedora-messaging and export/clean the data in a way that is easy to share and download.
  • Data analysis and visualization: Use the exported/cleaned data as a sample for testing questions about the Fedora Project and the community. Understand trends and look at correlations between actions and activities that might not be represented in data.
  • Design and communication: Work with someone analyzing the data to create clear messaging and outreach materials for advocating discoveries and learnings to the community, and growing awareness about the team in general.

Also, I ask out of curiosity and not committing you to anything here. :slightly_smiling_face: If you have this interest, then I would guess there are others who do too.

+1. The contributor survey could be a duty for this team to fulfill, although I’m not sure whether that should be in the initial scope or not.

I would lean with Matthew because I do believe working in a community like Fedora is notably different than working in other open source communities[1]. I think we want to separate ourselves in this way, because the work is different. I also think this is a place where Fedora can be innovative in how we work and collaborate.

I contend that this happens more often than you think. :grinning: In my previous role, one of my biggest responsibilities was mentoring startup companies on how to work in an Open Source way. For someone who not immersed in it, it was a big jump to be so open. It felt intimidating and so coaching helped gain confidence in working open.

While there should be an open call for anyone to participate in this team, I think an initial recruitment strategy might be shoulder-tapping others in the community who feel they could contribute in this space. This way, we can form up the team and get a strong base before we open the floodgates for newcomers. It could even take time for experienced folks to get the team established so newcomers can be guided effectively.

This way, the team could develop that team definition and how we position/explain ourselves in the community.

I am contending my list of three. :slightly_smiling_face:


  1. We are carrying a lot of “historical baggage”. Most open source projects today don’t have a 30+ year old history and culture. Never mind that Fedora itself has existed for 20 of those years! ↩︎

  • Requirements analysis: what success metrics do a CommsOps want to measure and track? How about team-specific metrics?
  • Data collection: Discover full inventory of data sets and API (Example: Pagure API reference, GitLab value streams, GitHub repo statistics) and data mapping
  • Data aggregation method: fedora-messaging, what else do we need to fetch data from external systems? Assess a need for custom-built connector or script
  • Proposal and scope of work

I tried to match my skill set and experience from my day job in the last two years.

2 Likes

Hmmm. Is this is separate thing from “facilitating collaboration between multiple teams”? I really like the active nature of these.

I like Community Architecture — although I’m not sure if it’s good or bad that it’s really close to “Fedora Community Architect”. I wonder if it is possibly in practice to avoid shortening it?

Thanks for this @hankuoffroad! It is good to know you have this interest, so we can try to shape things early toward what people want to do.

To me, they are similar or the same. All of these activities required working across multiple teams and (in a way) inserting CommOps into existing processes.

I like it being closer, because it ties my role to the team. In 2015, CommOps was closely tied to the FCA role, but after 2016, that tie was undone and the FCA did not participate directly. I think tying the FCA role closer to the team helps provide greater sustainability and continuity for the team.

“Community Architecture” is fine to type out. In fact, we had this conversation before! I also think writing it “Community Architecture (CommArch)” could help. But I can compromise on this. :slightly_smiling_face:

I think Community Architecture can work and I also agree with avoiding the abbreviation. Or if you’re going to abbreviate, call it the CA Team or FCA Team so that you don’t immediately make the connection to communications instead of community. Compared to CommArch, someone may still have to ask the clarifying question, but with CA Team you kind of have to ask what it means, where as CommArch could still lead to an assumption (maybe).