On Wednesday 01 June 2005 04:06 pm, Chris Cannam wrote: > Good idea! Thanks. And blimey, what a lot of RFEs.
You can say that again. A good lot of them are really worth looking at too, if only there were more hours in the day. Glad I thought of it then, and you're welcome. > I don't agree with all your classifications of particular RFEs, but > that's OK -- so long as they're classified to something meaningful, > then when they get assigned to someone, that someone can always > reclassify. I don't agree with all my classifications of particular RFEs either, but none of this is chiseled in stone. I think it's a good start anyway. If we get this running right, users should be able to use it too, by looking to see what sort of suggestions got knocked down to the bottom of the pile, and what sort got the express train onto somebody's TODO list. In fact, we should probably publish a suggestion that they look through the thing and take all of that into account before posting anything new. > Where can we keep a record of the classification system for RFEs? We > had a similar one for bugs a while ago -- it was based on the > particular release schedule for the time, but the broad principles > would apply well enough at any time. We could do with having them > available for reference somewhere. It's a good question, and one I tried to answer myself last night. I don't see any good place to put it off hand. I agree that we should formalize it, and that we should also come up with a similar spread for the bugs. Keeping 5 as "unclassfied" is particularly useful, I'd say. The reclassificiation of bugs was aimed at the 1.0 release. I can see two ways of looking at that from here. One way to go is to just sort the thing into some kind of order irrespective of any particular release, with 9 being the most egregious problems, and 1 being the it doesn't build on Solaris 3 running on a food processor kind of things. The other way is to reserve the top one or two tiers for release planning use, and keep out of them at other times. I think I'd favor just running the same rules all the time. We didn't actually fix all of the "release critical" bugs before the last release anyway. None of this will ever be more than a optimistic best case look at the world anyway, I don't imagine, so I guess our priority at future releases should simply be to knock out as many of the top rated bugs as we possibly can. If they're sorted properly, that should be a pretty good target. I don't have the original rules handy, so here's a start on some new ones. Salt to taste, this is just off the cuff: 9 critical - crashes, build problems, and data corruption/bad behavior problems which impact core functionality for a large number of users (eg. starting without JACK crashes; someone forgot to commit the new Blurfl class and broke CVS; something broke to such an extent that data was either ruined forever, or had to be salvaged by manually hacking the XML; doing the wrong thing causes 300 error dialogs to pop up) 8 grave - repeatable crashes which can be worked around or avoided, and other very significant usability problems (eg. crash when inserting triplets this way, but you can still get them in another way; audio loops or the solo button or something similarly critical is broken badly) 7 serious - less significant usability problems, broken features 6 unused 5 unclassified 4 unused 3 important - this is a real bug, and we really should fix it, but unfortunately, it isn't going to get fixed anytime soon (eg. the grace note stuff) 2 minor - unrepeatable crashes and other random flake worth mentioning, but probably only useful to note because it might eventually offer a clue to unraveling a larger problem 1 nuisance - trivial complaints that are just barely on the bug side of the bug/RFE divide, and/or which shouldn't really have been submitted at all -- Michael McIntyre ---- Silvan <[EMAIL PROTECTED]> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ http://rosegarden.sourceforge.net/tutorial/ ------------------------------------------------------- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
