EOSERV Bug Tracker > Bug #230: More Specific Priority For Features

Bug #230: More Specific Priority For Features

More Specific Priority For Features
ID #230
Submitter Hacker_Alex
Product eoserv.net
Severity Feature Request
Status CLOSED, WONTFIX
Submitted 22nd Mar 2013
Updated 24th Mar 2013
Hacker_Alex Submitter 11 years, 41 weeks ago

How about add a priority for features from 1-4 so that features that are really useful or needed are given a 4 while ones that may not be that useful or needed at the time a 1.

Then the features would be ordered based on this priority so that the right ones get read and dealt with first.

Comments

Hacker_Alex Submitter 11 years, 41 weeks ago

[DUPLICATE]

Sorry, my net was being attacked so I didn't think it made it the first time.

Apollo 11 years, 41 weeks ago

There is a basic priotiy in place. Critical should be dealt with first, followed by normal, and lastly trivial. Some users may view their requests of more importance than others, but when it comes down to it, functionality should always be given priority.

Hacker_Alex Submitter 11 years, 41 weeks ago

Well I mean if you switch to the feature request tab, there are no priority options. But yes I see what you mean.

Plasmastar 11 years, 41 weeks ago

Feature requests have NO priority...it's a want/desire, and critical bugs and things that cause problems usually get done before ANY requests.

Plasmastar 11 years, 41 weeks ago

This is a "Bug Tracker" after all, not a "Wish List". It has its priority system, which is pretty standard in other systems. For this reason, I find this request to be ridiculous.

Sausage Developer 11 years, 40 weeks ago

Most other large bug tracking systems have a priority field, however, the number of requests is currently small, and the projects managed are small, non-commercial, and not done to any kind of schedule. I'd much rather have a version target system (EOSERV 0.6.0 released when and only when quests are implemented, and the server is otherwise stable, i.e., no outstanding CRITICAL bugs), which is how I've worked so far when deciding a release was ready.

Bug #37 covers a method for the community to vote up feature requests and bugs that are affecting them most. I don't think the requester, or even me, is the best judge of which features have a higher priority than other requests.

A single number can't really capture the difference between things like the addition of a very important, simple, admin command; and something like the wedding system, and I expect that between tagging large requests to future versions, and voting up of smaller requests, would make a bug priority system completely redundant.

Updated Status to CLOSED, WONTFIX

Add Comment

Please don't post unless you have something relevant to the bug to say.
Do not comment to say "thanks" or "fix this please".

Please log in to add comments. EOSERV Bug Tracker > Bug #230: More Specific Priority For Features