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


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:

Operating Principles:

Techincal Strategy:

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: