Re: HTML Working Group Decision Policy - for discussion

Sam Ruby wrote:
> 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.

As was noted earlier, I missed that the item is not CLOSED in Bugzilla, 
if the item has been moved to the Issue Tracker. That addressed my 
concerns in this regard.

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

But how do we do this? Do we ask in the Bug? Do we have to email people 
individually? Do we have to send an email to the HTML WG?

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

I still have a very real concern about how the issue gets worded in the 
Issue Tracker.

For instance, I submitted two bugs on the re-use of dt/dd [1][2]. I 
mentioned two concerns: the redefining of the semantics of the elements, 
and the fact that syntactic differences will cause confusion to authors 
in the future.

When it was moved to the Issue Tracker, it was done so as "The content 
models for the <figure> and <details> elements use the <dt> and <dd> 
elements, but give them different semantics."

That doesn't cover my concerns. Sure the bugs are referenced in the 
Issue Tracker, but that requires that a person follow the bugs, and that 
isn't always going to happen when people are being asked to consider the 
issue.

This may seem minor, but when the item is moved to the Issue Tracker, I 
no longer have any control over how my concerns are expressed. And the 
new procedures document does not address how a person submits an edit, 
or new information. I believe additional material in this regard would 
be helpful.


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

I'm sorry, but I don't believe that telling someone to join the group is 
a viable way of dealing with people's concerns. And I believe that 
recording the steps a person needs to take to add additional information 
to the Issue, to volunteer to write a proposal, etc, is not an 
unreasonable edit to ask of the document.

> 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.
>
I believe that ensuring a request for proposal submitted to the HTML WG 
email list, and cc'd to the person who submitted the issue, originally, 
would ensure that all bases are covered.

>> 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.
>
How does one register a Formal Objection to the HTML WG? Do we send an 
email to the HTML WG list, with the Issue in the subject line? Do we use 
the words "Formal Objection" in the subject line, too?

>> Shelley
>
> - Sam Ruby
>
Shelley


[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=7669
[2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=7657

Received on Wednesday, 7 October 2009 14:16:51 UTC