I think we agree, or I think we think we agree we have a definition of Blocker in that those issues would be blocking a specific release from proceeding - i.e. we must do something about those issues before a release can go ahead and they become a mechanism to help us not forget them.

For me as the default priority level is Major and Blocker has a definition we don't have much room for prioritisation in between and the field is called "Priority" so a Critical tends to be something with higher priority than the default priority.  I tend to move things to Critical to get them about the large backlog of Majors to identity what I think is the next priority.

Although we do have lower priorities available to us in Jira we don't use them enough to give us space to prioritise tasks.



On Thu, Jan 18, 2024 at 10:15 PM Brian Stansberry <brian.stansberry@redhat.com> wrote:
Can we do some housekeeping of the open 'Critical' issues in WFCORE and WFLY?

1) Can the assignees and relevant component leads go through them and change the priority for any that aren't truly critical?

2) Simultaneously, we can have a discussion here of what we want 'Critical' to mean going forward. My 2 cents is it needs to have more of a meaning of 'Priority' (which is what the field is), i.e. it gives a clue as to what needs to be worked on next. And less of a meaning of 'subjective importance'.

My sense is right now we have a lot of things where 'Critical' means someone thought it was 'Important' but there is no corresponding priority to get it done. At some point that calls into question whether it's truly critical.

For 1) above I'm not asking that we have a big discussion and then people can review issues. I'm looking for a quick triage to clean up things where the experts decided 'nah, that's not really critical.' Just try and get rid of some noise so it's easier for new Critical items to stand out.

Also, in a preview of coming attractions, I expect later this quarter we'll kick off a more general JIRA housekeeping initiative. This is something that Alessio Soldano suggested last year, and it's sorely needed, but I didn't have time to get anything going. But it's a New Year, and my New Year's Resolution is to tidy this up.

Best regards,

Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
Privacy Statement: https://www.redhat.com/en/about/privacy-policy
List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message/HKWM4XZDORD2MUVILQ3DVBOAQ6NHTXAC/