Branden Robinson writes ("Re: Disputes between developers - draft guidelines"):
> 6. Bug report etiquette
>
> Sometimes bugs are reported inappropriately; likewise, sometimes
> -maintainers close bug reports inappropriately. Bug reports are `todo
> -list' items for the whole Project; they should be closed when there is
> -rough consensus that the whole system is working as well as it could.
> +maintainers close or change the severities of bug reports
> +inappropriately. Bug reports are "to do list" items for the whole
> +Project; they should be closed when there is rough consensus that the
> +whole system is working as well as it could.
I'm not sure the issue of severities needs dealing with explicitly
here. In fact, your suggested changes seem to spill over from dispute
resolution into general rules for the use of the BTS. I don't want to
address that here.
In particular, I note that you seem to be grinding your axe about the
issue from Bug#97671. Surely you must agree that that axe is not best
ground in this document ? Why don't we wait and see what the BTS
admins say; it seems to me that it's their decision (as it's a process
question and they're the appropriate delegates).
But, in any case, I think I largely disagree with you about the
specifics. That's why I'm CCing this mail to [EMAIL PROTECTED]
and debian-project.
> For example, here are some examples of situations where a bug report
> should not be closed:
...
> -* The bug was reported; the maintainer felt immediately that it was a
> +* A bug was reported; the maintainer felt immediately that it was a
> spurious bug report of some kind, and closed it, but the submitter
> disagrees with the explanation and has reopened the report for
> -discussion. The matter should be debated until both Developers are
> -happy.
> +discussion. The matter should be debated until both parties are
> +happy. In the meantime, the maintainer can use the "wontfix" tag in
> +the BTS to indicate to interested parties that a resolution is not
> +being actively worked on. (In some circumstances, the "help" or
> +"moreinfo" tags may be more appropriate, depending on the nature of
> +the disagreement and specifics of the situation.)
I disapprove of the `wontfix' tag, in principle. It seems to me that
there are three possible relevant situations:
* There is a deficiency in the package, but perhaps the maintainer
does not have time or expertise to fix it. The bug should remain
open, maybe with `help'.
* There is no deficiency in the package. The bug should be closed.
* The question is currently disputed. `wontfix' is not an appropriate
tag here, since it implies a decisive outcome, rather than an
ongoing process [1]. I wouldn't mind `disputed' tag; that would
indicate the need for continuing discussion.
Note that the BTS is not a good place to document commonly reported
mistaken (or controversial) bugs. That should be done in package
documentation in the usual way. If this is done correctly then
repeated _useless_ bug reports should be generally avoidable -
although you can reasonably expect (and indeed it would be
appropriate for) people to file new reports if they have substantial
new arguments etc.
[1] In particular, I think `wontfix' tends to go against this advice:
Be flexible; try to avoid categorical statements such as `I will never
implement that'. There is no shame in being convinced, by good
arguments, to change your mind, even if you have just been vigorously
propounding the opposite view !
> +* A bug was reported; both the maintainer and the submitter agree that
> +it's a defect, but disagree in their interpretations of the
> +definitions of bug severities. The bug should be left at the severity
> +determined by the package maintainer, but the report should not be
> +closed. The parties should discuss their disagreement within the bug
> +report until some mutual agreement can be reached. Note that the
> +Release Manager may regard a bug as "release-critical" (or not)
> +irrespective of its severity in the BTS.
We can't put anything about this in until the BTS admins have decided
who is responsible for bug report severities, and this is where you're
prejudging #97671.
Until then we could have:
* A bug was reported; everyone agrees that it's a defect, but
disagree what severity should be assigned. The bug should be left
open at the severity determined by the package maintainer or release
manager. The parties should discuss their disagreement within the
bug report until some mutual agreement can be reached.
which is neutral on that question (ie, fudges it).
> +Under no other circumstances should you get into a back-and-forth with
> +a package maintainer, changing the state of a bug in the BTS. If
> +the maintainer of the package against which a bug is filed makes a
> +change to that bug report which you disagree, you should *discuss* the
> +matter with them but *not* immediately undo their action in the BTS,
> +except to reopen the bug to stop it getting lost. If you are unable
> +to reach a conclusion through constructive discussion, you should ask
> +for outside help with resolving your dispute, as outlined above.
I disagree with putting this here in that way. I don't want to
document in this disputes advice file what the policy is about
ownership of BTS state. The BTS admins should do that.
Ian.
