BLOCKED: How do I denote the "urgency" and "importance" of an issue beyond "priority-1"?

[nelsonic]

Context

Last month I opened an issue dwyl/cid#11 that is a "Blocker" to the progress of all other work
(both our Product(s) and Client work). We MUST get it done as the highest priority and the longer we go on without it being complete, the more "re-work" we will have to do in future. This is basically a "cash bonfire" we need to resolve and the longer we ignore it, the more money it is costing us. 💸 🔥

To be clear this issue is not about money, but if we lose sight of what issues are costing us cash every minute that passes, we will literally go bankrupt", the dream of "dwyl" ends and everyone will have to find another job. 😞 If we put out this "fire" we can save some of our "runway".

Question

So my/the Question is: how do I/we make it clear to everyone in the team that NOTHING else is more important than getting this "one thing" done?

How do we systematically communicate with everyone in the @dwyl "core" team and wider community (where applicable) that getting a specific issue "unblocked" is the difference between success and failure of the organisation/company?

Proposal: BLOCKED Label

I propose that we start by creating a new label called BLOCKED
(intentional ALLCAPS as the person applying the label is "screaming for help!")

This label should only be applied when the person has exhausted all other options and has made a concerted effort to do everything they can to describe the problem they are facing.

When the BLOCKED label is applied it should trigger an alert to call everyone's attention.
everyone in the "core" team should attempt to help in solving the issue.
If a corresponding StackOverflow issue is opened for it, upvote it so it gains exposure.

Wider Discussion

GitHub is definitely not a good "company" management system. (this is not news to anyone)
GitHub is fine for tracking the issues of a software project but it's inadequate for tracking development across multiple organisations for example when we have a dependency fields that need to be updated before the client feature can be completed, it's difficult to visualise this dependency in the "milestone" or "project board".

The only reason we started using GitHub to collect the information/stories/tasks/discussions
for @dwyl was because our "core" product is code/software and GitHub is the most popular platform (by far) for collaborating on open source code. I still feel that it's (way) more important to have a single source of truth and avoid fragmenting project information across multiple communication systems.

Priority-0 ?

@iteles and I have informally (verbally) discussed the idea of having a priority-0 label.
The reason we have resisted doing this is simple: the escalation to p0 would simply "bump" the whole priority system up a level and we would end up with 10 p0 items and back in the same place we are now ... 🙄 (also, the irony of the lack of transparency of a verbal conversation is not lost on me, despite my insistence that all discussions should be had on GitHub for traceability/accountability, many still happen on Gitter or in-person and never relayed onto our "single-source-of-truth" ...)

Dependency Visualisation

We need a single dashboard for visualising what everyone in the team is currently working on, what they will be working on next and what issues are blocked across all teams/orgs/clients/projects.

The longer we leave this the more likely we are to run out of cash.

Longer Term

In the near future we will have a Gantt Chart dwyl/product-roadmap#8 to help us visualise the order/priority of issues/stories/tasks so that it's immediately clear to everyone what needs to be done now, next or never. (some things are so low on the priority list - because users aren't requesting them and they will deliver little value while cluttering the UI so - they should simply never get done if we are prioritising correctly, and yet often they get "actioned" because of a lack of clarity... there is way to much at stake for us to lose focus and do low priority tasks!)

[iteles]

Linked to dwyl/hq#349

My hypothesis is thatBLOCKED may be used across the board by anyone who is blocked in their own project and will quickly lose impact.
In an open source focused organisation like ours, anyone who has a question or has their own work blocked when using one of our open source modules is likely to use it.

Using something like dwyl-priority, priority-0 or priority-nuclear would denote a bit more seniority and disavow people from the notion that it can just be used at will.
Until that issue is assigned to someone and has an in-progress label on it, nothing else is looked at. And should the person accountable for that task require help, that also takes priority.

This label will not be available to client projects, only to dwyl open source packages/work (which may of course be related to critical work on client projects if these match up).

It may also be advantageous to start off with the rule that organisation-wide, there can only be one BLOCKED (or whatever we call it) at any given time, until we feel there is an absolute need to expand this number. This can be written into the label description so it's obvious immediately at the point of applying the label.

[iteles]

Created a BLOCKED label given the priority here, name can be changed if this isn't working later on.

Thoughts on this very much welcome!

[nelsonic]

Inês, this is a valid hypothesis. 🤔

However only people who are members of the organisation are able to add labels so we would not have random chancers using our Google Sheets Tutorial which often has Noobs making "do my work for free" requests.

If someone who is a collaborator adds the BLOCKED label we will have @dwylbot comment linking to our "workflow" which will explain the exact circumstances when the label can be applied.
The ONLY circumstances when it Can are:

1. @dwyl the company (or one of our customers) is losing money while the issue remains unfixed.
2. Development of a @dwyl product/service or client app is "blocked" until the issue is fixed
3. There is a security issue, though I feel we should have a separate "channel" for "responsible disclosure" of security related issues rather than people posting public GitHub issues ...

The @dwylbot comment will give the person a few minutes to re-think if they "crying wolf".
After that "cooling off" time, @dwylbot should email both Inês and Nelson (and anyone else in the intersection of the "contributor" list and "core" team)

I can think of fewer than 10 instances in the (4 year) history of @dwyl where I would have applied this label.

priority-0 does not give anyone any indication that the whole company is Blocked until the issue is resolved and again, it will almost inevitably result in a "priority escalation".

At present there are 56 open priority-1 issues:
https://github.com/issues?q=is%3Aissue+is%3Aopen+label%3Apriority-1+user%3Adwyl

This is a clear indication that:
A. we are not systematically working on the most important issues/tasks.
and/or
B. the priority system is not clearly understood by the team.

Of these issues zero are assigned to me.
https://github.com/issues?q=is%3Aissue+is%3Aopen+label%3Apriority-1+user%3Adwyl+assignee%3Anelsonic

But if a BLOCKED label was applied to anything I would know that regardless of who an issue/task is assigned to, I need to look at it.
Whereas if a priority-0 is applied but someone is assigned I assume that the person is actively working on the issue ... or is that a bad assumption unless it has in-progress?

All of this would be a lot easier for everyone to understand if the "workflow" was clarified /github.com/dwyl/contributing/issues/109

[nelsonic]

@iteles does the assignment to me signify agreement with this label suggestion/idea?
If so, should we document it's usage guidelines?

[iteles]

@nelsonic The label has been available and in use since the beginning of the year #87 (comment)

Is there anything else you'd like to add to the above ahead of it being documented?

[nelsonic]

@iteles if you feel the above is sufficiently clear, then no (for the time being).