On Jan 20, 2008 10:42 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote: > After some months of tracker operation, I'd like to discuss one aspect > of the tracker schema: priorities. > > Each issue has a severity and a priority. The severity is assigned by > the submitter, defaults to normal, and indicates how serious the issue > impacts him and the community. > > The priority is assigned by a developer (and cannot be set by > a "mere" user), and indicates how quickly this issue must be processed. > The priority is initially unset, requiring a developer to perform screening. > > It appears that developers rarely set the priority, leaving the issues > formally unscreened. > > So what should we do? Leave things as-is? Drop the notion of priority? > Change our process to make sure priorities do get set (and honored)? In my dream schema, severity becomes difficulty (e.g., easy, medium, hard, expert), type goes away, and priority changes to be release-based (e.g., RFE since those can occur whenever, next minor release, next micro release, immediately, etc.). I think priority should more be tied to our release cycles than this generic notion of importance. If it is important, we should try to get it done by a certain release. Let's have that fact directly reflected by the tracker. -Brett
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4