[meta-issue] We need to figure out what 'critical' means from now until code freeze

webchick's list looks about right to me - here's how I'd break it down personally:

Critical bugs should include webchick's list, plus performance regressions from D6, server-hosing bottlenecks etc. (but not performance features) , especially since we're in such a sorry state at the moment.

Really really stupid wtf usablity/design issues probably need to go here too since they can have has much impact as API-level bugs on actual users (in terms of support requests etc.).

These definitely aren't critical bugs:

- Things that are just awesome enough.
- Things that would be really nice to have. Even if it's really, really.

But i think they are critical tasks. Ones which are big API changes should get moved to Drupal 8 as slush turns to ice rather than demoted to normal. Opened #566306: Add 8.x to Drupal project version dropdown which would be the clearest way to deal with this.

Test coverage - those issues have a tendency to get out of date, as tests are added or changed with patches more often than added by themselves. I'd lean towards critical tasks there too - since that keeps it in the critical queue without flooding the active bug reports list (which will get busier when we have more people clicking around alphas/betas).

So summary:

Critical bug - has to be fixed before release. If it was found after release, it would have to be backported from D8 if at all possible.

Critical task - has to be fixed before code/slush/string/freeze/rc, but if it's not done before then it'll have to be fixed in Drupal 8, unlikely to get backported.

Normal bug - if we ship Drupal 7 without it, it'll be a shame. Candidate for backport from Drupal 8.

Normal task - cleanup, not going to get backported unless it's misclassified and was really a bug.

So, we need to clarify bug vs. task. normal vs. critical, and probably whether we have to do postponed vs. Drupal 8.

There is Priority levels of Issues, but I don't think it qualifies in the new code-slush period.

+1 to catch's list. I like the distinction between critical bugs and critical tasks -- I think that's the distinction we're looking for, between "critical == must fix, no question" and "critical == very very exciting and important but not actually broken".

We'll need some examples to make this clear. Let me propose a few:

• In general, a missing test is a "critical task": nothing is broken, but we really want to get the test in before Drupal 8.
• A white-screen-of-death bug that occurs because of a missing test is... a critical bug. The fact that the test which would have caught the bug is missing is part of the bug's issue.
• Many of the items on Dries' list will actually be classed as "critical tasks": They're really important -- so important that they will be worked on during the Time of Slush -- but technically they are not bugs and do not make it impossible to release D7.
• But some items on Dries' list are actual release-stoppers and must be classed as critical bugs.

I sense that there will be a lot of issue-by-issue debate on the last two points. But at least we will have a framework within which to hold that debate, so I agree that it would be great to get some guidelines into the handbook ASAP.

(webchick: once we've got an idea of what to say, I can make the handbook changes if you wish.)

+1 for catch's definitions.

@#5: There appears to be a simple solution to the possibility of Dries' list being debated. Given that we have definitions, Dries should classify them as bugs or tasks. By my count, there are currently 38 open items tagged as Favorite-of-Dries; and only 10 of those are currently marked critical. I don't want to make more work for Dries, but 10 items seems like a reasonably low number to look at.

I'd rather we kept Dries free for committing patches. IMO 'Favorite of Dries' just means 'I like this', not 'has to get in' - we should deal with the grey areas when they come up - since there'll always be new patches coming through which mess up any strict definition.

@catch: That's fine. However, webchick put Dries' list in her requirements. You included it in your comment (#2). Unless there's another Dries' list, then we've made it a requirement. If the tag has no (significant) meaning, as you state in #7, then let's make sure that there's no mention of anyone's personal list in the definition and/or examples. That seems to meet all of the needs, including leaving gray areas in the gray.

I'm still +1 for the actual definitions that catch proposed. (I'll go back to lurking now.)

Well Dries list is exceptions - so they get in whether bugs or tasks - but we should use the same criteria for determining which they are.

For me the crucial difference is that at various stages of a the code freeze, we'll be moving certain types of task to 8.x (other than writing tests, which is like a permanent code freeze exception since it doesn't change the runtime code base) - bugs we should only move to 8.x, once it's actually open for development. How soon things get moved to 8.x is where the arguments are going to be - but completely new features ought to start from next week, whereas a lot of API improvements/cleanup might stick around for the next month / 6 weeks.

Code freeze is on Thursday, I think we're done here.