| 1 |
On Monday 01 August 2005 02:07, R Hill wrote: |
| 2 |
> Alec Joseph Warner wrote: |
| 3 |
> > Donnie Berkholz wrote: |
| 4 |
> >> |
| 5 |
> >> Are you having a tough time filtering out enhancements in your queries |
| 6 |
> >> or something? I don't understand how feature requests could possibly |
| 7 |
> >> interfere with anything besides other enhancements. |
| 8 |
> >> |
| 9 |
> > |
| 10 |
> > Many of the enhancements aren't marked as such, |
| 11 |
> |
| 12 |
> Then they should be. ;) There's nothing wrong with reclassifying your |
| 13 |
> bugs to make it easier to manage them. The features are there exactly |
| 14 |
> for this reason - so critical bugs don't get drowned out by less |
| 15 |
> important bugs or enhancement requests. I guess it doesn't really |
| 16 |
> matter, but it would have been just as easy to set the severity of these |
| 17 |
> bugs to min or enh rather than close them, and then they would still |
| 18 |
> show up on a simple search. |
| 19 |
|
| 20 |
Several people have asked why the available bug attributes don't suffice. |
| 21 |
The reasons are quite simple: |
| 22 |
|
| 23 |
1) Feature requests won't be addressed any time soon. |
| 24 |
|
| 25 |
It was suggested that closing the bugs as LATER will cause more duplicates |
| 26 |
and effect more work. I deferred (not closed!) 150 feature requests at least |
| 27 |
a third of which were duplicates. Because feature requests are not being |
| 28 |
addressed, they are piling up and users are not able to find duplicates |
| 29 |
with the bugs being open anyway. However, publicizing that feature requests |
| 30 |
have been put on hold has had the desired affect. There have been no new |
| 31 |
requests this past week. |
| 32 |
|
| 33 |
2) Every bug change has to be dealt with at least twice. |
| 34 |
|
| 35 |
I try to monitor bugs via the emails sent as much as possible. With the |
| 36 |
amount generated by new feature requests and the numerous "+1" posts on |
| 37 |
existing requests, it is simply not feasible to parse the incoming mail |
| 38 |
without making at least two passes. Here, I can hear people suggesting |
| 39 |
that I just /dev/null the email and monitor bugs via bugzilla. My answer? |
| 40 |
Opening listing 100+ bugs (that's assuming the bugs were properly categorized |
| 41 |
(which they are not) - there is actually about 300 bugs open other than the |
| 42 |
150 feature requests closed) as well as the bugs is a slow painful process |
| 43 |
on a 32000bps connection. |
| 44 |
|
| 45 |
3) To be able to utilize bug mails beyond notification. |
| 46 |
|
| 47 |
I've written a simple script to create a report of what bugs have changed |
| 48 |
and how many times within a set period. I'm posting the results to the |
| 49 |
portage mailing list in order to try and fish out some fresh blood. Having |
| 50 |
these reports littered with feature requests means that the important stuff |
| 51 |
that is causing users problems is hidden between all the "oh wouldn't it be |
| 52 |
lovely" bugs. Yes, this has also been successful already. There's been |
| 53 |
patches posted on various bugs that actually fix the root cause of the |
| 54 |
problems outlined. |
| 55 |
|
| 56 |
4) Less user frustration. |
| 57 |
|
| 58 |
The two most frequent comments at the moment are "is anybody looking at |
| 59 |
this?" and "it's been over a year!" Users knowing what's going on and |
| 60 |
especially finding that their minor bugs are starting to gain some activity |
| 61 |
can only be a good thing. |
| 62 |
|
| 63 |
I could figure out some more reasons if it's really necessary, but the past |
| 64 |
week has shown that the path chosen (even if there is some better path) is |
| 65 |
not a bad one as things are working out well thus far. |
| 66 |
|
| 67 |
-- |
| 68 |
Jason Stubbs |
Archives