This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Use of the different bug resolutions has been somewhat inconsistent between editors and the meaning of different resolutions is occasionally unclear to commenters. It would be good to document a shared meaning for the resolutions, since their natural meaning in the field of software may not be equally clear when applied to technical specifications. See also bug 9283.
Strawman resolution: Suggest the following use of bug resolutions (which largely matches existing practice. FIXED - Accepted or partially accepted. Spec was changed. Editor's resolution and diff link are required. WORKSFORME - Accepted, but no spec change. The spec already addresses the comment due to a previous change. Editor's response required. NEEDSINFO - Additional information is required to accept or reject this comment. Editor's response required. Editor should be clear on what additional info is required. WONTFIX - Rejected. Editor's response required. LATER - Rejected, but may be reconsidered for a future version. Editor's response required. REMIND - Do not use. INVALID - Bug is obvious junk or spam. Does not require a full editor's response. DUPLICATE - Bug is the same issue as another bug. Does not require a full editor's response.
Reopening - I closed this by mistake.
(In reply to comment #1) > WORKSFORME - Accepted, but no spec change. The spec already addresses the > comment due to a previous change. Editor's response required. I suggest letting other people than the editor to resolve bugs as WFM without editor's response. It's the existing practice and seems to work well.
(In reply to comment #3) > (In reply to comment #1) > > WORKSFORME - Accepted, but no spec change. The spec already addresses the > > comment due to a previous change. Editor's response required. > > I suggest letting other people than the editor to resolve bugs as WFM without > editor's response. It's the existing practice and seems to work well. I think it would be fine for people other than the editor to close bugs as WFM, assuming the relevant editor for a draft does not object. However: 1) It's still useful to explain to the originator what next steps are available to them if they disagree that the issue is already addressed (e.g. reopen the bug). 2) It's still necessary to explain how the issue is already addressed. This is required both for benefit of the bug originator, and in the future to be able to produce a disposition of comments. For obvious spam or duplicates, hopefully no further explanation is needed. So perhaps the best solution here is a variant of the editor's response template. Or maybe such cases of WORKSFORME are sufficiently obvious that they don't require further explanation. Comments from the editors and the other chairs welcome.
I agree with Henri's suggestion about letting other people than the editor resolve bugs as WORKSFORME. I also agree that it might be useful to have a variant of the editor's response boilerplate/template for this case, but I don't think it's absolutely necessary. Other than that, I think the proposed description of the INVALID state might be too restrictive. I think in practice we are not just using it for bugs that are obvious junk or spam, but also for bugs that are raised legitimately but which are clearly based on the commenter having misread/misunderstood the spec.
(In reply to comment #5) > I agree with Henri's suggestion about letting other people than the editor > resolve bugs as WORKSFORME. I also agree that it might be useful to have a > variant of the editor's response boilerplate/template for this case, but I > don't think it's absolutely necessary. > > Other than that, I think the proposed description of the INVALID state might be > too restrictive. I think in practice we are not just using it for bugs that are > obvious junk or spam, but also for bugs that are raised legitimately but which > are clearly based on the commenter having misread/misunderstood the spec. I think that should be a WORKSFORME, not INVALID (i.e. the spec doesn't actually have the stated bug). I would prefer we reserve INVALID for bugs that don't even state an issue. It also seems like this is the kind of situation that will require a rationale. How else can we tell if the originator agrees that they just misread the spec?
Addressed in: http://dev.w3.org/cvsweb/html5/decision-policy/decision-policy-v2.html.diff?r1=1.13&r2=1.14&f=h I also added the boilerplate text that is suggested when resolving a bug.