We should have four priorities not three (introduce a new 'major' priority)

Seems to make sense to me. :)

Basic project management advises you to have an even number of priorities, or all your issues will be classified using the median one.

Agreed.

I thought there was a setting for the issues priorities, but I didn't find it.
If this is the case, then it is only possible to open a feature request for project_issues.module, or add custom code inside drupalorg.module; between the two choices, I would prefer the first.

I agree that four priorities are better than three; it would then be better to have a global setting to change the priorities of an issue, in the same way it is possible to change the issue components, or the issue statuses.

this sounds like a good idea.

Wierd, thought I commented already but - definitely agree with this. There is one differentiating factor at least for when I mark issues, is that critical issues are so big that almost no one will be able to use it, where as major would be say 60% - thats still a large amount of people, but a very different criteria on which we should focus.

What D7 has learned me, is that most critical issues are mere major bugs. But not actually functionality that is so broken it can't be used at all.

#175555: Add custom Priority Levels

Can't decide if this issue should be "postponed" until the other is fixed, or just call this duplicate. I explain the legacy + technical problems in detail at the other issue, so please read there.

catch opened #714728: New 'major' priority but I think that's really duplicate with this issue. There's no reason to have 3 issues for this. There are only 2 things: add the functionality to project_issue to make this possible (that's #175555: Add custom Priority Levels which chx and I are working on), and a d.o-specific issue about how to use the new feature for our workflow. Re-posting what catch wrote:

#175555: Add custom Priority Levels and #669048: We should have four priorities not three (introduce a new 'major' priority) are working towards a new 'major' priority for core. So that the criticals queue doesn't get polluted with non-broken stuff, but major issues don't get lost in the sea of 'normals'.

I think we need to discuss how to actually apply this to the core workflow, and don't want to derail those issues (which are generic ones against project*), so here's a new issue. Re-posting my comment from there:

---
I just asked webchick in irc what the rationale for this is, and I think I get it - it's much better than having 'critical' issues moved to normal just to get the release out quicker, 'cos normal issues can get lost very easily amongst all the others.

However, I think deployment of this absolutely needs to be accompanied by an update to the contributors issue count block - so we have a 'major (count)' link alongside critical.

As we gear up for release, there are two places you have to look at the moment - 1. critical issues 2. Pending bugs - because people often post critical bugs as normal bugs, which then sit there for a week while nobody looks at them. Adding 'major' to this list means there's three places to check - because we need to look out for mis-classified 'major' bugs which are actually release blockers, and if there's not a handy link to them, I guarantee we'll release Drupal 7 with some stupid issue in it which will require a 7.1 within a matter of days. Look at the security issue which was fixed on the day D6 was released if you've forgotten how crazy it gets. And as a community we have a habit of reclassifying things at the last minute to get things done quick, that's going to be so much easier to do with a major priority.

Also apologies for the off-topic rant here, but I don't see an actual issue to add 'major' for core anywhere, so this was the best bet.
---

Yup. Once we agree on the criteria for what's major vs. normal, etc, we need to:

A) Update http://drupal.org/node/45111
B) Communicate this change to the community:
B.1) devel list email
B.2) planet post
B.*) other?

And yeah, definitely want to add this to the contributor links. However, for that, there's a bit of a tangled mess in drupalorg module. See #704376-6: Invalid HTML generated due to check_url() not used in URLs being output

Cheers,
-Derek

Curious if this will be the issue where the distinction between Normal, Major and Critical will be discussed, or if there is a separate issue for that discussion. I have posted a discussion on g.d.o. Drupal 8 accessibility bug priorities
, which may contribute to the distinction from an accessibility perspective.

I think that Critical issues should be those that break functionality, however, I think that this needs to be looked at from both the technical "the machine is broken" and the user "can't use the working machine" perspectives.

#175555: Add custom Priority Levels is now done and committed to project_issue in CVS. It will be deployed to d.o hopefully Monday morning PDT.

So, this issue is active again to discuss/coordinate the other aspects of the change for d.o: namely policy and documentation. Can one of the champions of this change please propose some new text explaining major issues for use on http://drupal.org/node/45111 (and mention any other edits that need to happen to that page for this change to make sense)?

Also, calling volunteers to help with the code for the "Contributor links" block. See #704376-6: Invalid HTML generated due to check_url() not used in URLs being output for a list of issues that need some lovin' (in addition to that issue itself). Patches welcome.

Thanks,
-Derek

I missed this last update.

Here's a crack at 'major', and rewording the others to keep them in line. I'll also note that our standards have got quite a bit higher since these were last updated, can't remember the last time node creation or block module was completely fubar, and we have loads of bugs marked critical which are nowhere near as serious as node admin filters being broken....

Critical
When a bug renders a system unusable. Possible examples from core are the inability to create content, blocks not displaying, inability to upgrade between versions and security vulnerabilities. These are to be fixed immediately because the software is not usable at all or is unusable without significant risk. In Drupal 7 this also applies to test failures: we have a policy of 100% pass rate for tests, so failing tests block all other development.

