Information
ID: 250
PHID: PHID-TASK-6jgsfzeilsppesu4yr7k
Author: Patrick
Status at Migration Time: open
Priority at Migration Time: Normal
Description
Let’s take for example T203, T207, T31.
Those are currently priority “normal”. But what do we use the priority field for at the moment anyhow? Mostly it’s set to “normal”.
Can we developers use it perhaps the priority field for some kind of “high means, should be done as fast as possible” [because it would otherwise block a point release or otherwise make someone else’s task harder than necessary]? For easy tasks such as “add package xyz with signed tag to repository”?
What I find not useful on most bug trackers is users bickering about priority “high means important”. By that logic, we would never get to work on the priority “normal” tasks.
So I hereby suggest extra fields:
severity: Describing the impact. For example T203, T207, T31 could be declared that they might have a “high” impact. I.e. those could significantly increase security. Alternatively we could call it “impact” rather than “severity”.
difficulty: Based on our current team and/or time requirements we estimate, we could also say for example T203, T207, T31 have difficulty “high”. Not sure if the difficulty field would be any useful or rather deterring?
Other options:
we keep leave it as is
we also remove the “priority” field
something else
Any opinions?
Comments
HulaHoop
2015-03-25 01:05:36 UTC
Can we developers use it perhaps the priority field for some kind of “high means, should be done as fast as possible”
Yes, that’s how I always looked at it.
And also the Severity and Difficulty fields make alot of sense as they all represent different but important properties of a ticket.
Difficulty level shouldn’t be a deterrent. Lets say someone experienced reads a ticket you describe as hard, they can readjust the difficulty as easy once they claim the task.
troubadour
2015-03-25 22:19:06 UTC
I am not sure either if a difficulty field would be useful.
An extra field reflecting the impact a task could have on the security (or usability…) of Whonix looks meaningful. Now “severity” could be misleading, the highest severity being easily interpreted as the highest priority, which might or might not be the case.
Or what about cleaning up and organizing the tags in a hierarchy? At the moment, a lot of tags link to nowhere, and some of them are probably not needed, like python
or bash
, or they seem created for a single task (the title should be self-explanatory). Some other are dead but could be useful in this perspective (security
, usability
).
We could order the tags (mandatory order):
distribution/version: whonix
whonix 10
qubes-whonix
and so on, (all
).
importance: normal
high
blocker
category: development
maintenance
update
bug report
bug fix
or something like that
sub-category: general
security
usability
research
and probably more.
This is just a raw suggestion (don’t know if it’s achieavble in Phabricator). It’s hard to cover every possible subject with predefined tags, take it as a general idea for a better readability of the tracker. And it would be nice to have a summary in the form of a road map, as in Tails (https://labs.riseup.net/code/projects/tails/roadmap ).
WhonixQubes
2015-03-27 05:18:51 UTC
I generally like the idea of these extra ticket attribute fields.
But I question the experience of using the difficulty
field somewhat.
If we create a ticket about an issue where we may not be the person – or only person – to work on resolving it, then how do we know how “difficult” something is?
What is easy for one of us might be hard for another, so our own personal bias of rating difficulty may make it not useful for others.
Regarding the other fields…
Priority would maybe be better served with a more time-related term, like “Urgency”?
I do like the idea of generally filtering for Severity/Impact too.
Patrick
2015-03-30 21:26:11 UTC
Added a new field Impact
which defaults to Needs Triage
, but can also be set to Normal
, High
or Low
. All these words and options are arbitrary, i.e. it would be simple to rename it to something else and to add additional options such as Lowest
, Highest
or whatever. For new tasks it defaults to Needs Triage
. Don’t worry, if you don’t know, just leave it as is. It’s not something we need to go crazy about. For existing tasks, when you edit them, you’ll add this field.
Priority rename to Urgency:
Good idea, but phabricator does not support renaming default fields. (asked on IRC.) We try a feature request against phabricator. But until it’s not possible, let’s use “Priority” as a synonym for “Urgency”.
Sorting tags:
Good idea. Phabricator doesn’t have a feature to automatically enforce some order. Doing it manual seems like a lot work. (I am not opposed if one wants to do it, but I guess no one would step up.) We try a feature request against phabricator.
Deprecating tags:
Yes, we can get rid of less useful tags such as bash
or python
that aren’t used consistently. (Adding bash
and python
wherever it’s involved seems tiresome.)
difficulty:
Might indeed not be that useful. Some projects use integer fields for estimated hours
and actual hours
. But as long we are not counting hours for any purpose (which adds overhead by itself), I think we don’t need these.