CommOps/Metrics Ideas

From FedoraProject

Jump to: navigation, search

Till date, we have worked on metrics like

  • Understanding Impact of Attending Fedora Events like FOSDEM
  • Diversity Metrics
  • Year in Review Metrics for differents parts of Fedora Project.
  • Metrics for Fedora Election cycle
  • Community Blog Metrics
  • fedmsg related metrics

Possible future metrics ideas (as discussed in Community Operations workshop in FLOCK 2016) -

  • Release parties metrics
   - Information about impact at release parties (since they are more closer environment than a large conference)
   - Gaps between times when claimed (for peaks) with city names for different release party dates
  • Community metrics
   - By Geographical diversity
       # of contributors of specific areas in project (filtering FAS groups by countries / regions)
  • Globalization metrics
  - what countries are actively translating to their language (or making small attempts to begin, as an indicator for #help)
  - Other Zanata / Localization metrics

Some open metrics related tickets can also be found on the CommOps Pagure Instance.


Community ideas

Have some ideas for metrics you'd like to see collected or generated? Feel free to edit this page and add some bullet points with your own ideas or wishes for things you think would be helpful, useful, or informative.

  • Metrics about the number of the fedora community. For ambassadors, for example, it is very difficult to answer a question like "what is the size of the Fedora community ?", and people want to know, by numbers, if fedora has a big community or not. It can be done via fas quering, and filtering with activity (with the question of the time: since when a contributor is considered as "inactive" ?). For more info, metrics about field (globalization, coding, sysadmin...) could be great, allowing new users to find fields with needs of contributors.
  • Metrics of downloads. How many copy of fedora are downloaded every day ? Wich version/spin/lab is the most popular ? It will help focusing on what is really usefull. Ideally, metrics on package, and their downloads. Again, it will help us to target the package that really need to be maintened when a mass-oprhaning is done (with a non-responsive maintener for example).
  • Metrics on this…
  • Or on that..