4:14 p.m.
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
4:40 a.m.
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(a)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(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)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...
11:57 a.m.
What you describe sounds fine; particularly since it matches how I think
about it. :-) In practice it often doesn't seem to be used that way though,
i.e. things are the 'next priority' for years.
If we come to a consensus that that's what Critical means, perhaps we just
need periodic threads like this to ask people to triage and update.
There's a bit of a tension between "Critical because I want it to stand out
for me/my component team" vs "Critical because it needs to stand out for
the WildFly community as a whole". I think that's ok, as long as we keep a
balance. Too much of the former and people not intimately familiar with
numerous details have no sense of project priorities. Too much of the
latter and important things end up getting lost in the sea of Major.
On Fri, Jan 19, 2024 at 4:40 AM Darran Lofthouse <darran.lofthouse(a)jboss.com>
wrote:
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(a)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(a)lists.jboss.org
> To unsubscribe send an email to wildfly-dev-leave(a)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...
>
320
days inactive
321
days old
2 comments
2 participants
participants (2)
-
Brian Stansberry -
Darran Lofthouse