Page MenuHomePhabricator

extra fields in phabricator for severity and difficulty as alternative for priority
Open, NormalPublic

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?

Details

Impact
Normal

Event Timeline

Patrick raised the priority of this task from to Normal.
Patrick updated the task description. (Show Details)
Patrick added projects: phabricator, Whonix 10.

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.

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).

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.

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.