Re: HTML Working Group Decision Policy - for discussion

Hi Shelley,

Thanks for the feedback and questions.


On Oct 7, 2009, at 6:09 AM, Shelley Powers wrote:

>
> As a person who is not a member of this group, but will, most  
> likely, be submitting bugs, there are aspects of this procedure that  
> need some clarification:
>
> First, I disagree with closing the bug if the item gets kicked into  
> the tracker. A closed bug implies nothing is being done to address  
> the issue, but that's not true. If a person searches in the Bug  
> database for open items, this item won't be among those returned.  
> This will give the person the impression that there is no open items  
> on this issue at this time. They wouldn't necessarily think to look  
> in the Issue Tracker, either. This will, most likely, lead to  
> numerous duplicate bugs. And a false sense of the state of the  
> document, too.

Looks like this has been addressed by others - tracker issues will be  
in a different state than bugs that are actually closed. To clarify  
further, there is a table of what different bug states mean: http://dev.w3.org/html5/decision-policy/decision-policy.html#states-and-keywords

> What are the actual mechanics of moving a bug to the issues tracker?  
> A person who doesn't have Issue Tracker write access can't do this.  
> Will Bugzilla have an option that does this automatically?

In practice, the way it has happened is that Mike Smith finds all the  
bugs that need to be escalated and files a tracker issue. It's  
probably good to define this more formally, though.

> Also, the person who adds the issue to the Tracker can modify the  
> text of the issue in such a way that it no longer reflects a  
> person's concern. How do we prevent this? In Bugzilla, we all own  
> our own writing, but the same cannot be said for the Issue Tracker.

To address this and the previous question, I updated step 5.d. as  
follows:

"If the commenter is dissatisfied with the resolution and does not  
believe it is productive to ask the editor to reconsider, he or she  
may ask to escalate the issue to the issue tracker. A commenter with  
Tracker access can raise an Issue directly. A commentor without  
tracker access should apply the TrackerRequest keyword, and should  
suggest a title and text for the tracker issue. Team contacts or other  
volunteers with access will move TrackerRequest issues into the tracker.

The issue tracker issue should reference the original bugzilla bug.  
The bugzilla bug will reference the issue and have the TrackerIssue  
keyword added."

>
> How do we add additional information to an Issue? This isn't  
> documented in the procedure.

Two ways to add information are documented: writing a Change Proposal,  
and participating in the discussion of a Change Proposal. I have  
documented two additional ways:

"Note: comments with additional information may still be added to a  
bugzilla bug after it has been escalated to the tracker."

"Note: information can be added to an Issue without writing a full  
Change Proposal by sending email to the public-html mailing list that  
mentions the issue number in the format ISSUE-<i>nnn</> where <i>nnn</ 
i> is the issue number."


> The escalational process for determining how to manage the issue  
> does not reflect the most likely fact that the bugs/issues during  
> Last Call will come from outside of the group. If the call for  
> volunteers only occurs during the WG teleconference, which I'm  
> having to assume happens, because this is not mentioned in the  
> document, there's no opportunity for the person who submits the bug/ 
> issue to be involved with authoring a change proposal for submittal  
> to the group.

Our Working Group is required to do everything in a way that enables  
asynchronous participation. I added the following to the policy:

"Requests for Change Proposals will go out to the HTML WG mailing list  
and possibly via other channels as well."

My expectation is that we'll issue each call for volunteers on the  
public-html mailing list at a minimum, and likely also on the telecons.

> How does the WG submit an issue for volunteers that encompasses  
> effort both outside of the group and in?

I'm not sure what you have in mind. Could you give an example?

>
> Finally, I couldn't find in the document a clear procedure about how  
> Formal Objections are made, and tracked. Do we write these up as  
> separate documents, and submit? Are these recorded somewhere? Do we  
> send these to the HTML WG email list? If I remember correctly, the  
> W3C process doesn't do a good job of stating where FO should be  
> submitted, nor does it cover how these are made publicly available.  
> Frankly, I've also been given the impression that Formal Objections  
> submitted by individuals will not be considered by the Director:  
> only submittals by organizations. Can this be clarified in the  
> document?

The document says, for step 9.a:

"If the commenter does wish to enter a Formal Objection, he or she  
should do so according to W3C Process. This includes explicitly  
stating that it is a Formal Objection, as well as giving a technical  
justification for the objection. The Formal Objection should be  
recorded in the bugzilla bug, and the bug should be placed in the  
CLOSED state and tagged with the FormalObjection keyword."

So the right place to record a Formal Objection is in bugzilla. Note  
that this option is only available after going through the whole Basic  
Process and the whole Escalation Process. I added that a Formal  
Objection should mention at least one way the objection could be  
removed.

Thanks for the feedback, and I hope the clarifications help.

Regards,
Maciej