Re: HTML Working Group Decision Policy - for discussion

Maciej Stachowiak wrote:
> 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
>

Yes, thanks.

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

That's much better. Provides a nice flow to follow.

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

Ah, there it is. I missed it first time through.

Yes, this seems like an excellent way to make additional notes, or add 
additional material.

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

I'm thinking that a direct email could also be sent to the person who 
submitted the bug, and escalated the issue. There's a way to subscribe 
to the bug, but it would be nice if non-HTML WG members were aware when 
they're issue is being discussed outside of the Bug database.

However, if the Chairs send a request for change proposal to the HTML 
WG, that should probably be OK. Most of us keep up with the group.

Is there a way to subscribe to the issues in the Issue Tracker?
>>
>> 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.

Again, I must have missed this one. Sorry, next time I'll try to read 
more carefully.

So we record a Formal Objection in Bugzilla? I'll be honest and say I'm 
not comfortable with this. This seems like a very inappropriate place to 
put something such as a Formal Objection. If this is the only way this 
can work, I guess we'll have to live with it, but what happens to the 
Formal Objection once it's in the Bugzilla database?

>
> Thanks for the feedback, and I hope the clarifications help.
>
> Regards,
> Maciej
>


Thanks for the clarifications.

Shelley

Received on Thursday, 8 October 2009 01:58:15 UTC