On Wed, 28 Mar 2018, Simon McVittie wrote: > On Wed, 28 Mar 2018 at 12:17:37 +0200, Andreas Tille wrote: > > I think "wontfix" is exactly the feature of the BTS that was invented to > > solve the problem I described. The bug is not closed and remains listed > > - so everybody is free to ignore that tag and close the bug. > > Is this how most people interpret wontfix? I'd usually interpreted it as > an indication of policy rather than priority: "I acknowledge that this > is a bug, but it isn't going to change, even if you provide a patch".
The documentation of wontfix[1] currently allows for both interpretations, and I think both are OK, especially if that helps maintainers filter out bugs that aren't ever going to be fixed. I think that the use of wontfix+help can disambiguate between the two interpretations. For example: 1) wontfix: This bug isn't going to be fixed; don't bother helping. 2) wontfix+help: this bug requires too much effort to fix, so I won't be working on it, but patches will be accepted. 3) help: I want to fix this bug, but I'm blocking on assistance from someone But that's not documented at all. Would a sentence: "Use the help tag in addition to the wontfix tag if you would still accept a patch that fixed this issue." to the wontfix description be useful? 1: https://www.debian.org/Bugs/Developer#tags -- Don Armstrong https://www.donarmstrong.com I've had so much good luck recently I was getting sated with it. It's like sugar, good luck. At first it's very sweet, but after a while you start to think: any more of this and I shall be sick. -- Adam Roberts _Yellow Blue Tibia_ p301
