Re: HTML Working Group Decision Policy - for discussion

> Sam, Paul and I have discussed decision policy for the HTML Working  
> Group at some length. We'd like it to be very clear what Working Group  
> contributors are expected to do to pursue an issue. And we would like  
> it to be clear in turn how we will act on that input. We have a  
> proposal ready for discussion, with a combination of ideas from Sam's  
> experience chairing the IETF Atom Working Ggroup, Paul's experience  
> chairing the W3C XQuery Working Group, and my experience participating  
> as a non-chair in various Working Groups. Much of what is in this  
> document is based on methods that we're already practicing.
>
> Right now, we're putting this document our for discussion. It's very  
> important for Working Group members to read this document and give  
> questions or comments. Once we settle on a policy, we're going to  
> follow the procedures outlined and will expect Working Group members  
> to be the same. So now is a great time to ask about things that are  
> unclear, or suggest improvements.
>
> At the very least, I recommend reading the introduction, and looking  
> at the flowcharts and tables.
>
> One important new concept in this policy document is the idea of a  
> Change Proposal. To move forward on Tracker Issues, we will expect  
> Working Group members to write up proposals with a few required  
> content fields. If you are interested in advancing the progress of  
> Tracker Issues, please read over the description of a Change Proposal.
>
> The policy document can be found here: 
> http://dev.w3.org/html5/decision-policy/decision-policy.html
>
> Regards,
> Maciej

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.

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?

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.

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

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.

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

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?

Shelley

Received on Wednesday, 7 October 2009 13:10:31 UTC