This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In the process, there are situations where an issue is marked "CLOSED" when the status is actually "CLOSED after timeout". (The latter is called "CLOSED without prejudice", but in fact there is a "prejudice", namely that the issue cannot be reopened without the permission of the chairs.) The distinctions between these two states is fundamental: in one case, the issue was resolved amicably, while in the other case, the issue was deferred because no one in the working group was able to volunteer to create a counter-proposal which met all of the (somewhat arbitrary) format requirements imposed by the chairs, within a time limit also imposed by the chairs (without getting the working group agreement about the time limit). In one case, there was even a volunteer to write a change proposal but the time requested for submitting the change proposal was considered (by the chairs, without agreement from the working group) to be too long. The status of issues, and the fact that they were closed because of lack of a specific kind of response within an arbitrary timeout period should be clear in the issue status. There should be two states "CLOSED" and "TIMEDOUT". Significant care has been given to embedding status information in the document, so that reviewers can know which issues are still open or subject to more careful review. This annotation should carry through even into last call, as reviewers outside the working group may well have additional information and alternative proposals to bear, if only they knew the status. That is, issues that are "TIMEDOUT" should be marked as such in the document. In the case of "bugs" which have been marked by the editor as "RESOLVED" and "WONTFIX", but the original bug reporter has not had time to object to this annotation and escalate the issue --- please verify that these "bugs" also are reported in the issue status. Perhaps the bugzilla database needs to have a similar distinction between "EDITOR MARKED RESOLVED" and "RESOLUTION ACCEPTED" vs. "ESCALATED".
Could the chairs please confirm: * If a change proposal is not completed by its deadline, the issue will be closed without prejudice and DEFERRED to the NEXT VERSION of HTML. * An issue that is closed without prejudice in this way can only be e-raised with approval of the HTML Chairs. It is an ENDPOINT for the escalation process. Are these correct? Thanks. Also it isn't clear from the process document if there is a differences between CLOSED and "TIMED OUT".
Related Reference: Dan Connolly's February 25, 2010 definition of what closing an issue means. "...closing an issue means 'we're done; we don't plan to work on it more unless/until somebody brings up information that we haven't considered.'" http://lists.w3.org/Archives/Public/www-archive/2010Feb/0044.html
Looks like there are a couple of different requests here: 1) Use some state other than CLOSED for issues that are closed without prejudice, for lack of action by a deadline, with the specific suggestion of TIMEDOUT. 2) Continue marking issues that are closed without prejudice in the draft. 3) Mark issues that are closed without prejudice in the draft even during Last Call. 4) 'In the case of "bugs" which have been marked by the editor as "RESOLVED" and "WONTFIX", but the original bug reporter has not had time to object to this annotation and escalate the issue --- please verify that these "bugs" also are reported in the issue status.' - I'm not sure what the request is here. When you say "reported in the issue status" do you mean the issue status page, something in the tracker, or the issue markers in the draft? 5) Bugzilla should distinguish among between "EDITOR MARKED RESOLVED" and "RESOLUTION ACCEPTED" vs. "ESCALATED". I will try to split these up into one bug per issue. Some preliminary comments: On (1), I'm told that the only way to add a new state to the tracker is to do so across all W3C tracker instances, and that we'd need a very convincing argument to add a new state. However, there is an existing POSTPONED state which might be appropriate. On (2) and (3), issue markers are a practice that the Working Group came to by rough consensus (during last year's late summer publication round). They are not currently documented in the Decision Policy. I would suggest that before crafting a formal policy, it may be desirable to seek change informally with the Working Group. Also on (2) and (3), the current issue markers look something like this: "ISSUE-41 (Decentralized-extensibility) blocks progress to Last Call". Clearly that text would not be usable as-is for issues that do not block progress to Last Call, and especially not during Last Call. Personally, as I see it the very purpose of the markers is to flag issues that block progress to Last Call, so I'm unsure of the merit of flagging issues that do not. On (5), those three states are indeed distinguished in bugzilla. "EDITOR MARKED RESOLVED" is identified by the state RESOLVED or VERIFIED without the TrackerRequest or TrackerIssue keywords. "RESOLUTION ACCEPTED" is identified by the CLOSED state. "ESCALATED" is identified by presence of the TrackerRequest or TrackerIssue keywords.
Hi Laura, (In reply to comment #1) > Could the chairs please confirm: > > * If a change proposal is not completed by its deadline, the issue will be > closed without prejudice and DEFERRED to the NEXT VERSION of HTML. > > * An issue that is closed without prejudice in this way can only be e-raised > with approval of the HTML Chairs. It is an ENDPOINT for the escalation process. > > Are these correct? I believe those statements are nearly direct quotes from the decision policy, and have already been confirmed by the chairs via email. Are you looking for some further clarification in the policy itself?
(In reply to comment #4) > Hi Laura, > > (In reply to comment #1) > > Could the chairs please confirm: > > > > * If a change proposal is not completed by its deadline, the issue will be > > closed without prejudice and DEFERRED to the NEXT VERSION of HTML. > > > > * An issue that is closed without prejudice in this way can only be e-raised > > with approval of the HTML Chairs. It is an ENDPOINT for the escalation process. > > > > Are these correct? > > I believe those statements are nearly direct quotes from the decision policy, > and have already been confirmed by the chairs via email. Are you looking for > some further clarification in the policy itself? That would be very helpful. Some do not yet understand the repercussions of missing deadlines and the finality of closing an issue. The chairs have been generous in repeatedly extending deadlines to the point were deadlines may not be taken seriously by some. Realistic and reasonable deadlines should be mutually agreed upon, set, and then actually met not only by individual working group members but by task force groups as well.
Re: "I will try to split these up into one bug per issue." Please don't. I submitted what I think is a coherent "bug". I pointed out some examples of the "bug" and gave some proposed solutions, I'm not sure I've really hit them all, or the proposals that I made were the "right" ones. The main point of the "bug report" is that the process should maintain the integrity of the information about comments on specifications: for the record, for the next version, for reviewers, for all of the reasons why a standards process should be "open". I think there is requirement that comments get a response *from the working group*. There are several paths through the current process where a comment gets a response from one individuals (the editor) or a few (the chairs, who set a schedule for change proposals and judge whether the proposals are proper), and where the working group opinion isn't assessed except by the absence of objections, or (worse) the absence of anyone willing to both put in an extraordinary amount of "work" (one might even say "abuse") that comes along with making proposals. These steps may be necessary in order to get the document and the process stabilized quickly, but losing the visibility of the cases in which that happened isn't really in the best interest of anyone. So, if we're following the current process, please, editors of the process document, either accept this bug 9184, resolve the bug, mark it as NEEDSINFO, WONTFIX or whatever, but don't split it up. (There's a separate 'bug' in the process, if the editor of a document can split up a 'bug' into several other 'bugs' and then reject one or more of them as 'already decided by rough consensus'; that would be counter to the requirement to actually address the comment. ) (The notion that we're using the process to discuss the process seems odd -- reminds me of Reddit's Nommit; is this really appropriate?)
(In reply to comment #5) > (In reply to comment #4) > > Hi Laura, > > > > (In reply to comment #1) > > > Could the chairs please confirm: > > > > > > * If a change proposal is not completed by its deadline, the issue will be > > > closed without prejudice and DEFERRED to the NEXT VERSION of HTML. > > > > > > * An issue that is closed without prejudice in this way can only be e-raised > > > with approval of the HTML Chairs. It is an ENDPOINT for the escalation process. > > > > > > Are these correct? > > > > I believe those statements are nearly direct quotes from the decision policy, > > and have already been confirmed by the chairs via email. Are you looking for > > some further clarification in the policy itself? > > That would be very helpful. Some do not yet understand the repercussions of > missing deadlines and the finality of closing an issue. > > The chairs have been generous in repeatedly extending deadlines to the point > were deadlines may not be taken seriously by some. > > Realistic and reasonable deadlines should be mutually agreed upon, set, and > then actually met not only by individual working group members but by task > force groups as well. Maybe this should be a separate bug. These comments don't seem related to Larry's suggestions.
> (The notion that we're using the process to discuss the process seems odd -- > reminds me of Reddit's Nommit; is this really appropriate?) Two points. First, I don't see that as particularly odd, given that the W3C process document itself indicates that the process for modifying a Recommendation may be used to modify the Process Document itself: http://www.w3.org/2005/10/Process-20051014/processdoc.html#GAProcess Second, we are using a piece of software which is known to be effective at ensuring that comments don't get lost. I see that as different than "using the process to discuss the process". Should a new draft of the HTML Working Group Decision Policy be produced, I see it as highly likely that we will follow the same process seeking input and accessing consensus before the draft gets put into effect.
(In reply to comment #8) I'm fine with using this as a means of insuring comments don't get lost, and I'm sorry if it sounded like I meant otherwise. It's easy to get lost in the mechanics (what's the state of the database? Who is allowed to post what kind of comment where, which decisions were already decided vs. which things are allowed to still be open) vs. the intent (can outsiders figure out what went on?), and that can happen with a "decision policy" document too, and some people seem to get caught up in that.
(In reply to comment #6) > Re: "I will try to split these up into one bug per issue." > > Please don't. I submitted what I think is a coherent "bug". You made at least five concrete suggestions, and I would like the bugzilla record to reflect which of those specifically was accepted or rejected. If you'd like, I can make those five separate bugs in addition to this bug, rather than instead of. > I pointed out some examples of the "bug" and gave some proposed solutions, I'm > not sure I've really hit them all, or the proposals that I made were the > "right" ones. The main point of the "bug report" is that the process should > maintain the integrity of the information about comments on specifications: for > the record, for the next version, for reviewers, for all of the reasons why a > standards process should be "open". > > I think there is requirement that comments get a response *from the working > group*. There are several paths through the current process where a comment > gets a response from one individuals (the editor) or a few (the chairs, who set > a schedule for change proposals and judge whether the proposals are proper), > and where the working group opinion isn't assessed except by the absence of > objections, or (worse) the absence of anyone willing to both put in an > extraordinary amount of "work" (one might even say "abuse") that comes along > with making proposals. These steps may be necessary in order to get the > document and the process stabilized quickly, but losing the visibility of the > cases in which that happened isn't really in the best interest of anyone. > > So, if we're following the current process, please, editors of the process > document, either accept this bug 9184, resolve the bug, mark it as NEEDSINFO, > WONTFIX or whatever, but don't split it up. To be clear: the Chairs are using bugzilla to track issues with the decision policy document because we need some way to track issues, and bugzilla is available and convenient. However, we do not intend to make the Decision Policy a publication of the Working Group and therefore the Decision Policy does not really apply. Likewise for bugzilla components such as "HTML WG website" and "testsuite" that do not correspond to a current or proposed Working Draft and which are not intended to ever go to Last Call. I would expect that when we have a revised draft of the policy, we will have the same kind of WG discussion and eventual Call for Consensus as we did on the original policy. > (There's a separate 'bug' in the process, if the editor of a document can split > up a 'bug' into several other 'bugs' and then reject one or more of them as > 'already decided by rough consensus'; that would be counter to the requirement > to actually address the comment. ) > > (The notion that we're using the process to discuss the process seems odd -- > reminds me of Reddit's Nommit; is this really appropriate?) It's definitely appropriate to have some process for updating the process. Since you have yourself asked for changes and clarifications, I am not sure why you think it's appropriate to mock the chairs for taking feedback, tracking it, and planning to make changes. Constant use of scare quotes and repeated comparisons to Nomic are not courteous or constructive, in my opinion.
(In reply to comment #10) I'm sorry if my tone seemed combative, but given recent events, maybe you could cut a little slack. > You made at least five concrete suggestions, I did make some suggestions, but I'd hope that you'd actually respond to the spirit of the "bug" report, of which the concrete suggestions were just examples. While it's great if those suggestions are helpful, it would be fine if you found some other more efficient way of addressing the concern. I can think of many other ways of addressing the issue raised; e.g., in a separate document, publication, web page, which is released along with the working group documents. I'm really not tied to the concrete suggestions I made, but I didn't want to just complain without pointing out at least one way of trying to address the issue. > However, we do not intend to make the Decision Policy a publication of the > Working Group and therefore the Decision Policy does not really apply. OK, that itself wasn't clear; I didn't understand how this was going to get updated, and your reference to previous "rough consensus" of the working group as somehow preventing use of two my suggestions left me puzzled. If there's a new problem report for the decision policy, the fact that there was a previous agreement about a little bit of process associated with the decision policy shouldn't interfere with addressing the new problem, should it? I'm sorry you read my tone or references to Nommit as mocking. The working group would be more constructive if ad hominem argumentation could be reduced. I put "bug" in quotes because, while "bug" is traditionally used for software, and sometimes documents and test cases, it seemed was a stretch for me to apply it to something like the process document. "Scare quotes" are "quotation marks are placed around a single word or phrase to indicate that the word or phrase does not signify its literal or conventional meaning." I can't see why that's not courteous or constructive.
Larry, here's my plan. I am going to file the five concrete suggestions from you as separate bugs. However, I am not going to close this bug. Instead, we should check back after those concrete suggestions have been fielded, to see if transparance has improved to your satisfaction, or if there's more we need to do. I hope that's ok.
The five narrower bugs are now marked as blocking this bug.
(In reply to comment #1) > Could the chairs please confirm: > > * If a change proposal is not completed by its deadline, the issue will be > closed without prejudice and DEFERRED to the NEXT VERSION of HTML. > > * An issue that is closed without prejudice in this way can only be re-raised > with approval of the HTML Chairs. It is an ENDPOINT for the escalation process. > > Are these correct? I would suggest the addition of the word "presumed" before DEFERRED. This would make this part of the sentence consistent with "closed without prejudice" and "can ... be re-raised with approval of the HTML chairs". I don't think we need to annotate this further in the process itself, but my expectation is that the chairs will entertain any or all fully-thought out proposals that have a reasonable chance of gaining consensus. That being said, once an issue has timed out, I do not believe that it is anybody's best interest to allow the WG to spend further time on proposals that are not fully-thought out or do not have a reasonable chance of gaining consensus. [if it will help, I'll gladly split this out to a separate bug report]
Added bug 9654 as blocker per Sam's comment 14.
Will revisit this once all blockers are resolved (there are two left).
Someone who has not been tracking the HTML working group process day to day should be able to review which sections of the document for which there is widely perceived problem but for which the issue was closed because there was no concrete proposal delivered in time, especially since the timeouts have been produced without any clear reasoning for when the deadline was set or any consensus from the working group that the deadline was reasonable. This "bug" in the process will be fixed when at least 2 out of 3 random non-working group member would be able to tell that, say, the issue over the "resource vs. representation" issue was only closed because Roy Fielding wasn't willing to volunteer to work on the editing with a deadline to the chair's satisfaction.
The Chairs believe that the revised decision policy, plus WG homepage updates and so forth, will make it sufficiently clear how issues have been resolved. Once the new decision policy is deployed, we welcome feedback based on testing it. I suspect a standard of 2 of of 3 non-WG members understanding something clearly without following the WG day-to-day is unrealistic. I suspect there is no nontrivial fact about the work of this or any other WG which 67% of non-WG members are likely to understand immediately without explanation.