For Drupal core, a major version (like Drupal 6.0 or Drupal 7.0) won’t be released until all critical bugs are fixed. For point releases (like Drupal 6.1 or Drupal 6.2), critical bugs won't hold back a release if a security fix is needed. In contributed projects, it is up to each maintainer how they would like to handle the critical status and whether that will stop them from creating a release.

Major
An issue with a system which may have significant repercussions, but which does not render the system unusable overall. For example a PHP error which is only triggered under rare circumstances or which affects a small percentage of overall users. These issues will be prioritized in the current development release, and for backport to stable releases where applicable, but do not block an individual point release. This status also applies to tasks or features which consensus has agreed are important (such as improving performance or code refactoring) but which are not functional bugs.

Normal
Bugs that just affect one piece of functionality. An example here might be the category filter not working on node admin screen. This is self-contained and does not impact the overall health of the software.
Minor
This is most often used for cosmetic issues that don't inhibit the functionality or main purpose of the project, such as correction of typos in code comments or whitespace issues.

Wording looks good to me.

I think parts of 'Major' and 'Normal' should be switched.
An error

which is only triggered under rare circumstances or which affects a small percentage of overall users

would in my opinion be more likely a 'Normal' issue than THE major admin screen not working (the example for a 'Normal' issue).

In general a very good improvement, though!

What I was thinking of there was issues like #89181: Use queue API for node and comment, user, node multiple deletes. /If/ you have a lot of comments or nodes, and /if/ you trigger the deletion of them all in one go (by cancelling a prolific user), then you'll end up with your database in an inconsistent state due to apache timeouts. If this bug happens to you, it's a lot worse than the filters on the admin/content screen - because it's not just a case of updating the code and it magically working again - you either have to live with the inconsistency or try to re-trace from a backup. However, we've survived several releases with that issue in core, and it's extremely rare that accounts get deleted which aren't spammers on 99.999% of websites, so there's not much reason for it to be a release blocker. This might need a more concrete example though, although that ones a bit long and complex to put into one sentence.

I agree the admin/content screen being broke is a bit too serious for normal, would be good to find a generic issue which is a bit less central.

Here's a rework of that sentence from major:

For example a bug which may cause data inconsistency, but which is only triggered under rare circumstances or unusual configuration.

And let's exchange 'content admin' for 'watchdog' in normal.

Since this is ready to deploy apart from these bits afaik , going to mark this to 'needs review'. I also think we can live without the major count in contributor links at least for a bit - they should be near the top of the other queues anyway hopefully, and easy to find via issue search.

FYI: #175555: Add custom Priority Levels is still not working right on d.o. As is often the case, things that work fine in local testing don't actually work on the d.o infrastructure. :/ So, while I appreciate the recent burst of activity in here for documentation and other stuff, we're still not done over at #175555 yet, so this isn't just blocked on documentation.

+1 subscribe etc. to the general concept.

Trying to shave of some words here and there without losing information (from 307 down to 262 words):

### Critical
When a bug renders a system unusable (not being able to create content or upgrade between versions, blocks not displaying…), and security vulnerabilities. These bugs are to be fixed immediately. In Drupal 7 this also applies to test failures: we have a policy of a 100% pass rate for tests, so failing tests block all other development.

Major versions of Drupal core (like 6.0 or 7.0) won’t be released until all critical bugs are fixed. For point releases (like 6.1 or 6.2), critical bugs won't hold back a core release if a security update is needed.

In contributed projects, it is up to each maintainer how they handle the critical status.

### Major
For issues which have significant repercussions, but do not render the whole system unusable. For example a PHP error which is only triggered under rare circumstances or which affects only a small percentage of all users. These issues are prioritized in the current development release and backported to stable releases where applicable. Major issues do not block point releases.

Also major are tasks or features which consensus has agreed are important (such as improving performance or code refactoring) but which are not functional bugs.

### Normal
Bugs that affect one piece of functionality. For example the category filter not working on the watch dog screen. This is a self-contained bug and does not impact the overall health of the software.

### Minor
Most often used for cosmetic issues that don't inhibit the functionality or main purpose of the project, such as correction of typos in code comments or whitespace issues.

It sounds weird to have a major release mentioned in the critical priority description, and then the word major reused as the new priority (which does not have anything to do with the major releases)...

I was going to try and re-write the description of critical to not use the word major... but major is an official word for what critical issues block. http://drupal.org/node/93999 says "[Major] is an integer that indicates what major revision of the contribution the release is from..."

So I wont try.

And I guess this is still blocked by #175555: Add custom Priority Levels

Also, I'm tagging a few of the D7 critical issues as "priority-major" in preparation of being able to move them to the major priority when it is ready on d.o

Reopening now that #856850: Enable major priority for issues is in and we have a "major" priority (woohoo!) - we need to fix the docs over at http://drupal.org/node/45111

The text in #20 looks pretty good to me - perhaps we should just put that up (since the status is live already) and refine from there?

I changed the page http://drupal.org/node/45111 to add the text in #20. Refine as needed!

I made a small (but significant) correction to the ending paragraph, changed

Tasks and Feature Requests should never be marked “critical”. They should always be “normal” or “minor”.

to

Tasks and Feature Requests should never be marked “critical”. They should usually be “normal” or “minor”.

as per the "major" priority definition.

It's been about a month since the last comment; marking as fixed.