Re: HTML Working Group Decision Policy - for discussion

> > > The policy document can be found here:
> > > http://dev.w3.org/html5/decision-policy/decision-policy.html
> >
> > First, I disagree with closing the bug if the item gets kicked into
> > the tracker.
>
> As the table at the bottom of the 'Basic Process' steps shows, bugs do
> not get marked CLOSED when escalated to the Tracker; they get marked
> VERIFIED and tagged as TrackerIssue.


My apologies. to Maciej This is different than current behavior.

>
> > A closed bug implies nothing is being done to address the issue, but
> > that's not true.
>
> There's no implication going on; all the states have defined meanings,
> listed in the policy document.
>
> > If a person searches in the Bug database for open items, this item
> > won't be among those returned.
>
> It would be convenient if predefined Bugzilla links were provided for
> the various meanings, to avoid any confusion.
>
> > 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.
>
> Since the policy clearly mentions the Tracker's use, anybody following
> the policy should be aware of the Tracker.  (And anybody not following
> the policy can't be catered for by what the policy says ...)
>

That's not the appropriate way to deal with concerns.

This procedure should be a way to facilitate concerns, not test whether 
someone is familiar with how the HTML WG operates.


> > This will, most likely, lead to numerous duplicate bugs.
>
> Anybody diligently wishing to avoid giving feedback that others have
> already given, to avoid duplication, shouldn't be searching only open
> bugs: if the feedback has already been given and successfully dealt with
> then the bug will be closed, and re-giving the same feedback would be
> just as pointless.

My concern on this was moot, since the bugs will not be closed if the 
item is moved to the Issue Tracker.


>
> > 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?
>
> The policy says:
>
>   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.  Those who have
>   permissions to create and edit issues will help with the mechanics.
>
> So that is not automatic, but does cover those without Tracker privs.
>

No, it is not clear how this occurs. Who do they ask? How do they ask? 
Does it have to be asked in the bug? Does an email have to sent to the 
HTML WG?

This is not clearly defined in the document.


> > 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,
>
> The working group is chartered for asynchronous participation.  All
> announcements and calls so far have been by e-mail.  Why do you think
> that would suddenly change?
>

Actually, this hasn't always happened.

For instance, the new dt/dd issue was mentioned, from what I can tell in 
HTML WG teleconference meeting minutes, in the last teleconference, but 
I haven't a clue if the chair asked for volunteers, or what happened 
with it.

So far, the chairs have not formally sent an email to the HTML WG, or to 
me, the person who raised the issue, asking for volunteers to address 
the issue.

In addition, there's nothing in the procedure about soliciting for 
volunteers outside of the group. For instance, if an issue is raised by 
a person outside of the HTML WG it would seem to me to be appropriate to 
allow the person who raised the issue to submit a proposal. But I'm 
still trying to figure out what happened to the one dt/dd issue from the 
last meeting minutes, and if I should do _something_ to ensure it 
doesn't just die.

So, no, there are gaps in the document that need to be addressed.

> Smylers
Shelley

Received on Wednesday, 7 October 2009 13:59:28 UTC