#5122 closed enhancement (wontfix)
Add a difficulty field to tickets
Reported by: | Owned by: | Jonas Borgström | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | ticket system | Version: | |
Severity: | minor | Keywords: | |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
It would be really useful if trac tickets could have an additional "difficulty" field.
The rationale is described in detail in this Lennart Regebro's blog entry : http://blogs.nuxeo.com/sections/blogs/lennart_regebro/2006_09_13_triage-bugs-in-an-open-source-world
" What would be even more helpful in an open source situation would be a difficulty field. The experienced bugfixers can look through the bugs, note severity and difficuly, and then not fix the easy bugs. It's tempting to fix the easy ones because quick fixes are satisfying and you feel productive. But if the wanna-be contributor can fix bugs marked as "easy" and understand and fix them, then we have not only gotten a new contributor, we have saved time for the experts. "
Attachments (0)
Change History (6)
comment:1 by , 18 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 18 years ago
TracTicketsCustomFields functionality is great. I didn't know it before, thanks. This will solve an immediate problem in the trac system I administer.
But still, I think that adding a "difficulty" field is needed for people just to think about this notion. Adding such a field in mainstream trac would evangelize good practices and all libre software projects using trac will benefit from it.
But if you are not convinced, I won't get mad, just a bit sad.
Thanks for trac anyway !
comment:3 by , 18 years ago
I agree with eblot. While the ideas exposed in the blog article has some merits, the difficulty of a task is probably something even more difficult and subjective to rate than the other fields, besides a few obvious cases.
Better express the notion of difficulty "in plain text" and flag the easy contributions in a special way.
Btw, we already have a few contributor-oriented keywords:
- documentation - things to document
- helpwanted - some moderately sized task, quite self-encapsulated, that is looking for a volunteer (similar to Subversion's bite-sized tasks)
- see TracTicketTriage#Keywords for more
… not saying those were efficient up to now to trigger a lot of contributions ;-)
follow-up: 5 comment:4 by , 18 years ago
Replying to anonymous:
But if you are not convinced, I won't get mad, just a bit sad.
It's not really about being convinced or not, but rather defining what is useful for most users and what may be less useful and that could eventually clutter the UI.
This is a highly subjective matter, but I think the difficulty field falls into the second category. The more fields a bug tracker exposes, the less the users incline to use it.
Fortunately, Trac allows some customization of the UI with the help of the custom fields, so I believe this is the way to go for now. There might be many requests to add such a field and users are always welcomed to give their feedback here.
follow-up: 6 comment:5 by , 18 years ago
Could it be possible to expose a custom difficulty field base solely if you are logged in?
OR have a list of developers for which the difficult field appears or them to have the option to set when triaging.
just a few thoughts.
You can use custom fields to achieve this, see TracTicketsCustomFields.
I don't think it is worth adding this extra field in mainstream Trac.