[Plan] Use tags for release blockers, not priorities [#2738795]

Problem/Motivation

There's been an assumption that any critical issues block a Flag 8.x alpha release, majors block a beta release. As Martin and several others have pointed out, however, that criticals would still crop up even after we enter the alpha/beta cycle.

Proposed resolution

Instead of relying on issue priority, we rely instead on tags:

alpha blocker
beta blocker
Release blocker

Issues tagged as an alpha blocker will block the first alpha release, or the next alpha release if an alpha release has already been made. Beta blockers block the first or next beta release, and release blockers block the first or next full version release.

This separates priority from releases, which hopefully frees up the perpetual dev cycle logjam in which we currently exist.

Remaining tasks

Review issues, reprioritizing them and adding appropriate tags.
Determine if current issues prevent an alpha release or not.
Coffee.

User interface changes

None.

API changes

None.

Data model changes

None.

Comments

Comment #1

1 June 2016 at 15:19

socketwench created an issue. See original summary.

Comment #2

socketwench CreditAttribution: socketwench at FFW commented 1 June 2016 at 19:25

Title:

Use tags for release blockers, not priorities

» [Plan] Use tags for release blockers, not priorities

Comment #3

joachim CreditAttribution: joachim commented 25 September 2016 at 16:18

alphas and betas are releases, so I'd rather '1.0 blocker' than 'Release blocker' as a tag name.

(though we already use that: https://www.drupal.org/project/issues/search?projects=Flag&project_issue...)

I like this proposal, but my main problem with tags is that it's impossible to find them if you don't know them! So if we introduce these, we'd have to create links to their search results on the project page.