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 management": 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; CommOps is a place where a wide network in the community becomes a superpower. A new CommOps better enables cross-sectional collaboration. "Product management" in quotes here because I didn't quite feel like it was the right way to call it either, but I digress.
• 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?