From Fedora Project Wiki

Revision as of 22:51, 23 September 2015 by Lmacken (talk | contribs) (Fix and link to the social-media list)

Important.png
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.fp.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