User:Dmose:Simple Metrics
In brainstorming, it very quickly became clear that there are a lot of metrics that could potentially be useful to track to help us get and keep people more engaged in our development process. In the interest of starting small and iterating quickly, I propose the following:
Contributions
We care about contributions. The hope is to use this to notice when individuals' contribution numbers go up or down so that when there are significant changes, we can ask contributors specific questions, such as what motivated the change, and if they're contributing less, what it would take for us to interest them in contributing more.
I want to start by tracking the number of patches landed in mercurial per person per month, in large part because landed patches are an extremely leveraged way to contribute. Over time, I expect a more general "contributions per person per month" metric would make sense, including some or most of:
- addon link with ui-review request (design)
- bugzilla change (qa)
- comment on bug assigned to self (dev)
- getsat response (support)
- checkin-needed push (dev)
- mailing list post
- forum post
- wiki post
separate list of possibilities specifically for devs from Standard8:
- Patches submitted (maybe with indications of re-submission) and review requested on
- Patches reviewed
- Comments submitted
- New bugs submitted
Contributors
New contributors per month
Reviews (for both MailNews Core and Thunderbird products)
If someone goes to the trouble of writing a patch, submitting it for review, and then the review doesn't happen in a timely manner for whatever reason, this can be extremely demotivating. As a result, I think it's worth focussing some energy here. The most interesting metric, I suspect, is number of open reviews. Secondarily, average time for r+ / r- to be granted over the last month could be helpful too.
It could be interesting to be facet and/or correlate these numbers with each of patch size, requestor, requestee, bugzilla component as well.