On Mon, Mar 19, 2007 at 09:12:40AM -0300, Gustavo R. Montesino wrote: > 1. Query BTS according to paramaters given by the user. It could filter > the bugs by maintaner, uploader, package, usertags, tags, etc. Display a > list with bug number, title and tags to the user. > 2. The user may select one of the bugs. The user would be then able to > do the following on the selected report: > * See the full bug report, followups, etc > * Follow-up to the bug (launch the mail client with the right headers) reportbug-ng already does something like this. Have you looked at that program? > * Change the bug tags (generate and send a control mail with the > choices made by the user) > * Search the upstream BTS for similar bugs [...] Philip Kern worked on this for last year's SoC, but I'm not sure if the code actually ended up working and I can't remember where it was now. :-/ The best I can find is some mock-up screenshots at: http://lists.alioth.debian.org/pipermail/soc-coordination/2006-August/000058.html Personally, I find triaging mostly involves grouping rather than followup -- ie, the process is look at all the bugs, group related ones together into a bloc (by what area of the code they impact, how important they are, whether there's anything that can be done about them yet, etc), and then choose a group and do detailed followup/resolution on those bugs. Would it make sense to focus on the tagging aspect (either with the standard tags or usertags) so that your program just makes it really easy to set tags so maintainers can get a good idea of the state of their package (and share that idea through the use of tags), and fire off reportbug or a web browser for following up or reading bug logs? Cheers, aj
Attachment:
signature.asc
Description: Digital signature