Tracking important issues

[Tomas Mraz]

On Mon, 2020-10-05 at 10:00 +0100, Matt Caswell wrote:
> 
> On 04/10/2020 15:22, Kurt Roeckx wrote:
> > On Wed, Sep 23, 2020 at 08:51:28PM +0200, Kurt Roeckx wrote:
> > > Hi,
> > > 
> > > I would like to have a system so that we can tag issues as
> > > important. But I think they fall in a few categories:
> > > - Features for the next minor/major release (so 3.1 or 4.0)
> > >   that we find important. I've created a new milestone for that:
> > >   https://github.com/openssl/openssl/milestone/18 (Post 3.0.0)
> > > 
> > >   We've also had a Post 1.1.1 milestone, but that seems to be
> > > just
> > >   things that didn't block the 1.1.1 release, maybe some more
> > >   things can be moved over.
> > > 
> > >   I suggest we do not add all feature requests to the new
> > >   milestone, so that we can have some kind of overview.
> > > - Features we want in before beta 1: The 3.0.0 beta1 milestone
> > > - Bugs that need to get fixed before the 3.0.0 release: 
> > >   currently using the 3.0.0 milestone
> > > - Important bugs that affect the stable releases. I've started
> > >   tagging bugs that have "triaged: bug" also with the branches
> > >   that are affected. But that doesn't say how important it is.
> > >   I have 2 proposals for that:
> > >   - Create a milestone for them, like 1.1.1-stable. In cases we
> > >     have multiple supported branches, we can add for instance a
> > >     3.0-stable and use the oldest branches that's a affected
> > >     as the target. This would at least match what we do now
> > >     with the "3.0.0" milestone.
> > >   - Create a label for the severity. I'm not sure we need things
> > >     like "severity: minor", but it might be useful too.
> > 
> > So I've created the "severity: important" label, and started
> > tagging some issues with it.
> 
> We should define some criteria for what constitutes an important bug.
> Everyone always thinks the bug they found is important because it
> impacts *them*. But what makes something important for the project?.
> Perhaps something about the number of users likely to be affected, or
> likely to cause interoperability issues, etc.

IMO whether interoperability is affected is not really criteria on its
own. What should matter is:

1. pervasiveness - i.e. how many users are affected
2. the actual severity - i.e. is the bug breaking affected
functionality completely or it is just an intermittent problem
3. availability of workarounds

Unfortunately it is hard to evaluate the first criterion in our case as
it will also be a subjective matter - I do not think we have a database
of all our users with the functionality they use. :D

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]