Re: HTML Working Group Decision Policy - for discussion

Shelley Powers wrote:
>> 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.

Re: "implies"... until we have a documented procedure, all we have is 
implications.  Once the procedure is in place, the terms will mean what 
we say they mean.

Given the (relatively much smaller) number of open issues and the 
frequency with which we review them as a group, I'm not convinced that 
duplicate bug reports will be a significant problem.  There are multiple 
purposes to which the bug reports serve, one of which is the todo list 
for the editors of the various documents produced by this Working Group.

The model here is that the issues list is an escalation path if an 
editor is unwilling or unable to find a resolution to an issue to the 
satisfaction of the person bringing up the objection.  Similarly, 
decisions made by chairs can be overruled... ultimately up to the director.

In a very real sense, every decision is provisional until Rec, meanwhile 
I like the clarity of having every step along the way making clear, 
binary decisions, and having a clear process to revisit, and potentially 
overrule, prior decisions.

> 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?

This is not automatic.

> 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.

We have a number of people (currently 26) with access to the tracker... 
and I am willing to add more.  If you are not happy with the text in an 
issue, let me know and I will either correct it or open a new issue.

( The current list can be seen by members at 
http://www.w3.org/2000/09/dbwg/details?group=41863 )

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

Each issue has an "edit this issue" link, but again that is limited to 
the people with access to the tracker.

The documentation is clearly incomplete at this moment, and parts of it 
are (unfortunately) members only.  http://www.w3.org/html/wg/ mentions 
an issue tracking task force.

> 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.

I'm not following.  Nothing will happen exclusively in WG 
teleconferences, the group is open to everybody who is willing to agree 
to the patent policy, and we have plenty of people who will assist with 
the mechanics of everything from adding a link from an issue to a 
proposal to doing actual updates in cvs.

See: http://www.w3.org/html/wg/#who

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

My first preference is to encourage volunteers to join and enable them 
to directly participate.  And when that isn't sufficient, I have not 
only stated but demonstrated that I am willing to go further.  Maciej 
and Paul are continuing this tradition, and we are blessed to have 
plenty of other volunteers (again, the current count is 26 total) who 
are willing to help.

> 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?

Here's the link, and adding it to the process document would be a good idea:

http://www.w3.org/2005/10/Process-20051014/policies#WGArchiveMinorityViews

The essence of that part of the process is that an individual registers 
a Formal Objection to a decision, and the Issue process is a way to get 
the WG to make a decision.

> Shelley

- Sam Ruby

Received on Wednesday, 7 October 2009 13:55:46 UTC