Changing the meaning of the "Critical" and "Blocker" priority in Jira

[vmassol]

@MichaelHamann

My understanding was (but I didn’t search carefully) that the current definition of Blocker is that we cannot release when there is a blocker.

Until now the time-boxing aspect has always taken precedence over a Blocker issue, except when we can fix that issue by delaying only by 1-2 days (we accept a small delay to time-boxing), and exceptionally by 3 days and in this case, we usually send a proposal to skip the RC (or agree on the xwiki chat). Example: Skiping 11.10RC1 release).

@MichaelHamann

At least my intent wasn’t to change the definition of a blocker issue with this vote, my assumption was that this is basically the current definition of a blocker issue, sorry for not making this clear.

Ok thanks for the precision. There are still consequences so let’s be more clear Hence my proposals to clarify.

@MichaelHamann

Could you point me to our current definition of a blocker issue?

I don’t think we’ve written one. I’m sure it was discussed on the chat + on the old mailing list but I haven’t found a place on xwiki.org.

@MichaelHamann

Thus, I believe it is justified to put them on the next roadmap and not delay them further.

That’s a definition of a Blocker, not of a Critical

We define the next roadmap only at the end of the month (when the RC is released). We can use “Critical” to indicate “Candidate for a Blocker in the next roadmap”. I still feel that there are critical issues for which we will need more than the next release to fix because of lack of time. And marking them as major would loose the information that we need to work on them ASAP.

Thx