RFR: triageweb

[Brennan Ashton]

==Primary Contact==
Name: Brennan Ashton
Fedora Account Name: bashton
Group: Bugzappers
Infrastructure Sponsor:

==Secondary Contact==
Name: John Poelstra
Fedora Account Name: poelstra
Group: Bugzappers

==Project Info==
Project Name: TriageWeb
Target Audience:  Bug Triagers, Developers, Quality Assurance. To some
extent this might include the general public, as a way to see how
fedora is managing bugs and developing.
Expiration/Delivery Date (Required): 06/06/2009

==Description/Summary==

TriageWeb is a turbogears application that automatically queries and
processes bugzilla bugs to generate user defined reports on triage
related activities.
 Base reports include:
* Number of bugs of each work flow status changed for Fedora product
as a whole over time
* Number of bugs of each work flow status changed for component D over time
* Number of bugs of each work flow status changed for component group
E over time
* Number of bugs of each work flow status changed by user F over time
* Number of bugs of each work flow status changed by user group G over time

Data is presented in both tabular and graphical displays (these lack
some UI changes for customizing queries):
Here are some samples:
* http://bashton.fedorapeople.org/personalstat.png
* http://bashton.fedorapeople.org/mainlist.png

Tabular data can be sorted and date ranges can be selected.
Graphical data can have data ranges limited, as well as statuses.

Refreshes of bug data would be updated at the end of each day, as
processing the few hundred bug reports changed each day take a fair
amount of time.

FutureFeatures (not so far away):
* Will integrate with FAS so that users can store there queries for
later,  they also  can create custom user and component groups here.
* Send weekly reports on rawhide bugs, and well as top reporters,
triagers, and bug closers.
* A Look Into Rawhide
--This is an idea that I discussed with jlaska, the idea is that this
is a work bench that people can visit to see how we are progressing
with blockers as milestone are reached.  This would also include a
section that more effectively then bugzilla, shows the top duplicated
bugs, so that developers and traigers spend less time having to sort
through 50 dup bug reports filed when component X failed today.
*Create a section where FAS groups and users can create a monitor
goals that are compared to standard queries.  What this means will be
partially determined by feedback on what people use and how they use
the core features.

==Project Plan==
* Currently the project is locally hosted and is in a nearly usable
state already.  There is still one known bug in the scripts that pull
data from bugzilla, this just requires going back and tracing what
types of bugs cause the error and then fixing the script to process
these correctly.
* In a week or as soon as the RFR is granted, people are wanting to
start testing the app, the triage group is especially eager to start
using it, this will give me significant feedback as to what needs to
be changed or added.
*After this has become stable, I will request that the application be
pushed live as a release application.
* I need to start looking into optimizing the database queries and
format, as the application is database intensive.
* Once the core app is running smoothly I will start to integrate and
develop the tasks outlined in FutureFeatures in the order that I have
listed them. The development of these features will mostly take place
during the months of June and July, and then continue at a slower pace
during the school year where the focus will be primarily maintenance
and bug fixes as I will have more limited time.

==Specific Resources Needed==
*Webspace to run the turbogears application
*Ability to create cron jobs for daily data fetching scripts (no more
then an hour each day)
--When rebuilding the database to introduce feature requests a script
will take around 10-12 hours.  This should happen only very
occasionally, and does not take much processing power as most of the
time is spent doing xmlrpc communications with bugzilla.
*Database space to store metrics data as well as user preferences.
The metrics data right now in a sqlite db is only a few MB, I would
not expect it to grow beyond 50MB even with heavy user usage.  I have
no preference between MySQL and postgresql
*Package wise all dependencies are in fedora already, with the
exception of traigeweb itself.
--Python
--TurboGears
--python-turboflot
--python-fedora
--python-bugzilla
--python-sqlalchemy
--python-numeric
--httpd
There may be a few others, but that should be a very representative list.

==Goals==

The point of this project is to give the traige, packaging, and QA
groups some new tools so that they can better measure there status as
well as monitor critical areas.  This should especially help with the
development cycles once some of the FutureFeatures have been
introduced. This also allows fedora to better recognize the commitment
of some members in the community who spend there time in the drudgery
of processing, reporting, and solving bugs.

==Other Notes==
* I am looking for someone in the sysadmin-web group to sponsor me.
* I have filed this as ticket #1314
https://fedorahosted.org/fedora-infrastructure/ticket/1314


Thank you for the consideration,
Brennan Ashton