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
