ParticipationMetrics/roadmap

From MozillaWiki
Jump to: navigation, search

This page is no longer being actively maintained. For current information about participation metrics see the Contribution Dashboards page.

this is a DRAFT document

Roadmap for Participation Metrics

The goal of the Participation Metrics module is to develop, monitor and analyze metrics relating to participation in the Mozilla project.

This includes tasks such as:

  • determining which questions are most important to ask (how many people do X?)
  • determining what data is relevant to answer these questions
  • designing and operating a system to generate the requested data
  • analyzing the resulting metrics
  • notifying appropriate people when participation starts to change significantly
  • assisting various groups to understand and use the metrics to strengthen participation
  • produce periodic report/analysis of participation metrics

The initial team includes Asa Dotzler, Daniel Einspanjer, and Ken Kovash.

This is not an entirely new function for the project and the early stages of this effort will attempt to re-create, programatize, and then build on some of the ad-hoc participation reporting that's been happening for more than a decade. This draft roadmap is intended to describe the efforts of the team for the next ~1 year.

Phase 1 - Firefox+Gecko code contribution report

  1. Determine which of or combination of a)patches b)lines changed c)kb changed d)reviews, d)other is best measure for code-ish contributions
  2. Build a mechanism for distinguishing Mozilla paid staff (employees and contractors) from other contributors
  3. Ensure that our infrastructure allows for pulling in other organization lists for future reports.
  4. Create the specialized databases that will make for much simpler querying than we have in Bugzilla today.
  5. Ensure that this mechanism can be easily extended to include other (beyond Gecko and Firefox) code areas for future reports.
  6. Design and deploy a code contribution dashboard with most compelling information breakdowns (fe. modules, releases, calendars, components, front-end vs. back-end, etc.)
  7. Evangelize dashboard and iterate based on feedback from dashboard users.

Phase 2 - Request form (Bugzilla component?) for for custom code contribution reports and one additional report delivered

  1. TBD how to prioritize requests.
  2. TBD if or how much to extend infrastructure/platform specifically for custom reports
  3. Deliver at least one report for a not-Firefox code project (f.e. Thunderbird, SeaMonkey, Fennec, Bespin, etc.)

Phase 3 - Self-serve code contribution reports/dashboards against any existing infrastructure.

Bugzilla allows quite a bit of reporting today, however, the interface is difficult and getting many kinds of data out of Bugzilla can be difficult. We should have simple Web UI for querying the new participation-specific database(s) so that anyone can benefit from the work we've already done at this point.

Phase 4 - Support at least one non-code participation area with a similar participation or engagement dashboard (f.e. Marketing or QA)

The intent here is to add a non-code participation area where the data will still be drawn from systems we maintain or can easily connect with. Easiest would be Bugzilla since we'll already be building reporting on those data sets.