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. 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 a bug resolution results in the document being > split, we seem to be doing a CfC for publishing the > split parts as FPWD. Clarification: Publication of a new FPWD is a separate process from the Decision Policy. Anyone can bring forward a draft at any time, and whether it was produced as the result of a bug resolution is irrelevant. The existence of a bug does not remove the need for the standard Call for Consensus that we do in such cases. Possible Policy Update: The Chairs believe that we should write a separate document on the policy for publishing new documents as a First Public Working Draft. We believe the requirements for a new publication should be fairly minimal, but at the same time we feel it is only fair that the requirements should be documented. This will likely be a separate document from the current Decision Policy, but it may end up a new section in the current policy. > ---- > Things that aren't clear: > > After CfC for FPWD, it isn't clear what happens > if there isn't consensus. Clarification: The general expectations are documented in the W3C Process Document here: <http://www.w3.org/2005/10/Process-20051014/tr.html#first-wd>. In particular, "Consensus is not a prerequisite for approval to publish; the Working Group may request publication of a Working Draft even if it is unstable and does not meet all Working Group requirements." Thus, consensus is not required and it is possible to proceed notwithstanding lack of consensus. But it is also likely that the Chairs will seek to have objections addressed if there is an obvious practical path to doing so. Possible Policy Update: We'll probably say something more specific when documenting the procedure for FPWD. > > What happens when: > (1) a bug is submitted, (2) the editor responds, > (3) the person reporting the bug is satisfied with the > change, but (4) other working group members are not? > Do working group members watch bug fixes and then > open new bugs? Clarification: Any Working Group member who is dissatisfied with a bug resolution may reopen the bug or escalate to an issue, even if he or she is not the one who originally filed the bug. This is the intent of the policy, and we have given this clarification before, but we should make it more clear. Possible Policy Update: Make the above clarification manifest in the wording. > > When (as happened) a "bug fix" results in a split of > the spec, and a working group member is unhappy about > the split, which document should one file a bug > report on? Clarification: Short version: It doesn't matter. Long version: If a split results from a bug resolution, any Working Group member who is dissatisfied may reopen the original bug or escalate it to the tracker. Alternately, if there wasn't a bug in the first place, or if the WG member didn't notice, then he or she could file a new bug against either document. It does not matter much, because we can reassign bugs if necessary. The key is that the result should be either an open bug, or an open issue escalated from a resolved bug. If the commenter broadly agrees with the split, but is dissatisfied with some particular details, then it is probably better to file bugs about those details. Reopening or escalating are better options if the commenter thinks the split should be reverted or should be done along substantially different lines. > > There were some "commitments" made when issues were > closed (for example, the commitment to maintain > the author-only view of the specification, presumably > also as a W3C edition?). Can issues be re-opened > if those commitments aren't followed? Clarification: Any issue may be re-raised if new information comes to light. If resolving the issue in the first place was based in part on an assumption of some future action, and that action does not take place, then that would be relevant new information. Short version: yes. However, we would prefer if such failures to meet expectations were first communicated to the group, and ideally documented in the form of bugs. > > Is the previous policy of allowing new drafts > to be published as long as there are three independent > contributors still part of the working > group decision policy? Clarification: We believe that this should be part of the minimum requirements for a new draft, and that overall the bar should be fairly low. But it is not the only relevant requirement. Drafts should be meaningfully related to the Working Group's work, for example. We think the requirements and process should be formally documented. Possible Policy Update: We will document the process for seeking publication of a new draft. > > What is the decision process is for abandoning > a document or moving it somewhere else once it's > past FPWD. Is the default that all documents that > pass FPWD will have the presumption of making it > through last call if "change proposals" aren't > completed. Would "drop entire document" be an > acceptable "change proposal"? (That is, if we > publish Microdata as a FPWD, will it by default > be published as a PR?) Clarification: Changing a draft's status in this way would require a Working Group decision on the draft. We think the usual Decision Policy applies - file a bug and escalate to issue and then Change Proposal if necessary. Basically this amounts to changing the status to non-normative, and possibly adding a note indicating that the work item is abandoned and should not be referenced as a standards-track document. This can follow the same procedure as any other kind of spec change. As to your parenthetical remark, no document that goes to FPWD will be published as a PR "by default". Proceeding to Last Call will require a Working Group Decision. Exiting Last Call to go to CR will require a Working Group Decision as well as agreement to the transition by the Director and the Team. Exiting CR to go to PR will likewise require a Working Group Decision as well as agreement to the transition by the Director and the Team. It would probably be good for the Working Group to establish some criteria that drafts should meet before being considered for Last Call, but that has not been established yet. > > The decision policy should probably also cover > the questions around whether work is or isn't in > scope of the working group charter. It seems like > the process is that after discussion, if there > isn't a resolution, the chairs will make a > "chairs decision" on the interpretation of the > charter? Clarification: We think it is fair game for Working Group members to apply their opinions of what is in scope in deciding whether to support or advance work. We would rather not see lengthy discussions about scope on public-html. If anyone is unhappy with a Working Group decision because he or she feels a work item is outside the scope of the charter, then that participant may ask the Chairs to consult with the Team on the proper interpretation of the Charter. If the participant is unhappy with the result of that consultation, then the usual avenues for recording disagreement apply, including stating an ordinary objection for the record, raising a Formal Objection, or if he or she feels that due process was not given, report concerns to one of the Team Contacts. We will let you know as soon as we have a way to track these suggested changes, and we will make sure the Working Group has a chance to weigh in on any proposed revisions of a document. Regards, Maciej
