Re: Request for clarifications and expansions in "decision policy" document

>
> Hi Larry,
>
> Thank you for your feedback. The chairs discussed your comments in detail. We agree that some things should be revised in the Decision Policy document, or else documented separately. And we'd like to answer your questions where you ask for clarification.
>
> As far as general process for updating the policy: we'd like to have some way to track requests for change or clarification, and we will have a bugzilla component set up. At that time, we'll make sure all your requests are recorded. When we have an updated version ready, we will put it before the group in the same way as the original.
>
> In the meantime, we will give you our tentative thoughts on what kind of changes are likely needed.
>
>    

Any changes to the procedure need to be communicated to the HTML WG, and 
comments about such changes should be requested.

There needs to be a good reason for the change, because the chairs 
proposed this procedure, and as far as I can see, only the chairs seem 
to be changing it.

> On Jan 14, 2010, at 5:54 PM, Larry Masinter wrote:
>
> >  In a previous discussion about process, someone said:
> >
> >>  I'd really like to see this turned
> >>  into concrete input on how we can do it differently.
> >
> >  Now that there is some experience with the "decision policy"
> >  http://dev.w3.org/html5/decision-policy/decision-policy.html
> >  I think it would be very helpful to revise it to cover
> >  items that we seem to be doing even if not described,
> >  and even some gaps where "we'll figure it out when
> >  we get to it".
> >  ----
> >  Things we seem to be doing although not documented,
> >  and might be put into the "decision policy":
> >
> >  In the escalation process, the chairs review change
> >  proposals, and ask for resubmission if they believe
> >  the change proposal doesn't meet the requirements for
> >  a change proposal. It's not clear how many times this
> >  can happen or whether it affects the deadline.
>
> Carification: When we give review feedback of this kind it is as a courtesy to the submitter of the Change Proposal. We will try to do it, but it's not mandatory for us to do it, or for anyone to take our suggestions. Once a Change Proposal is submitted, there is no firm deadline. The author of the Change Proposal can make revisions up until the time we are ready to call for consensus, issue a poll, or otherwise drive to a decision. Others can also submit additional Change Proposals. Thus, suggesting improvements can happen any number of times and does not affect any deadlines.
>
> Possible Policy Update: We think the Decision Policy should state that Change Proposals that do not meet the formal requirements for a Change Proposal will fail; but Change Proposal authors will be given ample opportunity to make revisions and resolve any problems.
>
> >  Once a change proposal is accepted, the chairs seem to
> >  be soliciting counter-proposals, or even "no change
> >  proposals".
>
> Clarification: We think this is a reasonable elaboration on what the policy calls for, but we agree that at this point it should be documented properly.
>
> Possible Policy Update: We will probably make the call for counter-proposals and alternate proposals a formal part of the policy. It has become an important enough part of how we work to be fully documented.
>
>    

If the process is changed to make this call _after_ the initial change 
proposal period, then I disagree with this vehemently.

This not only extends the period of time when a discussion occurs, it 
effectively gives those who want to support the status quo twice the 
amount of time to write the change proposals, as those wanting a change.

If people want to defend the status quo, or the existing specification 
text, they should do so at the same time as those of us wanting the 
change. The zero-edit change proposals should be based on a defense of 
the spec, not waiting to pick apart what the people writing change 
proposals write. The discussion and update period should allow for that.

You all keep throwing obstacles in our path. The editor can make any 
change he wants, such as adding the new srcdoc attribute, but then we 
have to go through the whole bug/change proposal process to reverse his 
quick edit out. As it stands now, when we do write the change proposal, 
then, and only then, is the call for a counter or alternative change 
proposal made. A counter proposal is a zero-edit proposal, and should be 
completed at the same time as the initial change proposal. Alternative 
proposals should be incorporated into the discussion, as happened with 
the dd/dt issue discussion (which somehow has seemingly faded away into 
non-completion). One proposal period, and a discussion/modification 
period following. That's it. Clean, simple, fair.

I will support a change in the procedure, if is is modified to ensure 
that calls for proposals happen at the same time. I will not support a 
change in the procedure that not only extends the period of time to 
resolve these issues, but also puts undue burden on those seeking change.

Shelley