(In reply to comment #0)

> Evidently, giving dissenters the benefit of due process didn't bring the ISSUEs
> to closure.

Some of the decisions made to date are indecisive. 

For instance a decision takes something out because it's incomplete but allows it to put it back in the spec later. Another leaves something in for now, but allows taking it out later if problem(s) with it are not resolved. Some decisions allow for improvement of a feature decided to be left in the spec.

It might help if the parts of the decisions which are indeed:

* Open to further discussion be specifically identified in the decision. 
* Closed to further discussion be specifically identified in the decision. 

This would let everyone know what is or is not off limits.

(In reply to comment #0)
> I gather an important point of the Decision Policy is to manage dissent by
> establishing a due process for dealing with the dissent as opposed to having
> permathreads of claims that a particular concern hasn't been duly considered by
> the WG as a whole to go on indefinitely taking the attention of the WG
> participants and interfering with productive work at the WG.

I agree that this was an important goal for the Decision Policy.

> Now that the Chairs have, on behalf of the WG, made their Decision on some
> ISSUEs, I see almost *nothing but* emails about the subject matter of the
> ISSUEs or about the fallout of the decisions coming from public-html.
> Evidently, giving dissenters the benefit of due process didn't bring the ISSUEs
> to closure. We have both attention-exhausting permathreads *and* a heavyweight
> process. 

I haven't fully caught up on the last two weeks of email, but I can see your point that there have been lengthy threads on the fallout from the last few decisions. 

> I think this is a sign of the Decision Process not working properly. It is
> possible that this isn't a bug in the Decision Process document per se, but in
> the application of the process. Emphasizing the a Decision applies "at this
> time" is effectively an invitation to continue discussion instead of bringing
> the ISSUEs to closure.

I think we need to be more clear about the finality of Working Group Decisions, and encourage participant only if at least one of the following holds:

(a) They have new information which was not available at the time of the decision.
(b) They would like to raise a Formal Objection to the decision.
(c) They would like to enter an objection to the decision on the record, without raising a Formal Objection.

In particular, the participants who made dozens of posts about a decision without providing new information should have been advised to proceed otherwise or take discussion elsewhere.

That being said, I am hesitant to jump into those threads now, as most of them seem to have petered out a few days ago and I would not want to rekindle the flames. The "request for editing guidance" thread continues, so I will read that closely and see if any course correction is needed.

That being said: while there has been a burst of discussion about the last few issues to be resolved, there have been at least 36 total issues have been resolved since the decision policy has been adopted. For most of these resolved issues, there are no ongoing permathreads and the results of the process are generally accepted. So I am not sure it is correct to generalize from the last three issues resolved to the process in general.

(In reply to comment #0)
> I gather an important point of the Decision Policy is to manage dissent by
> establishing a due process for dealing with the dissent as opposed to having
> permathreads of claims that a particular concern hasn't been duly considered by
> the WG as a whole to go on indefinitely taking the attention of the WG
> participants and interfering with productive work at the WG.
> 
> Before the current Decision Policy was put in place, the idea of soliciting
> concrete proposals (now termed Change Proposals) was accompanied by a reference
> to
> http://bitworking.org/news/Camera_Ready_Copy_and_the_Social_Denial_of_Service_Attack
> (See http://lists.w3.org/Archives/Public/public-html/2009Jan/0385.html)
> 
> While pointing to
> http://bitworking.org/news/Camera_Ready_Copy_and_the_Social_Denial_of_Service_Attack
> doesn't explicitly say that a substantial reason for soliciting concrete
> proposals is avoiding Social Denial of Service Attacks, I think it was
> reasonable for readers of the 0385 email to infer that what later developed
> into the Decision Process was supposed to limit behavior that would tie up the
> finite attention of WG participants. I posit that this reasonable inference may
> have played a substantial part in getting the WG to agree to a heavyweight
> Decision Process. At least I thought that the end points of the Process were
> supposed to be end points of attention-exhausting activities around a given
> ISSUE.
> 
> Now that the Chairs have, on behalf of the WG, made their Decision on some
> ISSUEs, I see almost *nothing but* emails about the subject matter of the
> ISSUEs or about the fallout of the decisions coming from public-html.
> Evidently, giving dissenters the benefit of due process didn't bring the ISSUEs
> to closure. We have both attention-exhausting permathreads *and* a heavyweight
> process. 
> 
> I think this is a sign of the Decision Process not working properly. It is
> possible that this isn't a bug in the Decision Process document per se, but in
> the application of the process. Emphasizing the a Decision applies "at this
> time" is effectively an invitation to continue discussion instead of bringing
> the ISSUEs to closure.

I believe you exaggerate. 

What permathread? There was a discussion about a couple of recent decisions recently because both parties who submitted proposals (original and counter) questioned the fact that our objections were not addressed. I have since filed a bug in the decision process to ask the co-chairs to address all objections--those stated in the surveys, and those in the counter-proposals. And I'm keeping my options open as to whether to file a formal objection. 

Later, the discussion varied into the fact that neither hidden nor accessible is fully accessible at this time, and a lively discussion ensued about how to make it so. Not surprising: the decision was to keep both, but problems still exist with both.

Do you expect that one decision means there is no discussion about the elements? Even if the elements, as they are defined, are problematic?

There are no permathreads. There is a new discussion based on a formal objection for continuing to include links to the WhatWG document within the W3C HTML5. And the HTML5 editor seems to be unhappy with most, if not all, co-chair decisions.

(In reply to comment #0)

When we count how many times Ian (and  other WHATwg members) have mentioned the word "Microdata"
this week, then it is tempting to answer "yes" to your claim that the process is not working.

(In reply to comment #0)

> Now that the Chairs have, on behalf of the WG, made their Decision on some
> ISSUEs, I see almost *nothing but* emails about the subject matter of the
> ISSUEs or about the fallout of the decisions coming from public-html.

Ian explained, the day before you filed this bug, why <figure> still needs discussion by calling it "even more so" immature than microdata: [1] http://lists.w3.org/Archives/Public/public-html/2010Jun/0218

]] 0002 cited above and the microdata decision cited above put forward nearly 
identical arguments, yet reach diametrically opposite conclusions. Both 
microdata and <figure> have been specified, have rationale, have support 
from implementors and developers, have counter-proposals that are also 
specified (in the case of <figure>, HTML4+ARIA, in the case of 
microdata, RDFa), both could be specified in a modular fashion, though 
in both cases doing so results in a fractured language, both are 
intrinsically part of HTML though in both cases an argument could be made 
that it could be turned into a generic vocabulary, both are immature 
(<figure> even more so), and so on. [[

And, also, the chairs, represented by Sam, when the decisions where announced, encouraged the group to identify problems and file bugs. I therefore feel that you  turn everything on it head wiht this bug. 

The one thing that almost *all* that took part in the debate after the vote *did* share was that most of us do not have any alternative spec where we can place those things that we do not get as we want!!! What many of the participants *did not* share, was the vote: Most of the accessibility oriented WG participants were for keeping all these features. Thus, you did not watch a debate between "

When it comes to "bugs in the process": 

The "keep the elements" crowd found it much too easy to gather around a anti-Shelley totem. I really wonder why they did not try to behave more nicely so that they could win over weak souls for their cause that way. It scares me that this was so unimportant for them. That said, if there had been a way for the chairs to encourage Shelley to working herself to a compromise with the group, then I think that would have been very good.  So I don't think the decission process is wrong per se, but I would like that there were more encouragement to work for consensus built into it.

s/Thus, you did not watch  debate between "/Thus, you did not watch a debate between 'dissenters'.

Sorry, the following:

Later, the discussion varied into the fact that neither hidden nor accessible
is fully accessible at this time, and a lively discussion ensued about how to
make it so. Not surprising: the decision was to keep both, but problems still
exist with both.

Should be:

Later, the discussion varied into the fact that neither figure nor aside
is fully accessible at this time, and a lively discussion ensued about how to
make it so. Not surprising: the decision was to keep both, but problems still
exist with both.

(In reply to comment #2)
> I think we need to be more clear about the finality of Working Group Decisions,
> and encourage participant only if at least one of the following holds:
> 
> (a) They have new information which was not available at the time of the
> decision.

That seems like a valid reason to reopen a Decision.

> (b) They would like to raise a Formal Objection to the decision.

The Process document says: "When the Chair believes that the Group has duly considered the legitimate concerns of dissenters as far as is possible and reasonable, the group SHOULD move on."
http://www.w3.org/2005/10/Process-20051014/policies.html#managing-dissent

After a Decision, the Working Group Decision Policy has already provided due consideration. If someone merely upgrades into an FO a previous expression of disagreement that the chairs have already considered, I think the FO should just be recorded and the group should move on. Otherwise, the procedure would be vulnerable to DoS by FO.

> In particular, the participants who made dozens of posts about a decision
> without providing new information should have been advised to proceed otherwise
> or take discussion elsewhere.

Indeed.

> That being said: while there has been a burst of discussion about the last few
> issues to be resolved, there have been at least 36 total issues have been
> resolved since the decision policy has been adopted. For most of these resolved
> issues, there are no ongoing permathreads and the results of the process are
> generally accepted. So I am not sure it is correct to generalize from the last
> three issues resolved to the process in general.

Fair point.

(In reply to comment #2)
  [...]
> In particular, the participants who made dozens of posts about a decision
> without providing new information should have been advised to proceed otherwise
> or take discussion elsewhere.

This is a misrepresentation of the discussion.

(In reply to comment #9)
> (In reply to comment #2)
>   [...]
> > In particular, the participants who made dozens of posts about a decision
> > without providing new information should have been advised to proceed otherwise
> > or take discussion elsewhere.
> 
> This is a misrepresentation of the discussion.

Indeed.

(In reply to comment #8)
> (In reply to comment #2)
> > I think we need to be more clear about the finality of Working Group Decisions,
> > and encourage participant only if at least one of the following holds:
> > 
> > (a) They have new information which was not available at the time of the
> > decision.
> 
> That seems like a valid reason to reopen a Decision.
> 
> > (b) They would like to raise a Formal Objection to the decision.
> 
> The Process document says: "When the Chair believes that the Group has duly
> considered the legitimate concerns of dissenters as far as is possible and
> reasonable, the group SHOULD move on."
> http://www.w3.org/2005/10/Process-20051014/policies.html#managing-dissent
> 
> After a Decision, the Working Group Decision Policy has already provided due
> consideration. If someone merely upgrades into an FO a previous expression of
> disagreement that the chairs have already considered, I think the FO should
> just be recorded and the group should move on. Otherwise, the procedure would
> be vulnerable to DoS by FO.

The HTML WG decision process does not trump W3C procedures [1].

> 
> > In particular, the participants who made dozens of posts about a decision
> > without providing new information should have been advised to proceed otherwise
> > or take discussion elsewhere.
> 
> Indeed.
> 
> > That being said: while there has been a burst of discussion about the last few
> > issues to be resolved, there have been at least 36 total issues have been
> > resolved since the decision policy has been adopted. For most of these resolved
> > issues, there are no ongoing permathreads and the results of the process are
> > generally accepted. So I am not sure it is correct to generalize from the last
> > three issues resolved to the process in general.
> 
> Fair point.

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

(In reply to comment #0)
> Emphasizing the a Decision applies "at this
> time" is effectively an invitation to continue discussion instead of bringing the ISSUEs to closure.

If decisions allow features to be improved, discussion on them should not be stifled. It should be encouraged. Brainstorming and negotiation are critical factors for consensus, which is a core W3C value.

(In reply to comment #5)
> The "keep the elements" crowd found it much too easy to gather around 
> a anti-Shelley totem. I really wonder why they did not try to behave 
> more nicely so that they could win over weak souls for their cause 
> that way. It scares me that this was so unimportant for them. 

I agree, Leif. Instituting some list guidelines may be helpful. For instance:

* Don't attack a person. Disagree with an idea.
* Respect the right of others to disagree.
* Tone of messages must be maintained at the highest level of professionalism; flaming, sarcasm, or personal attacks will not be tolerated. 
* Be polite and show respect. If you have nothing positive, informative or helpful to say, refrain from sharing it.
* Debate; Don't argue.
* Listen; Don't shout.

Some sample list guidelines:

http://webdesign-l.com/policies/#etiquette
http://lists.evolt.org/index.php?content=listinfo
http://www.wise-women.org/about/guidelines/
http://www.river.com/users/share/etiquette/
http://css-discuss.incutio.com/?page=PostingGuidelines
http://css-discuss.incutio.com/?page=OffTopic
http://webstandardsgroup.org/mail/guidelines.cfm
http://www.sigchi.org/resources/web/guidelines.html/
http://www.w3.org/QA/IG/Lists
http://it.coe.uga.edu/itforum/

(In reply to comment #12)
> (In reply to comment #0)
> > Emphasizing the a Decision applies "at this
> > time" is effectively an invitation to continue discussion instead of bringing the ISSUEs to closure.
> 
> If decisions allow features to be improved, discussion on them should not be
> stifled. It should be encouraged. Brainstorming and negotiation are critical
> factors for consensus, which is a core W3C value.
> 
> (In reply to comment #5)
> > The "keep the elements" crowd found it much too easy to gather around 
> > a anti-Shelley totem. I really wonder why they did not try to behave 
> > more nicely so that they could win over weak souls for their cause 
> > that way. It scares me that this was so unimportant for them. 
> 
> I agree, Leif. Instituting some list guidelines may be helpful. For instance:
> 
> * Don't attack a person. Disagree with an idea.
> * Respect the right of others to disagree.
> * Tone of messages must be maintained at the highest level of professionalism;
> flaming, sarcasm, or personal attacks will not be tolerated. 
> * Be polite and show respect. If you have nothing positive, informative or
> helpful to say, refrain from sharing it.
> * Debate; Don't argue.
> * Listen; Don't shout.

Over-relying on tone or word use doesn't encompass acts that, when taken separately are innocuous, but when combined are based more on a response against an individual rather than an idea. People can be polite but still act counter to what's best for the HTML5 spec, and for all web communities. Politeness in word is nothing if its not matched by openness in action. 

I would rather those who wanted to universally keep elements had argued each, individually. I believed then, and continue to believe now, that the arguments presented against my change proposals were weak, and based on politics rather than technology. In fact, there were few technical objections and many political -- based on emails and philosophical assertions rather than anything quantifiable. 

However, where the co-chairs failed, and badly, is by tolerating disrespect for the change proposal process by allowing a grouped response--even though the change proposals were about individual items. 

It is the co-chair response and behavior that actually opens this item up for formal objection, because the chairs did not follow their own established change proposal process. 

The Decision Process, when applied equitably and consistently, can work. Where it fails is when the application of the process is neither equal, nor consistent. Might as well file a bug against the co-chairs, as against the process.

 
> 
> Some sample list guidelines:
> 
> http://webdesign-l.com/policies/#etiquette
> http://lists.evolt.org/index.php?content=listinfo
> http://www.wise-women.org/about/guidelines/
> http://www.river.com/users/share/etiquette/
> http://css-discuss.incutio.com/?page=PostingGuidelines
> http://css-discuss.incutio.com/?page=OffTopic
> http://webstandardsgroup.org/mail/guidelines.cfm
> http://www.sigchi.org/resources/web/guidelines.html/
> http://www.w3.org/QA/IG/Lists
> http://it.coe.uga.edu/itforum/

(In reply to comment #8)

> 
> > (b) They would like to raise a Formal Objection to the decision.
> 
> The Process document says: "When the Chair believes that the Group has duly
> considered the legitimate concerns of dissenters as far as is possible and
> reasonable, the group SHOULD move on."
> http://www.w3.org/2005/10/Process-20051014/policies.html#managing-dissent
> 
> After a Decision, the Working Group Decision Policy has already provided due
> consideration. If someone merely upgrades into an FO a previous expression of
> disagreement that the chairs have already considered, I think the FO should
> just be recorded and the group should move on. Otherwise, the procedure would
> be vulnerable to DoS by FO.

I'm not saying that raising a Formal Objection is a valid reason to reopen a decision. Rather, it is a valid reason for a WG participant to post in response to a decision.

(In reply to comment #13)
> 
> Over-relying on tone or word use doesn't encompass acts that, when taken
> separately are innocuous, but when combined are based more on a response
> against an individual rather than an idea. People can be polite but still act
> counter to what's best for the HTML5 spec, and for all web communities.
> Politeness in word is nothing if its not matched by openness in action. 
> 
> I would rather those who wanted to universally keep elements had argued each,
> individually. I believed then, and continue to believe now, that the arguments
> presented against my change proposals were weak, and based on politics rather
> than technology. In fact, there were few technical objections and many
> political -- based on emails and philosophical assertions rather than anything
> quantifiable. 
> 
> However, where the co-chairs failed, and badly, is by tolerating disrespect for
> the change proposal process by allowing a grouped response--even though the
> change proposals were about individual items. 

The Chairs initially asked you to submit change proposals for your issues staggered, instead of all at once. You insisted on submitting them all at once. Therefore, we took steps to prevent this from overburdening the group. The resulting Change Proposal did in fact individually address all six issues.

In any case, you have made this point before. I don't think repeating it at every opportunity is helpful.
 
> It is the co-chair response and behavior that actually opens this item up for
> formal objection, because the chairs did not follow their own established
> change proposal process. 

If you'd like to raise a Formal Objection against any of the decisions, go ahead. I don't think this bug is the appropriate place to comment on your possible intent to do so.

(In reply to comment #15)
> (In reply to comment #13)
> > 
> > Over-relying on tone or word use doesn't encompass acts that, when taken
> > separately are innocuous, but when combined are based more on a response
> > against an individual rather than an idea. People can be polite but still act
> > counter to what's best for the HTML5 spec, and for all web communities.
> > Politeness in word is nothing if its not matched by openness in action. 
> > 
> > I would rather those who wanted to universally keep elements had argued each,
> > individually. I believed then, and continue to believe now, that the arguments
> > presented against my change proposals were weak, and based on politics rather
> > than technology. In fact, there were few technical objections and many
> > political -- based on emails and philosophical assertions rather than anything
> > quantifiable. 
> > 
> > However, where the co-chairs failed, and badly, is by tolerating disrespect for
> > the change proposal process by allowing a grouped response--even though the
> > change proposals were about individual items. 
> 
> The Chairs initially asked you to submit change proposals for your issues
> staggered, instead of all at once. You insisted on submitting them all at once.
> Therefore, we took steps to prevent this from overburdening the group. The
> resulting Change Proposal did in fact individually address all six issues.
> 

Your request was inappropriate, because my change proposals were based on the fact that the editor didn't respond for months on the bugs, and then responded all at once. 

I was not the instigator in the timing of these issues. As it was, the artificial grouping impacted on the discussion of the various points -- something that was obvious when you look at the varying responses to the items in the surveys. 

The co-chairs failed their first obligation: ensuring the editor responded in a timely and complete manner. It is his actions that triggered the grouping, not mine.


> In any case, you have made this point before. I don't think repeating it at
> every opportunity is helpful.
>

It is still a pertinent point and one that demonstrates the failure of the co-chairs to apply the Decision process in a equitable, and consistent manner. 
 
> > It is the co-chair response and behavior that actually opens this item up for
> > formal objection, because the chairs did not follow their own established
> > change proposal process. 
> 
> If you'd like to raise a Formal Objection against any of the decisions, go
> ahead. I don't think this bug is the appropriate place to comment on your
> possible intent to do so.


It is actually the best place to bring this up. Henri is stating that the discussion that followed the recent Figure/Aside decision demonstrates that the decision process fails because it does not stop the discussion. 

I responded with two clarifications:

The first was that much of the discussion had to do with the fact that since aside and figure were staying in the HTML5 spec, there were issues with both, including the fact that they're inaccessible, as currently worded in the document. This was an entirely appropriate, in fact essential, discussion to have. 

The second clarification I made is that Henri's perceived failure of the process isn't to do with the Decision process, but the co-chairs application of the Decision process. The co-chairs did not reference the objections in either the change proposals, or the singular counter-proposal. I further believe that the decisions were that much incomplete, because the co-chairs did not apply the Decision process in an equitable and consistent manner. 

It is, indeed, appropriate to this bug discussion. To me, all combined, I don't think we're finding a failure in the decision process. I think the failure was in the co-chairs application of the decision process. 

You may disagree with my assertion, but I don't see how you can disagree with it somehow being outside the scope of this bug.

(In reply to comment #13)

> by allowing a grouped response--even though the
> change proposals were about individual items. 

Lumping all one person's proposals together, could be seen as a type of personal attack. "Let's dispense with this in one feld swoop, as this person is not worth the time to examine their ideas individually." 

(In reply to comment #15)

> The Chairs initially asked you to submit change proposals for your issues
> staggered, instead of all at once. You insisted on submitting them all at once.
> Therefore, we took steps to prevent this from overburdening the group. The
> resulting Change Proposal did in fact individually address all six issues.

Could the Chairs have staggered the call for counter proposals? 

The Chairs did in fact make decisions on each issue separately, although the rationale presented in those change proposals was not addressed in the decisions. (Bug 9901).

It is possible, however, that grouping proposals was because of the push to get to last call...expediency. 

I am not sympathetic to the expediency plea, due to prior management failures. 

Management had little interest in putting out fires during the first two and a half years of the HTMLWG. Accessibility needs were fumbled by the editor. WAI was slow as molasses responding. Both PF and WHATWG have displayed elitist/condescending attitudes which didn't help matters. We have no agreed to design principles. The HTMLWG had no decision process for two and a half years. Even now it is not a real consensus policy. It is a decision policy.

So now work is backed up. Three years worth of work needs to be completed in a few months. 10 pounds of projects need to be through a 2-pound pipeline in a multi-project environment. It is unrealistic. Either the timeline needs to be moved out; the deliverables need to be trimmed; or more resources need to be obtained. 

Management needs to deal with it.

(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #13)

> This was an entirely appropriate, in fact essential, discussion to have. 

Indeed. Further editing where said to be self-evident. [1] And the <figure>
result announcement ended with an encouragment from the co-chairs "to write
specific and actionable bug reports on areas where this element is deficient".
[2]

[1] http://www.w3.org/mid/4C0D20A3.3080902@intertwingly.net
[2] http://www.w3.org/mid/4C058372.4020307@intertwingly.net

> The second clarification I made is that Henri's perceived failure of the
> process isn't to do with the Decision process, but the co-chairs application of
> the Decision process. 

Apart from a possible need to adjust the expectations (see above), there is
also such a thing as «simply won, easy lost». I agree that a process that is
felt "free and fair" and respectful by all, is likely to cause less debate in
the aftermath. And thus I agree that the way this process developed, may
negatively have affected the how the "winners" experienced their "vicotry"  it
didn't become the end station they had hoped. 

So I would encourage the the co-chairs to make sure that the decision process
is taken very seriously, *also* in the cases when the outcome of the process is
easy to predict.

It is true that at the time this bug was filed, there was a great deal of contentious discussion regarding some of the decisions that had recently been published. However, discussion has since died down and we have closure on those issues. In addition, the Chairs have since published further decisions which did not instigate the same kind of out of control discussions.

The Chairs believe we need to be vigilant to ensure that the outcome of contentious issues is handled gracefully, but we believe the decision policy is in fact effective at getting closure on ISSUEs, and so, no change to the process is needed.

Happening again: http://lists.w3.org/Archives/Public/public-html/2010Aug/0237.html

(In reply to comment #20)
> Happening again:
> http://lists.w3.org/Archives/Public/public-html/2010Aug/0237.html

Henri, you are entitled to an opion, of course. But so are the co-chairs. And Paul Cotton just spoke, on their behalf:[1]

]]
We do not plan to take any action on your formal objection at this time due to:

1) the active and potentially productive discussion going on,
[[

[1]  http://lists.w3.org/Archives/Public/public-html/2010Aug/0290.html