Re: Draft Decision Policy update

Here's my comments on reviewing this:

On Aug 14, 2012, at 4:11 PM, Sam Ruby <rubys@intertwingly.net> wrote:

> 
> Note that this is DRAFT. While most of the bugs addressed changes have been available for review since April with little feedback, the document which contains these changes has not been reviewed by W3C management, my co-chairs, or the editors.
> 
> Decision Policy v3 has been updated to reflect the changed identified in the Stabilization plan. Retroactive changes are fixed in place. New additions for LC2 are consolidated to a new section.
> Specifics:
> 
> 16481: Establish a feature freeze - no adding of new features based on bug or editor's discretion, without prior WG approval
> 
> Last feedback 2012-04-10
> Applied patch. Note this is retroactive.

Looks fine.

> 
> 16674: Feature discouragement in issue process - can use "too late to add features" as a technical argument in a counter-proposal
> 
> Last feedback 2012-04-10
> Applied patch. Note this is retroactive.
Looks fine.

> 
> 12734: Starting with LC2 or perhaps before, all changes need to be associated with a duly filed LC2 or earlier bug
> 
> Last feedback 2012-04-10
> Applied patch, then made the following changes:
> changed expect to require. This is based on feedback from the editors.
> moved to Second Last Call Process Additions section

I know we checked this with the new editors of HTML5 and HTML Canvas 2D Context. Are the editors of our other Last Call track drafts ok with this? (That would be HTML+RDFa, Microdata, Polyglot, and Techniques for Text Alternatives.) Assuming they agree, I am fine with this. These other deliverables have a lower rate of change but may also have spottier responsiveness.

> 
> 16675: Switch to a review-then-commit model for spec development
> 
> Last feedback 2012-04-10
> Created new text. This is based on discussion with the editors.
I have two issues with the new text, I think it is at the same time too much and not enough. Let me explain.

1) I don't think 72 hour notice is sufficient to expect WG members to thereafter hold their peace. The norm in this group is one week notice, and we have many participants who are interested in our activities, but participate part-time and asynchronously.

2) I don't think it is appropriate to make review-then-commit mandatory at this time. Most changes do not lead to controversy or demands for revert; rare exceptions do. Mandatory RTC with a minimum waiting period would introduce friction into the process just to deal with exceptional cases. I am not sure we should optimize so completely for the worst case at the expense of the common case. There are may changes that could quite reasonably just go in (e.g. simple editorial changes, applying WG decisions, obvious fixes to bugs already in the system for some time, etc).

What I would propose instead is that we move to optional RTC. That is, editors have the option to preflight changes with the WG, and if they do so for a period of at least a week, then that change is not subject to the revert policy. Editors are strongly encouraged to preflight any change that might be controversial. We did not go this route before because we did not have an editor who wanted to apply such judgment, nor the confidence that such judgment would be in accordance with views of the wider WG. I suggest that we give our new editors some trust in their judgment, and only move to mandatory RTC if optional RTC does not work out, or else upon entry to CR (after which we should make very few changes).


> 
> 13306: Establish a deadline for implementation of WG Decisions
> 
> Last feedback 2012-04-10
> Applied patch, then made the following change:
> changed one month to one week. This is based on feedback from the editor.

I know we checked this with the new editors of HTML5 and HTML Canvas 2D Context. Are the editors of our other Last Call track drafts ok with this? (That would be HTML+RDFa, Microdata, Polyglot, and Techniques for Text Alternatives.) Assuming they agree, I am fine with this. These other deliverables have a lower rate of change but may also have spottier responsiveness.

> 
> 16676: Limit scope of LC2 bugs to relate to items that were changed since LC1
> 
> Last feedback 2012-05-03
> Applied patch, then made the following changes:
> Added "All bugs entered outside of this scope are to be reassigned to components set up for HTML.next activities."
> Added "In rare cases, editors may select individual bugs, ensure that there is a proposed change, and submit such for approval to the Working Group. "
> moved to Second Last Call Process Additions section
Looks ok to me with your edits.

> 
> Related links:
> 
> Stabilization plan
> Decision Policy v2
> bugs
> - Sam Ruby
>