From Fedora Project Wiki

(→‎CommOps Toolbox: Opting to remove Telegram from the toolbox for now until a situation arises where it will be most useful for in-person wrangling, such as a Flock / FUDCon / FAD / etc. Currently is directing people to an inactive platform.)
(Restructure, reorganize, and rework many parts of the wiki page)
Line 1: Line 1:
{{admon/important | Help wanted! | You can help with this stuff! Join us on <nowiki>#fedora-commops on Freenode</nowiki>! }}
{{admon/important | Help wanted! | You can help with this stuff! Join us on <nowiki>#fedora-commops on Freenode</nowiki>! }}


== IRC ==
== Community + Operations = CommOps ==
 
{{Team contact|CommOps|commops|#fedora-commops}}


<nowiki>#fedora-commops on Freenode</nowiki>
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 &quot;build things&quot; or &quot;build communities that build things.&quot;


== Community + Operations = CommOps ==
CommOps aims to address the area of community infrastructure by providing the tools, resources, and utilities for the different subgroups of Fedora to increase communication across the Project, collect and use metrics to direct and provide support where needed, and


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 &quot;build things&quot; or &quot;build communities that build things.&quot;


== Mail Lists ==
== Mailing lists ==


{|
{|
! Address !! Function
! Address !! Function
|-
|-
| [https://lists.fedoraproject.org/mailman/listinfo/commops commops@lists.fp.o] || General Mailing List for all things CommOps related
| [https://lists.fedoraproject.org/mailman/listinfo/commops commops@lists.fp.o] || General mailing list for all things CommOps related
|-
|-
| [https://lists.fedoraproject.org/mailman/listinfo/social-media social-media@lists.fp.o] || The answer to "We should totally post this to Social Media!"
| [https://lists.fedoraproject.org/mailman/listinfo/social-media social-media@lists.fp.o] || The answer to "We should totally post this to Social Media!"
|-
|-
| [https://lists.fedoraproject.org/mailman/listinfo/fedoramagazine-tips fedoramagazine-tips@lists.fp.o] || Reader ideas and opinions about what to write about in the Fedora Magazine (evaluate pulse of the community)
| [https://lists.fedoraproject.org/mailman/listinfo/fedoramagazine-tips fedoramagazine-tips@lists.fp.o] || Reader ideas and opinions about what to write about in the Fedora Magazine
|}
|}
== Meetings ==
The CommOps team meets '''weekly''' on '''Tuesdays at 17:00 UTC''' in '''#fedora-meeting-2'''. Meeting minutes are logged both with [https://meetbot.fedoraproject.org/ Meetbot] and via wiki articles outlining the meeting agendas (such as [[Meeting:CommOps_2015-12-01|CommOps meeting 2015-12-01]]). All meetings use the [[Template:CommOps_meeting|CommOps meeting template]]. You're invited to join us!
=== Meeting format ===
Meetings primarily follow the agenda outlined in the meeting plan on the wiki. This includes a ticket-based approach to handle the tickets in [https://fedorahosted.org/fedora-commops/ our Trac].
The following is a long-term goal for our how tickets on our Trac will work:
* Tickets that don't get requests for information responded to after 2 weeks become inactive.
* Tickets that are stalled for two weeks either get unassigned or can be renewed for an additional two weeks by their owner.


== Delegation ==
== 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.
One person, [[FPL|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. This requires broad participation across many teams and communities. A delegation, rather than an elected board, or other top-down style governance structure, would 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 and participation by non-voting delegates who want to be involved.


=== Delegations include ===
=== Members ===


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


== Operating Principles ==
== Operating principles ==


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


== Technical Strategy ==


* Use real-time communication channels and infrastructure when possible (Fedmsg, FMN, Zodbot, others)
== Technical strategy ==
 
* Use real-time communication channels and infrastructure when possible ([http://www.fedmsg.com fedmsg], FMN, Zodbot, others)
 
 
== Things we help with ==
 
=== Unified messaging ===
 
When someone asks the question, &quot;What is Fedora?&quot; to an existing community member, *everyone* should have at least a standard elevator pitch, whether you are a designer, engineer, or translator. Ideally, this will be informed by the Fedora Core Values and Mission, and developed in the open (similar to the Red Hat Mission Statement). Input from existing groups (such as Marketing and Design) will be needed.
 
=== Storytelling ===
 
Much in the spirit of [http://boingboing.net/ BoingBoing], the idea of &quot;Cover Posts&quot; are a target goal which can be generated from existing content and point to existing parts of Fedora to minimize the burden of &quot;publishing in yet another place.&quot;
 
Content that is highly designed and curated already (announce-list, Fedora Magazine) should get the &quot;greenlight&quot; to be published automatically, and others added to a curated content queue from the community by Zodbot, other mailing lists, [http://www.fedmsg.com fedmsg], and/or other means. This queue of curated content will help feed both the [Magazine|Fedora Magazine] (end-user focused content) and the [CommunityBlog|Community Blog].
 
Here are some places where you can find the latest news and updates about the Fedora Project, read articles, and keep in touch with the community that develops, supports, and promotes Fedora. You can also publish your own articles, share an experience with others, ask a question, and interact with the community. Some of the most well-known sites are the following:
* [https://fedoramagazine.org/ Fedora Magazine]
* [https://communityblog.fedoraproject.org/ Fedora Community Blog]
* [http://opensource.com/ OpenSource.com]
* [http://fedoraplanet.org/ Fedora Planet]
 
=== 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 an award) for team / subproject membership. The Badges ''design process'' is operating very well, but the Badges ''strategy process'' falls onto the [[Design|Design team's]] already full plate. It is our aim to help fix that.
 
=== Onboarding via Fedora Hubs ===
 
This is an existing effort with the momentum and full support of the [[Design|Design Team]] and a buy-in from the [[Infrastructure|Infrastructure Team]]. We do not have to create or recreate this wheel and want to support Hubs as the Community Operation team's official strategy.


== Meetings ==
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. This would include tools for folks working in [[Docs_Project|Docs], [[Marketing]], [[Design]], [[Ambassadors]], and so on, to help make it easier and enable them to bring new contributors on-board.


The CommOps team meets weekly on Tuesdays at 17:00 UTC in #fedora-meeting-2. Meeting minutes are logged both with [https://meetbot.fedoraproject.org/ Meetbot] and via wiki articles outlining the meeting agendas (such as [[Meeting:CommOps_2015-12-01|CommOps meeting 2015-12-01]]). All meetings use the [[Template:CommOps_meeting|CommOps meeting template]]. You're invited to join us!
See the [http://blog.linuxgrrl.com/2015/03/24/enabling-new-contributors-brainstorm-session/ proposal] and the [http://blog.linuxgrrl.com/2015/03/25/summary-of-enabling-new-contributors-brainstorm-session/ results] of the proposal.


=== Meeting Format ===
=== Metrics ===


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.
Because of the [http://www.fedmsg.com 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.


# Tickets that don't get requests for information responded to after 2 weeks, become inactive.
=== Wiki ===
# 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: ==
The wiki is aging. The wiki tries to be all things to all Fedorans. There are a number of initiatives happening: some are moving user documentation out of the wiki into a ''readthedocs.org''-style site, others say there is a <nowiki>{{old}}</nowiki> tag that is going to help us sift through content, and there are likely other initiatives too.


* '''Unified Messaging.''' It is my hope that when someone asks the question, &quot;What is Fedora?&quot; 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.
We'd like to do things automatically, such as generate User pages on the wiki (in the spirit of the Badges template) so that users don't have yet-another-place-to-edit.


* '''Curating a queue of &quot;stories.&quot;''' Much in the spirit of BoingBoing.net, the idea of &quot;Cover Posts&quot; which can be generated from existing content, and point to those existing parts of Fedora to minimize the burden of &quot;publishing in yet another place.&quot; Content that is highly designed and curated already (announce-list, Fedora Magazine) should get the &quot;greenlight&quot; 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?)
=== Internal communications ===


* '''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.
This is an ongoing and difficult problem, and we have come up with an approach, but it does resemble the 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.


* '''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: &quot;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.&quot; Proposal here: http://blog.linuxgrrl.com/2015/03/24/enabling-new-contributors-brainstorm-session/ and results here: http://blog.linuxgrrl.com/2015/03/25/summary-of-enabling-new-contributors-brainstorm-session/
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.


* '''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 <nowiki>{{old}}</nowiki> 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.
=== Code of Conduct and Diversity ===


* '''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.
This may make sense to fall under the CommOps 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.


* 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.
=== Voter turnout ===


* '''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.
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.


* '''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.
=== Release notes ===


* '''Release Notes'''. Each time Fedora makes a release, subprojects and teams provide updates and highlights. Helping to aggregate and publish that data takes a village, and CommOps is here to help. See: [https://fedoraproject.org/wiki/Releases https://fedoraproject.org/wiki/Releases] for details
Each time Fedora makes a release, subprojects and teams provide updates and highlights. Helping to aggregate and publish that data takes a village, and CommOps is here to help. See the[https://fedoraproject.org/wiki/Releases Releases] page for details.


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


== Interest Areas ==
== Interest Areas ==
Line 95: Line 140:
|[[User:Jzb| jzb]] ||  || X || X || X || X || X || X || X || X || X
|[[User:Jzb| jzb]] ||  || X || X || X || X || X || X || X || X || X
|-
|-
|[[User:Jflory7| jflory7]] || UTC-5 || X || X || X || || X || X || || X || X
|[[User:Jflory7| jflory7]] || UTC-5 || X || X || X || X || X || X || X || X || X
|-
|-
|[[User:bee2502| bee2502]] || UTC +5.30 ||  ||  || X || X ||  || X || X || X || X
|[[User:bee2502| bee2502]] || UTC+5.30 ||  ||  || X || X ||  || X || X || X || X
|-
|-
|[[User:cprofitt| cprofitt]] || UTC-5 || X || X || X || X || X || X ||  ||  || X
|[[User:cprofitt| cprofitt]] || UTC-5 || X || X || X || X || X || X ||  ||  || X
Line 106: Line 151:
|}
|}


== 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
== Toolbox ==
 
Already, the [[Infrastructure]], [[Design]], and other teams started developing tools to help drive community initiatives and aggregate metrics. You can also find a detailed listing of CommOps tools on [http://decausemaker.org/posts/commops-toolbox.html decause's blog].


{|
{|
Line 132: Line 177:
| Fedora Hubs || https://pagure.io/fedora-hubs/branch/develop || Modern, web-based Fedora activity center || Python || Hubs
| 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
| Fedmsg || http://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
| 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
Line 159: Line 204:
* [https://fedorapeople.org/groups/schedule/f-23/f-23-trans-tasks.html Fedora 23 Translation Tasks]
* [https://fedorapeople.org/groups/schedule/f-23/f-23-trans-tasks.html Fedora 23 Translation Tasks]
* [https://fedorapeople.org/groups/schedule/f-23/f-23-web-tasks.html Fedora 23 Web Team Tasks]
* [https://fedorapeople.org/groups/schedule/f-23/f-23-web-tasks.html Fedora 23 Web Team Tasks]
== Story Telling ==
Here are some places where you can find the latest news and updates about the Fedora Project, read articles and keep in touch with the community that develops, supports and promotes Fedora. You can also publish your article, share an experience with others, ask a question and interact with the community. Some of the most well known sites are the following:
* [http://fedoramagazine.org/ Fedora Magazine]
* [http://communityblog.fedoraproject.org/ Fedora Community Blog]
* [http://opensource.com/ Open Source]
* [http://fedoraplanet.org/ Fedora People]


[[Category:CommOps]]
[[Category:CommOps]]

Revision as of 05:35, 2 December 2015

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

Community + Operations = CommOps

How to contact the CommOps team
Mailing list: commops
Visit this link to sign up for the email list for the CommOps team.		 Chat: #fedora-commops[?]
This is where real-time chat with CommOps team members happens.

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

CommOps aims to address the area of community infrastructure by providing the tools, resources, and utilities for the different subgroups of Fedora to increase communication across the Project, collect and use metrics to direct and provide support where needed, and


Mailing 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!"
fedoramagazine-tips@lists.fp.o Reader ideas and opinions about what to write about in the Fedora Magazine


Meetings

The CommOps team meets weekly on Tuesdays at 17:00 UTC in #fedora-meeting-2. Meeting minutes are logged both with Meetbot and via wiki articles outlining the meeting agendas (such as CommOps meeting 2015-12-01). All meetings use the CommOps meeting template. You're invited to join us!


Meeting format

Meetings primarily follow the agenda outlined in the meeting plan on the wiki. This includes a ticket-based approach to handle the tickets in our Trac.

The following is a long-term goal for our how tickets on our Trac will work:

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


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. This requires broad participation across many teams and communities. A delegation, rather than an elected board, or other top-down style governance structure, would 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 and participation by non-voting delegates who want to be involved.

Members

  • The 13 Fedora Subprojects
  • The five Working Groups (three Editions, plus Base and Environments/Stacks Working Groups)
  • Any active and interested SIGS (opt-in)
  • Distinct web properties without a team / committee / group
    • ask.fedoraproject.org (?)
  • Other moving parts of Fedora not yet identified but needing representation


Operating principles

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


Technical strategy

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


Things we help with

Unified messaging

When someone asks the question, "What is Fedora?" to an existing community member, *everyone* should have at least a standard elevator pitch, whether you are a designer, engineer, or translator. Ideally, this will be informed by the Fedora Core Values and Mission, and developed in the open (similar to the Red Hat Mission Statement). Input from existing groups (such as Marketing and Design) will be needed.

Storytelling

Much in the spirit of BoingBoing, the idea of "Cover Posts" are a target goal which can be generated from existing content and point to 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, other mailing lists, fedmsg, and/or other means. This queue of curated content will help feed both the [Magazine|Fedora Magazine] (end-user focused content) and the [CommunityBlog|Community Blog].

Here are some places where you can find the latest news and updates about the Fedora Project, read articles, and keep in touch with the community that develops, supports, and promotes Fedora. You can also publish your own articles, share an experience with others, ask a question, and interact with the community. Some of the most well-known sites are the following:

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 an award) 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. It is our aim to help fix that.

Onboarding via Fedora Hubs

This is an existing effort with the momentum and full support of the Design Team and a buy-in from the Infrastructure Team. We do not have to create or recreate this wheel and want to support Hubs as the Community Operation team's official strategy.

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. This would include tools for folks working in [[Docs_Project|Docs], Marketing, Design, Ambassadors, and so on, to help make it easier and enable them to bring new contributors on-board.

See the proposal and the results of the proposal.

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.

Wiki

The wiki is aging. The wiki tries to be all things to all Fedorans. There are a number of initiatives happening: some are moving user documentation out of the wiki into a readthedocs.org-style site, others say there is a {{old}} tag that is going to help us sift through content, and there are likely other initiatives too.

We'd like to do things automatically, such as 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 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.

Code of Conduct and Diversity

This may make sense to fall under the CommOps 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.

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.

Release notes

Each time Fedora makes a release, subprojects and teams provide updates and highlights. Helping to aggregate and publish that data takes a village, and CommOps is here to help. See theReleases page for details.


Interest Areas

Name UTC Messaging Storytelling Badges Hubs Wiki Culture Metrics Voting Misc
decause UTC-5 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
jflory7 UTC-5 X X X X X X X X X
bee2502 UTC+5.30 X X X X X X
cprofitt UTC-5 X X X X X X X
keekri UTC+5:30 X X X X X X X
descientist UTC+5:30 X X X X X X X


Toolbox

Already, the Infrastructure, Design, and other teams started developing tools to help drive community initiatives and aggregate metrics. You can also find a detailed listing of CommOps tools on decause's blog.

Project Source Description Stack Interest Area
wordcloudbot https://github.com/decause/wordcloudbot Create pretty wordclouds from IRC meeting logs Python Storytelling, Metrics
5 Things In Fedora This Week (5tftw) Final Product: http://fedoramagazine.org/5tftw-2015-10-30/

Contributions: https://www.piratepad.ca/p/5tftw

 Weekly series by the Fedora Project Leader to sum up five things going on in Fedora community shared via the Fedora Magazine. CommOps team can contribute to this by finding the "Things" happening in Fedora, collecting one URL for the topic, and writing a maximum of five sentences describing it. - Storytelling, Wiki
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 http://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
Community Blog (CommBlog) https://communityblog.fedoraproject.org A centralized blog available to contributors to publish news, activities, or calls for help for the rest of the project. Useful place for getting the inside scoop of "what's happening" in Fedora. Note that the blog publishes in UTC. WordPress (PHP) Messaging, Storytelling

Fedora Program Management and Schedule Track

Retrieved from "https://fedoraproject.org/w/index.php?title=CommOps&oldid=429133"