This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Larry Masinter wrote: "If a bug resolution results in the document being split, we seem to be doing a CfC for publishing the split parts as FPWD. " I replied: "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." We should definitely document the FPWD requirements somewhere.
Larry also wrote: "After CfC for FPWD, it isn't clear what happens if there isn't consensus." And I replied: "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."
All of the special HTML-WG-only processes should be described in a single document; if there are separate sections for the decision policy for working group comments, accepting an editor's draft (three submitters?), publishing documents as FPWD after split (?) , and responding to other working groups, that's fine, but having them together so that participants can actually understand what the actual practices are would seem to be a fundamental requirement for "transparency": that everyone who might engage in a process (or even just be called on to review the results of a process) actually knows what the rules are and have been -- not just those who have been following for years.
Strawman resolution: Because FWPD proposals don't happen often and we don't expect too many more, the Chairs do not expect to document this process in the upcoming revision of the Decision Policy. We do expect to document it separately at a later time, if needed.
Reopening; this bug was marked resolved inadvertantly.
Per comment #3, I propose we mark this RESOLVED LATER.
The Chairs agreed to mark this RESOLVED LATER.
Reopening as we have our first FPWD draft request that is generating objections: http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/thread.html#msg102 Given that we have established that a preference poll can be used to terminate work on a draft and publishing the result as a Note, perhaps we should consider employing a similar process for establishing support for a FPWD over which there isn't absolute consensus? http://dev.w3.org/html5/decision-policy/decision-policy-v3.html#note-vs-rec https://www.w3.org/2002/09/wbs/40318/microdata-status-preference-poll/results