#20041 closed defect (bug) (wontfix)
Disable "Priority" and "Severity" fields for new users
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | WordPress.org Site | Keywords: | |
Focuses: | Cc: |
Description
When a new user comes to report an issue in trac, they always seem to overestimate the severity of their problem.
I guess this is normal human psychology, but it makes the field less useful for everyone else.
So, I propose that only bug gardeners be allowed to set these fields, similar to how the milestone field works.
Change History (5)
#3
@
13 years ago
What I noticed is that the Priority field is barely used. The really high-priority tickets just get marked as task (blessed)
. Because of that, I just ignore it and look at Severity.
Aside: To test what non-gardeners see, log in as Scribu in a separate browsing window. Trac permissions are case-sensitive, so it won't think you have special permissions beyond any other authenticated user.
Now that's a hack, if I ever saw one.
The severity is the seriousness of the ticket in the eyes of the reporter. The priority is the seriousness of the ticket in the eyes of the project. Generally, severity is a judgment of how bad a bug is, while priority is its relationship to other bugs.
We already disable priority, based particularly on this interpretation. I think it's important to allow the reporter to reflect, at least initially, how severe their bug is. For example, if data is lost due to the bug, that's a major bug in terms of severity, at the very least. But if it's an edge case, it may be a very low priority. And we might end up lowering severity if we discover that it was was exacerbated by what the reporter was trying to do.
Aside: To test what non-gardeners see, log in as
Scribu
in a separate browsing window. Trac permissions are case-sensitive, so it won't think you have special permissions beyond any other authenticated user.