Tracking important issues

[Matt Caswell]

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.

Matt