Roll call! Rebuilding a Community Ops team in 2023?

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).

Oh nooooo CA: America’s most dysfunctional company :slight_smile:

lol I concede

I started grouping this discussion into a GitLab epic, which I will attempt to use as a way to organize this research and propose a trial period for a “CommOps” (or related) team.

I was thinking more about the name. I am thinking there is more to gain by continuing to use CommOps as the team name, so that the team benefits from wider recognition and an established name working to its advantage. For example, the Mindshare Committee and Ambassador program has some policies and documentation specific to CommOps. With CommOps officially going defunct in favor of a new team, there would be extra work of transitioning old policies and decision-making models to the new team, or somewhere else in Fedora.

The shorthand is the confusing part for me.

Regarding CommArch, I think that misses the mark. Architecture for me
implies (planning for a) building. While that may apply in some
situations, the team is more about enabling people in the community
(helping them) to build something.

Edit: I had quoted below part in my e-mail reply. I really don’t understand when Discourse decides to drop quotes and when not. :slightly_frowning_face:

In IT most people would read CA as Certificate Authority, I guess. Here in Europe, it’s most often associated, outside IT with Crédit Agricole - a French bank.

As long as we make sure to write Community Operations (CommOps) at the start of posts/documents, it should be fine. But it’s still an unfortunate ambiguity.

Justin just said “Community Ops” (in a video call) and I think there we go, name problem settled.

1 Like

If we have the name figured out, it can only get easier from here. Right? :grinning: :wink:

1 Like

So, it seems like the dust is settling. The feedback shared so far is great. It helped me to get this out of my head and hear what other people have to say. Thank you all!

Call to action

Do you want to be part of a new Community Ops team? Does the things described here sound interesting? If yes, then please add your name to this wiki table under the Expression of Interest section. As we get closer to rebooting the team, this list will serve as the starting place for getting a group of motivated Fedora contributors together:

https://fedoraproject.org/wiki/CommOps/2.0

The next step will be launching an initiative to (re-)build this team. I am committed to backing the initiative as a lead and and team chair. However, I would have the capacity to drive this after Flock concludes in August[1].

So, what can you expect from me in the coming months?

There will be more Discussion threads in the commops-team tag. I suggest following/subscribing to this tag specifically if you want to keep up with the conversations or participate with the team.

I also want to start building up the roster of interested folks. The wiki page above is this first step toward this. I encourage you to edit your name in if this is interesting to you.


  1. The virtual release party and Flock will consume a huge chunk of my time until August. This year, it is my first time in the organizer seat for both of these events and it is a learning experience for me! Hopefully next year, it will feel more natural, but right now, I need to give the proper bandwidth to making these two events successful. ↩︎

1 Like

How about “Community Service” or “Contributor Service” (my preference of the 2). The group could be “Contributor Service Committee (or … … Group)” or even better “Contributor Operations Group” aka COGs :gear: :grin: ContribOps retains the clarity of purpose in abbreviated form as well… The reason being I understand Community or Contributor to describe different, albeit often overlapping, functions of the overall “base users” or broader Community. Or rather Contributors to be a subset within the Community, even if the desire or goal is for all community members to be Contributors of some form, most, including myself, still think of it as having a distinction.

With a Symlink : CommOps = ContribOps
So no need for immediate changes in docs… :laughing: I mean I’ve let y’all symlink my ~/ so nothing is too sacred :innocent:

@sowow Not a bad idea. What do you think about the three things that this new team would do? Naming might become easier once the kind of work that the team does is established.

1 Like

I would help out with the team if I had more bandwidth, but I’m tight with my job right now and expect to be even busier in the next few months. :confused:

1 Like

I was browsing through past presentations and workshops and found this abstract from 2017 for a talk about CommOps I planned to give but never did. Leaving it here as additional context and future reference: