Our use of workflow::blocked label
Currently there are a few ways to indicate an issue is blocked in some way and is not to be worked on until the blocking event(s) have been satisfied.
We have seen use of the following ways/combination of ways to indicate a blocked status. The aim of this issue is to formally decide which ways we want to use them in growth and why. The closing of this issue should likely be a doc update to our handbook page.
- Use
is blocked by
relationship to another issue. - Use workflowblocked
- documented in handbook - https://handbook.gitlab.com/handbook/product-development-flow/#build-phase-2-develop--test
- Add some sort of wording to the description to indicate blockage.
Proposal
Strive to use is blocked by
with extra reasons why in the wording of the description. There will be edge cases where workflowblocked still needs to be used, but they should be few and analyzed as to why it is needed upon use. See below 'Reasoning' for more thoughts on that.
Example of using the above proposal w/o leveraging workflowblocked
Reasoning
- Using workflowblocked requires manual action to remove and thus can be forgotten, possibly causing delays in implementation. Leaving another workflow label on the issue along with a blocking relationship should cover indicating something is blocked.
- Using workflowblocked can be seen as an anti-pattern. If something is blocked there is likely a reason and that thing that is blocking could/should likely be documented in an issue. If it is only one part of an issue that is blocking the implementation, then perhaps that is a signal the blocking piece should be its own issue.
- Using the application provided
is blocked by
:- Leans more strongly into our Dogfooding value.
- Automatically resolves when the
is blocked by
relationships are closed and promotes better handling/closing of issues.