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

Mail Lists

Address	Function
commops@lists.fp.o	General Mailing List for all things CommOps related
social-media@lists.fh.o	The answer to "We should totally post this to Social Media!"

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)

Interest Areas

Name	Messaging	Storytelling	Badges	Hubs	Wiki	Culture	Metrics	Voting	Misc
decause	X	X	X	X	X	X	X	X	X
threebean			X	X		X	X	X	X
roshi			X	X	X	X	X		X
nyazdani	X			X	X	X	X	X	X
mitzie				X	X
jzb	X	X	X	X	X	X	X	X	X

CommOps Toolbox

Already the infrastructure, Design, and other teams have begun developing tools to help drive community initiatives and aggregate metrics.

For now, you can find a listing (to be wiki-fied soon) on decause's blog here: http://decausemaker.org/posts/commops-toolbox.html

Project	Source	Description	Stack	Interest Area
wordcloudbot	https://github.com/decause/wordcloudbot	Create pretty wordclouds from IRC meeting logs	Python	Storytelling, Metrics
longtail	longtail-analyze.py longtail-gather.py	Measure the ratio of activity/user to approximate burnout	Python	Metrics
feedcloud	https://github.com/decause/feedcloud	Take an RSS feed, or list of RSS feeds, and generate fancy wordlcouds for all/each	Python	Metrics, Storytelling
annualgrepper	annualgrepper.py	gather raw fedmsg totals on topics over 1 year timespan	Python	Metrics, Storytelling
cardsite	https://github.com/decause/cardsite	live fedmsg tracker inspired by http://emojitracker.com	Python	Metrics
meetbot-fedmsg-activity	meetbot-fedmsg-activity.py	jinja2 template that creates links to meetbot activities for each subproject	Python	Metrics
daily-briefing	daily-briefing.py	template takes lists of URLs, generates summary report of daily meetbot links and action items. Manual now, but can be automated in the future.	Python	Metrics
Fedora Hubs	https://pagure.io/fedora-hubs/branch/develop	Modern, web-based Fedora activity center	Python	Hubs
Fedmsg	https://fedmsg.com	Python package and API that hooks all the services in Fedora Infrastructure together by sending messages to one another over a unified message bus in real-time.	Python	Hubs, Metrics
datagrepper	http://apps.fedoraproject.org/Datagrepper	Using HTTP GET requests, you can query for all kinds of historical data from the fedmsg bus: events by username, by package, by message source, by topic... you name it.	REST API	Hubs, Metrics, Storytelling
statscache	https://github.com/fedora-infra/statscache	A daemon to build and keep highly-available fedmsg statistics	Python/REST API	Hubs, Metrics, Storytelling