CommOps

Help wanted!
You can help with this stuff! Join us on #fedora-commops on Freenode!

IRC

#fedora-commops on Freenode

Community + Operations = CommOps

The rise of DevOps has been swift. Sysadmins are increasingly instrumenting and integrating automated systems to stand up and maintain their infrastructure. This same approach can be taken to support community infrastructure in a distributed and automated fashion, that doesn't force people to choose between using their precious volunteer time to "build things" or "build communities that build things."

Delegation

One person, Lead or otherwise, cannot possibly know everything that is happening in every corner of a project the size of Fedora, let alone where each of those sub-communities would like to go in the future. To do this, we'll need broad participation across many teams and communities. I would propose a delegation, rather than an elected board, or other top-down style governance structure, be the vehicle through which to gather input and reach consensus on community infrastructure. Delegates will represent distinct groups within Fedora, selected from within their delegation, with additional input/participation by non-voting delegates who want to be involved.

Delegations include

• The 13 Fedora Subprojects
• The five working groups (three Editions, plus Base and Stacks/Env Working Groups)
• Any active and interested SIGS (will be opt-in)
• Distinct web properties without a team/committee/group (Ask.fp.o maybe falls into this category?)
• Other moving parts of Fedora that I have not yet identified, but should have representation

Operating Principles

• Instrument activity in existing communities to create and track metrics (a good initial effort exists at http://thisweekinfedora.org/)
• Federate and syndicate with as little burden on contributors as possible (like middle-ware that wraps and pipes existing process/activity)
• Community engagement and outreach is something *everyone* in Fedora should be concerned with and invested in, not just Ambassadors or Marketing.

Techincal Strategy

• Use real-time communication channels and infrastructure when possible (Fedmsg, FMN, Zodbot, others)

Meeting Format

I would like to adopt the ticket strategy that is used by Design Team, resulting from their latest FAD,, which is ticket-driven meetings, with open-floor at the end.

1. Tickets that don't get requests for information responded to after 2 weeks, become inactive.
2. Tickets that are stalled for 2 weeks either get unassigned, or can be renewed for an additional two weeks by their owner.

Things that the Fedora Community Operations (CommOps) Team helps with:

• Unified Messaging. It is my hope that when someone asks the question, "What is Fedora?" to an existing community member, *everyone* will have at least a standard elevator pitch, whether you are a designer or engineer or translator. Ideally this is going to be informed by the Fedora Core Values and Mission, and developed in the open similar to the Red Hat Mission Statement. Much input from existing groups (such as marketing and design) will be needed.

• Curating a queue of "stories." Much in the spirit of BoingBoing.net, the idea of "Cover Posts" which can be generated from existing content, and point to those existing parts of Fedora to minimize the burden of "publishing in yet another place." Content that is highly designed and curated already (announce-list, Fedora Magazine) should get the "greenlight" to be published automatically, and others added to a curated content queue from the community by Zodbot, mail-list, Fedmsg, and/or other means. This queue of curated content will help feed both Fedora Magazine (end-user focused content) and a here-to-for undefined Community/Contributor Outlet (perhaps a council or CommOps blog?)

• Badges Requests. To help direct contributor activity, the community team will help existing sub-projects come up with badges, and series' of badges, to establish an official process and credential for team/subproject membership. The badges *design* process is operating very well, but the badges *strategy* process falls onto the design team's already full plate. Let's fix that.

• New Contributor Onboarding via Fedora Hubs. This is an existing effort, with momentum, and full support of the design team, and buy-in from the infrastructure team. I am *thrilled* to not have to create or recreate this wheel, and want to support Hubs as the community team's official strategy. The gist is: "The point behind the idea was to provide a space specifically for Fedora contributors that was separate from the user space, and to make it easier for folks who are non-packager contributors to Fedora to collaborate by providing them explicit tools to do that. Tools for folks working in docs, marketing, design, ambassadors, etc., to help enable those teams and also make it easier for them to bring new contributors on-board." Proposal here: http://blog.linuxgrrl.com/2015/03/24/enabling-new-contributorsainstorm-session/ and results here: http://blog.linuxgrrl.com/2015/03/25/summary-of-enabling-new-contributors-brainstorm-session/

• Wiki. The wiki is aging. The wiki tries to be all things to all Fedorans. There are a number of initiatives happening (I've heard Pete Travis is moving User Docs out of the wiki into a readthedocs.org style site, pfrields says there is an {{old}} tag that is going to help us sift through content, and there are likely other initiatives too) We'd like to do things like automatically generate User pages on the wiki (in the spirit of the badges template) so that users don't have yet-another-place-to-edit.

• Internal Communications. This is an ongoing and difficult problem, and we have come up with an approach, but it does resemble the so-far-proposed structure of FOSCo. Each of the 13 official subprojects, active and interested SIGS, working groups, and each web-property (Ask, Magazine, etc...) can choose a delegate. Since this is a *massive* synchronous effort, we will need a way for each delegate to report on behalf of their delegation via a template. That template will be ticket driven. Creating zodbot hooks to fill in this template from existing IRC meetings will solve this in many cases, but not all. Having a method to manually submit reports will help as a fallback.

• Perhaps Code of Conduct and Diversity may make sense to fall under the community team as well. The new Diversity Advisor (search committee is forming now) will likely be interested, if not be the owner of this aspect of the community team.

• Metrics. Because of the Fedmsg stack, we have some very detailed raw data on Fedora contributor activity. There are a number of efforts being undertaken to generate data visualizations and regular reports based on this raw data. A critical part of developing metrics will be defining what kinds of questions we want to ask of this massive store of raw data.

• Voter Turnout. Improving voter turnout during FESCo and Council elections makes for a stronger field of candidates, and a more participatory community. This priority has been identified and added at the request of the Fedora Council.

• Other things I didn't think of (which is likely many)