This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Larry Masinter wrote: "What happens when: (1) a bug is submitted, (2) the editor responds, (3) the person reporting the bug is satisfied with the change, but (4) other working group members are not? Do working group members watch bug fixes and then open new bugs?" I replied: "Clarification: Any Working Group member who is dissatisfied with a bug resolution may reopen the bug or escalate to an issue, even if he or she is not the one who originally filed the bug. This is the intent of the policy, and we have given this clarification before, but we should make it more clear. Possible Policy Update: Make the above clarification manifest in the wording."
It would be useful for the "decision policy" document to note how to watch the bugzilla changes which note bug resolutions and submitters agreement (or lack of response or whatever that might lead to a comment being "closed" without additional working group review.) It's difficult to figure this out. I think one might, for example, monitor public-html-bugzilla@w3.org but that stream includes all kinds of bugzilla updates. is there a better way of monitoring when bugs are moved from NEW or ASSIGNED? The current charter http://www.w3.org/2007/03/HTML-WG-charter section 6 says that communication happens on public-html@w3.org. The working group home page http://www.w3.org/html/wg/ does point to a list of working group mailing lists, and public-html-bugzilla@w3.org is listed as one of the 10 mailing lists that might concern HTML, but it took some poking around to figure this out.
(In reply to comment #1) > It would be useful for the "decision policy" document to note how to watch the > bugzilla changes which note bug resolutions and submitters agreement (or lack > of response or whatever that might lead to a comment being "closed" without > additional working group review.) > > It's difficult to figure this out. I think one might, for example, monitor > public-html-bugzilla@w3.org but that stream includes all kinds of bugzilla > updates. is there a better way of monitoring when bugs are moved from NEW or > ASSIGNED? > > The current charter http://www.w3.org/2007/03/HTML-WG-charter section 6 says > that communication happens on public-html@w3.org. > > The working group home page http://www.w3.org/html/wg/ does point to a list of > working group mailing lists, and public-html-bugzilla@w3.org is listed as one > of the 10 mailing lists that might concern HTML, but it took some poking around > to figure this out. > There's a couple of ways to track what happens in bugzilla: 1) You can subscribe to or read the archives of public-html-bugzilla, though as you note that gives you a flood of irrelevant info. 2) You can add yourself to the Cc list of specific bugs you are interested in. 3) You can regularly do a bugzilla search query for bugs that have moved to state RESOLVED in some period of time (e.g. weekly). That's what I do to gather monthly bug stats, and Laura Carlson does it weekly for a subset of the bugs. I agree it would be good to document these, though it seems like a separate issue from the original substance of this bug. We could also add additional ways, for example it may be possible to set up a mailing list that gets mail only when a bug moves into RESOLVED state. I can ask our Team Contacts about the feasibility of doing that.
(In reply to comment #2) > I agree it would be good to document these, though it seems like a separate > issue from the original substance of this bug. cf "Do working group members watch bug fixes and then open new bugs?" The substance of the bug was to insure responses to comments come "from the working group" and not just "from the editor", even when allowing a fast-tracking situation where the bugs get resolved and closed without any explicit discussion. Not everyone on the working group has the bandwidth or interest to monitor these real time anyway. > "You can regularly do a bugzilla search query for bugs that have moved to state RESOLVED in some period of time ... monthly bug stats..." Easy-to-find canned queries linked from the working group "How to participate" instructions, with an explicit note about how to re-open or escalate something if you disagree, etc. sounds like it might do it. I would think you might want to add some preconditions around reopening things rather than escalating, though.
(In reply to comment #3) > (In reply to comment #2) > > > I agree it would be good to document these, though it seems like a separate > > issue from the original substance of this bug. > > cf "Do working group members watch bug fixes and then open new bugs?" > > The substance of the bug was to insure responses to comments come "from the > working group" and not just "from the editor", even when allowing a > fast-tracking situation where the bugs get resolved and closed without any > explicit discussion. > > Not everyone on the working group has the bandwidth or interest to monitor > these real time anyway. I agree. I suspect there are currently no people besides me attempting to review every single bug that gets resolved, and even my own monthly review is not very thorough. Realistically, the gating factor here is that, at least since August 2009, we have had 200-300 incoming bugs and 200-300 resolved bugs a month. I would guess few people have the bandwidth to follow along. However, many people do seem to follow their own bugs, or ones they get Cc'd on, or ones they hear about. When the originator (or anyone else) thinks a bug is of particular interest BTW here are some monthly bug stats I extracted from bugzilla, this is my basis for the claim about in/out rates: http://spreadsheets.google.com/ccc?key=0AoCAfo_LQ5_kdFFWWmpCMWxsLUN2TW9VYi1uNEJGenc&hl=en > > "You can regularly do a bugzilla search query for bugs that have moved to > state RESOLVED in some period of time ... monthly bug stats..." > > Easy-to-find canned queries linked from the working group "How to participate" > instructions, with an explicit note about how to re-open or escalate something > if you disagree, etc. sounds like it might do it. Good idea. Here is a query that I believe will find all bugs resolved in the past 30 days (from whenever it gets run - it uses relative dates) in the HTML WGs drafts. Testing would be appreciated: http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=HTML+WG&component=HTML%2BRDFa+%28editor%3A+Manu+Sporny%29&component=HTML5+differences+from+HTML4+%28editor%3A+Anne+van+Kesteren%29&component=HTML5+spec+bugs&component=HTML5+spec+proposals&component=HTML5%3A+The+Markup+Language+%28editor%3A+Michael%28tm%29+Smith%29&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=-30d&chfieldto=Now&chfield=bug_status&chfieldvalue=RESOLVED&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= Shorter URL for the above: http://tinyurl.com/yj2ajrl > I would think you might want to add some preconditions around reopening things > rather than escalating, though. Not sure I follow. What kind of preconditions do you have in mind?
I applied the following edits to the provisional v2 copy of the policy document: http://dev.w3.org/cvsweb/html5/decision-policy/decision-policy-v2.html.diff?r1=1.1&r2=1.2&f=h
Per Larry's suggestions, I also added a "Bugs resolved in the last 30 days" link to the HTML WG homepage: http://www.w3.org/html/wg/