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

# Context

Last month I opened an issue https://github.com/dwyl/cid/issues/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_**"](https://youtu.be/PYuzqNSPDsI) 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](https://en.wikipedia.org/wiki/Gantt_chart) https://github.com/dwyl/product-roadmap/issues/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!_)