#93: Review options to reward key QA contributors
--------------------------+-------------------------------------------------
Reporter: jlaska | Owner: jlaska
Type: enhancement | Status: new
Priority: major | Milestone: Fedora 14
Component: Wiki | Version:
Resolution: | Keywords: retrospective
--------------------------+-------------------------------------------------
Comment (by jlaska):
This is a large task ... and I haven't done a great job of actively
updating this ticket with progress. The bad news is that I don't have
tons of time to develop scripts and automation to support this task. The
good news though, is that there are some rough tools to get a basic idea.
My current understanding of the Fedora QA metrics landscape is listed
below. Anyone is welcome to grab a topic and expand/correct as needed.
1. '''Lists''' - The [
https://fedoraproject.org/wiki/EKG EKG]
project is
pretty straight forward. It scrubs the mailing lists and provides
information on the list contributors. I'd love to adjust this a bit,
first into something I'm more comfortable with (python), and second to
adjust the output slightly. Perhaps listing top 15 contributors, then top
15 contributor domains. Finally, maybe also listing top 15 most active
threads? Anyone interested in helping?
* Next steps ... adjust the EKG reporting to break down the
contributors according to the criteria above.
2. For '''wiki''' contributions, I
[
http://jlaska.wordpress.com/2010/11/08/fedora-qa-special-thanks/ blogged]
about a way to scrub text out of our wiki test matrices. Since then, I've
also discovered that mediawiki as an API that can be used to query for
additional data. I've written a few sample scripts that grab data from
the
fedoraproject.org wike (thanks to
[
https://bugzilla.redhat.com/show_bug.cgi?id=654007 python-
simplemediawiki] and [
http://www.mediawiki.org/wiki/API the mediawiki API
docs]).
* Next steps ... I did find a limitation with some of the API. I'd
like to ask mediawiki for a list of recent contributors in different
namespaces (e.g. QA:, Test_Results: etc...). Unfortunately, the mediawiki
method (see
[
http://www.mediawiki.org/wiki/API:Query_-_Lists#recentchanges_.2F_rc
recentchanges]) only provides the last 500 wiki changes. We'd need to
lobby for increasing the default configuration value to record more than
the previous 500, and likely implementing some local EKG-like caching of
data for later review.
3. '''Bugzilla''' ... I have some old scripts I use to provide
data about
how many bugs are reported, VERIFIED, CLOSED. I'd love to extend this to
provide another top-15 list of most active components, most active
triagers, most active reporters, most duplicated bugs. Some of this
information already exists, or is presented by bugzilla. So it may just
be a matter of directing folks to the right places.
* Next steps ... My scripts currently rely on direct database access to
bugzilla. That won't fly for folks outside the firewall. Some of what
I'm doing will need to be explored using [
https://fedorahosted.org/python-
bugzilla/ python-bugzilla]. Again, anyone interested? I'll be happy to
provide the outline of the data I'm grabbing now.
4. '''Bodhi''' ... I have no way to discover+recognize who our
most
active proventesters are. This needs to be addressed.
* Next steps ... I understand that the next major release of bodhi will
have support for extracting this type of information. Is there a staging
instance we can explore the query options against now? Is the upcoming
support available for review?
5. '''TRAC''' ... I don't currently keep track of TRAC
contributions.
I'm aware there is a tool called [
https://fedorahosted.org/offtrac/
offtrac] that can query a TRAC instance for details.
* Next steps ... more exploration using
[
https://fedorahosted.org/offtrac/ offtrac] is needed.
--
Ticket URL: <
https://fedorahosted.org/fedora-qa/ticket/93#comment:1>
Fedora QA <
http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance