On Jan 26, 2010, at 7:21 PM, Maciej Stachowiak wrote: > 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.
We now have a bugzilla component, so I filed the issues that may need changes to the policy in bugzilla. See below: > > On Jan 14, 2010, at 5:54 PM, Larry Masinter wrote: > >> 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. "Clarify how Change Proposals get reviewed and what happens to Change Proposals that do not meet requirements" http://www.w3.org/Bugs/Public/show_bug.cgi?id=8893 >> 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. "Document process for counter-proposals and alternate proposals" http://www.w3.org/Bugs/Public/show_bug.cgi?id=8894 >> 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. "Document policy for First Public Working Drafts" http://www.w3.org/Bugs/Public/show_bug.cgi?id=8895 >> 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. Covered by the previous bug. >> 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. "Clarify that anyone who is dissatisfied with a bug resolution may reopen or escalate" http://www.w3.org/Bugs/Public/show_bug.cgi?id=8896 >> 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. Not tracked because we don't think any change to the Decision Policy document is needed. >> 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. Not tracked because we don't think any change to the Decision Policy document is needed. >> 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. Covered by <http://www.w3.org/Bugs/Public/show_bug.cgi?id=8895> cited above. >> 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. Not tracked because we don't think any change to the Decision Policy document is needed. >> 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. Not tracked because we don't think any change to the Decision Policy document is needed. Regards, Maciej
