-
Notifications
You must be signed in to change notification settings - Fork 670
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tickets updated with priority and severity #220
Tickets updated with priority and severity #220
Conversation
paulsputer
commented
Sep 30, 2014
- TODO: New entries appended to language files require updating
Really Nice! It's like looking at my own code. Changes I'd like to see:
|
Thanks, glad it's easy reading
The intention was to keep the UI clean for users who don't use them but it does feel as though it complicates the code far more than the value it provides... Lucene indexes them no matter the config, so it is purely for the UI. Happy to take them out to keep the code simple, as you say if they don't use them the defaults are pretty much invisible anyway. 2.1) I had thought of making the priority & severity enumerations project configurable but it looks like that would require far more changes than I wanted to do on this PR. Lucene indexes them as integers to maintain portability so this could be done at a later date if needed. 2.2) Similar to 2.1 but focusing on language, the strings are generated directly from the enum name, is there a way to disconnect the display name from the enum name?
|
Changes complete, the calculated approach for color indicators didn't display quite as nicely as I was hoping for so I've implemented them as a lookup table for easier tuning to human eyes. The hue range has been widened to include purple at the catastrophic end. Alpha fades out ticket on lower priorities to a minimum of 20%. Default priority/severity settings should look similar to ticket icons in current release. |
fd23ec1
to
6d16bc6
Compare
Cleaned pull request into one commit to ease identification of changes. Also updated to display priority icons. |
This is looking really nice. There are a few things I'd like addressed before I merge:
|
@gitblit +1 for color blindness awareness |
6d16bc6
to
2c8c5ec
Compare
Ok, hopefully we're getting closer now :)
|
+ Severity indicated via new character indicator and color of ticket icon on ticket list + Priority indicated via new priority icon and color on ticket list + Indexed as integers to provide sorting and maintain language neutral index + Colours and indicator text controlled through CSS classes priority-<x> & severity-<x> + UITicketTest created to generate tickets of all types to ease debugging
2c8c5ec
to
f9c78c0
Compare
@paulsputer I've made a friendly amendment to your CSS changes which you can find here or at the I've attached a screenshot of the results of this change. If you are fine with this adjustment I'll go ahead and merge. |
@gitblit yes that looks great! Maybe we could remove the text all together and just use the dots to avoid the translation issue? I didn't like using Ca, C etc but couldn't think of a more suitable alternative at the time, but the dots are clear, simple, and language neutral 👍 |
I pulled out the S# text and set the tooltip with the severity from Thanks for taking the time to implement this improvement. It's really great! |
@paulsputer I'm giving more thought to the severity levels and wondering what your take is. Priority = What should be done first? I recognize that Severity is a standard term, but it implies bug or something wrong. That doesn't necessarily correlate well with a task, enhancement, or maintenance. What about labeling this as Impact or Importance, instead?
Language like that might be generally more useful in triaging. A task or an enhancement doesn't really have severity - but they do have importance or impact which might be orthogonal to priority. What do you think? |
@gitblit yea it gets rather tricky with the wordings. Priority is the easy one, but severity/impact could have very project specific terms. From a technical perspective I had hoped to abstract these further to allow them to be customized on a per-project basis but I felt the change was already on the large side for one PR, and at this stage my focus is on creating a tool to migrate from Trac to Gitblit without losing this vital information. From what I could gather the project settings uses JGit config API, which doesn’t appear to provide access to a group of KVPs so this may be a bit more involved. The terminology I’ve used here is based on ISO14971 which builds upon the more generic ISO16085 for risk management. Both refer to “probability of occurrence” and “severity of consequence” where the project specific weighting of both together determines the risk and if it is acceptable. All the standards specify that there should be a project specific description for each category, so there is scope for flexibility without going to the extreme of some ticket systems that do away with names all together and just have numbers, though there could be benefits in doing that internally in the code. Importance is an awkward one as it becomes too similar to priority. My first instinct with severity/impact is that it is the difference between an engineering term vs a business term so I’m not so convinced that renaming provides the answer. I see what you mean though about the different ticket types, I think the main question in either case is how it should be interpreted for the task/ticket being categorized. Maybe the best way forward will become clearer as we use that new feature :) |