Skip to content
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

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

Open
nelsonic opened this issue Jan 18, 2019 · 6 comments
Assignees
Labels
discuss Share your constructive thoughts on how to make progress with this issue help wanted If you can help make progress with this issue, please comment! please-test Please test the feature in Staging Environment and confirm it's working as expected.

Comments

@nelsonic
Copy link
Member

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. 💸 🔥

image

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

@nelsonic nelsonic added help wanted If you can help make progress with this issue, please comment! question A question needs to be answered before progress can be made on this issue discuss Share your constructive thoughts on how to make progress with this issue labels Jan 18, 2019
@iteles
Copy link
Member

iteles commented Jan 18, 2019

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
Copy link
Member

iteles commented Jan 18, 2019

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

image

Thoughts on this very much welcome!

@nelsonic
Copy link
Member Author

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
image

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
image

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

@iteles iteles added please-test Please test the feature in Staging Environment and confirm it's working as expected. and removed question A question needs to be answered before progress can be made on this issue labels Sep 21, 2019
@iteles iteles assigned nelsonic and unassigned iteles, SimonLab, RobStallion and Cleop Sep 21, 2019
@nelsonic
Copy link
Member Author

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

@iteles
Copy link
Member

iteles commented Sep 21, 2019

@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
Copy link
Member Author

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

@nelsonic nelsonic changed the title BLOCKED: How do I denote the "urgency" and "importance" of an issue beyond "priority-1"? BLOCKED: How do I denote the "urgency" and "importance" of an issue beyond "priority-1"? Oct 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Share your constructive thoughts on how to make progress with this issue help wanted If you can help make progress with this issue, please comment! please-test Please test the feature in Staging Environment and confirm it's working as expected.
Projects
None yet
Development

No branches or pull requests

5 participants