This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12776 - Define process for deciding whether a draft is REC-track or Note-track
Summary: Define process for deciding whether a draft is REC-track or Note-track
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: working group Decision Policy (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11y_text-alt
Depends on:
Blocks:
 
Reported: 2011-05-25 08:05 UTC by Maciej Stachowiak
Modified: 2011-06-27 10:04 UTC (History)
8 users (show)

See Also:


Attachments

Description Maciej Stachowiak 2011-05-25 08:05:44 UTC
Whether a Working Draft eventually becomes a WG Note or proceeds down the REC track is a decision of the Working Group. We should define a process for the WG to do so. A likely outline would be:

- Starts with a bug report. If no one objects to the proposed change, then the matter can be resolved without taking it to the full WG.
- If anyone objects, then we will ask proponents of both REC-track and Note-track to provide rationale.
- We will likely use a more lightweight approach, such as a survey similar to the one used for Last Call, rather than the full Decision Policy, since this is a process question, not a technical question.
Comment 1 Maciej Stachowiak 2011-05-30 21:39:58 UTC
To flesh this out a little more, I propose the following process:

1) Initial choice of whether a draft is REC-track or Note-track is up to the Editor or Editors of that draft. Ideally each Editor should make his intent clear.

2) If any WG member would like to move a draft from REC-track to Note-track or vice versa, they should file a bug as an initial step.

3) If the editor agrees, and no one objects, the matter is settled.

4) If anyone objects, they should escalate to a tracker issue, which  will be resolved by a special fast-track process.

5) The fast-track process is as follows:

    5.a) We do not ask for full Change Proposals, merely for a rationale statement from advocates of both REC-track and Note-track. These can be brief. They can quote existing bug comments. The timeline to deliver is a month.

    5.b) If neither side provides rationale, the issue is closed without prejudice and can be reopened if someone does provide rationale.

    5.c) If only one side provides rationale, we hold a CfC to close the issue without prejudice. It can be reopened if rationale is provided later and the relevant draft has not yet gone to CR.

    5.d) If both sides provide rationale, we hold a survey. Since this is a process, not a technical decision, the survey is by individual not organization, and subject to quorum requirements, majority wins. If we do not achieve quorum, the Chairs will decide whether to re-run the survey or table the issue.
Comment 2 Sam Ruby 2011-05-31 12:12:09 UTC
(In reply to comment #1)
> 
> 3) If the editor agrees, and no one objects, the matter is settled.

Overall, I agree.  I would suggest rewording this one to simply state that the bug is to be RESOLVEd by the editor as with any other bug.  The reason I suggest this is twofold: (a) the editor doesn't need to agree and can mark the bug as WONTFIX, and (b) unless there is a deadline for objections, the matter is not settled.
Comment 3 Lachlan Hunt 2011-05-31 12:35:37 UTC
Perhaps there should be some clearer guidelines to help editors decide whether their work should be Rec or Note?  I'd say any draft which is only meant to provide guidance for a select community, such as authors, should be note.  Any draft intended to describe an authoring language profile, by reference to the normative requirements of another spec, should be note. Any draft that does not intend to provide any normative implementation requirements should be note.

Conversely, any draft that seeks to define normative requirements for features, which are not also normatively defined in another spec from this group, should be rec.

Guidelines like these would mean that drafts like the polyglot guidlines, alt text guidelines, markup language reference or authoring reference/guides should be note.  However, specs like 2D Canvas, Microdata, HTML+RDFa, etc. would be on the Rec track.
Comment 4 Julian Reschke 2011-05-31 12:54:50 UTC
(In reply to comment #3)
> Perhaps there should be some clearer guidelines to help editors decide whether
> their work should be Rec or Note?  I'd say any draft which is only meant to
> provide guidance for a select community, such as authors, should be note.  Any
> draft intended to describe an authoring language profile, by reference to the
> normative requirements of another spec, should be note. Any draft that does not
> intend to provide any normative implementation requirements should be note.
> 
> Conversely, any draft that seeks to define normative requirements for features,
> which are not also normatively defined in another spec from this group, should
> be rec.
> 
> Guidelines like these would mean that drafts like the polyglot guidlines, alt
> text guidelines, markup language reference or authoring reference/guides should
> be note.  However, specs like 2D Canvas, Microdata, HTML+RDFa, etc. would be on
> the Rec track.

Lachlan, is this type of distinction backed by a W3C definition of what can be a REC and what can't?
Comment 5 Laura Carlson 2011-05-31 13:10:21 UTC
Adding the "a11y" keyword as the outcome of this bug will affect "HTML5: Techniques for providing useful text alternatives" [1] as well as two Accessibility Task Force Bugs: Webcam Bug-9215 [2] and CAPTCHA Bug-9216 [3].
	

[1] http://dev.w3.org/html5/alt-techniques/
[2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9215
[3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=9216
Comment 6 Paul Cotton 2011-05-31 19:21:34 UTC
(In reply to comment #3)
> Perhaps there should be some clearer guidelines to help editors decide whether
> their work should be Rec or Note?  I'd say any draft which is only meant to
> provide guidance for a select community, such as authors, should be note.  Any
> draft intended to describe an authoring language profile, by reference to the
> normative requirements of another spec, should be note. Any draft that does not
> intend to provide any normative implementation requirements should be note.
> Conversely, any draft that seeks to define normative requirements for features,
> which are not also normatively defined in another spec from this group, should
> be rec.
> Guidelines like these would mean that drafts like the polyglot guidlines, alt
> text guidelines, markup language reference or authoring reference/guides should
> be note.  However, specs like 2D Canvas, Microdata, HTML+RDFa, etc. would be on
> the Rec track.

I do NOT believe the Normativity of a specification is necesarily the test of whether it should be on the Recommendation track or not.  The real test for me is if the owning WG plans to maintain the specification or not.

See Section 7.5 "Ending Work on a Technical Report":
http://www.w3.org/2005/10/Process-20051014/process.html#tr-end 

For example the XML Schema Primer is a W3C Recommendation but obviously that specification does not contain normative text. 

See XML Schema Primer 2nd Edition as proof that the XML Schema WG actively maintained this specification:
http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/ 

On the other hand the WS-Policy Primer was published as a WG Note since that WG explicitly decided it did NOT want to maintain the specification:
http://www.w3.org/TR/2007/NOTE-ws-policy-primer-20071112/ 

/paulc
Comment 7 Michael[tm] Smith 2011-06-01 12:20:48 UTC
(In reply to comment #6 from Paul)
> I do NOT believe the Normativity of a specification is necesarily the test of
> whether it should be on the Recommendation track or not.  The real test for me
> is if the owning WG plans to maintain the specification or not.

I agree with Paul here. While I know some members of the group seem to believe the determination for whether a document is Rec-track should be made based on whether it contains an normative requirements, that is at odds with the W3C Process doc, because the Process document very clearly allows for non-normative Recommendations.

It seems like the members proposing that certain HTML WG drafts be changed to Working Group Notes instead of being Rec-track are proposing that because they know that will have the effect of making it necessary of the editors of those drafts to remove any normative requirements from them.

So I would suggest that instead of adding anything to the HTML WG decision-policy doc to "Define process for deciding whether a draft is REC-track or Note-track", what should instead be added is "Define process for deciding whether a draft should contain any normative requirements".
Comment 8 Sam Ruby 2011-06-01 12:42:17 UTC
(In reply to comment #7)
> 
> So I would suggest that instead of adding anything to the HTML WG
> decision-policy doc to "Define process for deciding whether a draft is
> REC-track or Note-track", what should instead be added is "Define process for
> deciding whether a draft should contain any normative requirements".

tl;dr version: that's a separate bug.

Until or unless the following bugs are resolved, we still need a process for deciding whether a given document is REC-track or Note-track:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12725
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12726

Additionally, there are the following Formal Objections that we need to resolve:

http://lists.w3.org/Archives/Public/www-archive/2011May/0050.html
http://lists.w3.org/Archives/Public/www-archive/2011May/0051.html

(where the above mentioned bugs were entered as a result of tracking these FOs).

Even if the bugs are resolved, unless the FOs are withdrawn it makes sense to document the process by which the working group determined which track it was pursuing for any given document.
Comment 9 Michael[tm] Smith 2011-06-01 13:20:32 UTC
(In reply to comment #8 from Sam)
> Until or unless the following bugs are resolved, we still need a process for
> deciding whether a given document is REC-track or Note-track:
> 
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12725
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12726

There isn't actually any such thing as "Note-track". So the premise on which both those bugs and this bug were raised is flawed.

The discussion and resolution of these bug needs to be based on what the W3C Process document actually says, not what people assume it says or on what they wish it said.

So, as far as what the W3C Process doc actually says: While it uses the term "Recommendation track" extensively, it makes zero mention of a "Note track" or anything like similar.

What the Process doc does instead is, it provides for a Note _state_, which it defines as a specific _maturity level_ -- and that particular maturity level is what Paul alluded to in his comment; it's used by a Working Group "to indicate that work has ended on a particular topic".

Here's a full excerpt from the relevant part of the Process document:

7.1.3 Maturity Level When Ending Work on a Technical Report
http://www.w3.org/2005/10/Process-20051014/tr.html#q75
[[
Working Group Note
A Working Group Note is published by a chartered Working Group to indicate that work has ended on a particular topic. A Working Group may publish a Working Group Note with or without its prior publication as a Working Draft.
]]

So the W3C process does not provide for this group nor any other group to decide "whether a draft is REC-track or Note-track". If the HTML WG decides to publish a draft as a Note, then as far as the Process doc defines it, that means the group is deciding to end work on that draft.

What the W3C publication policy does instead provide for is making it clear within the draft itself that it is an informative-only draft (if that's what the group agrees it is to be). So the right thing to be discussing and getting resolved here is an HTML WG policy for the group to decide whether a particular draft is informative-only or not.
Comment 10 Paul Cotton 2011-06-01 13:29:53 UTC
(In reply to comment #9)
> (In reply to comment #8 from Sam)
> > Until or unless the following bugs are resolved, we still need a process for
> > deciding whether a given document is REC-track or Note-track:
> > 
> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=12725
> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=12726
> ...
> What the W3C publication policy does instead provide for is making it clear
> within the draft itself that it is an informative-only draft (if that's what
> the group agrees it is to be). So the right thing to be discussing and getting
> resolved here is an HTML WG policy for the group to decide whether a particular
> draft is informative-only or not.

As an example of the kind of text that Mike is referring to, the following is the first sentence of the Abstract from the XML Schema Part 0: Primer which makes it very clear that the W3C Recommendation is "non-normative":
http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/

Abstract
XML Schema Part 0: Primer is a non-normative document intended to provide an easily readable description of the XML Schema facilities, and is oriented towards quickly understanding how to create schemas using the XML Schema language.

/paulc
Comment 11 Sam Ruby 2011-06-01 13:31:47 UTC
(In reply to comment #9)
> (In reply to comment #8 from Sam)
> > Until or unless the following bugs are resolved, we still need a process for
> > deciding whether a given document is REC-track or Note-track:
> > 
> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=12725
> > http://www.w3.org/Bugs/Public/show_bug.cgi?id=12726
> 
> There isn't actually any such thing as "Note-track". So the premise on which
> both those bugs and this bug were raised is flawed.

I encourage you to work with Lachlan Hunt and get him to withdraw his Formal Objections on this matter and agree to close these bugs.  Failing that, I think it is our best interest to document the rationale for the approach we are taking and provide input to the Director as to what course the Working Group as a whole prefers taking.

In short, I continue to support Maciej's proposed resolution.
Comment 12 Michael[tm] Smith 2011-06-03 09:40:33 UTC
I have come around to thinking that the group does not need to have a policy to address this at all.

Or rather, it needs to keep the current implicit policy the group already has been using -- which is that any HTML WG draft deliverable can contain normative requirements if the editor of the draft chooses to have the draft contain them. And if anybody disagrees with particular normative requirements in a draft, then they just do what they can already do now: File a bug report requesting that those particular requirements be changed or removed.

This gives all editors in the group equal authority to introduce useful requirements in a draft any time they see a need to do so, and to ask the group and the public to review the requirements in that draft and provide feedback on them.

In cases where there is disagreement among editors (and among members of the group) about particular normative requirements, and there has not yet been a working-group decision to resolve that disagreement, the policy change proposed in this bug report would hamstring editors of particular drafts, blocking them being able to get real spec text out for wider review in the same way that other editors in the group can.

So instead, for cases where we do end up with a draft that has normative spec text that conflicts with another draft, then the right way to resolve that is to get a working-group decision about that particular text, and so ultimately require that one or both of the drafts be changed to remove the conflict.

After such a working-group decision, if all normative requirements from a particular draft end up having been removed, then language can be added to the Abstract and Status sections of that draft to make it clear that it does not contain any normative requirements.
Comment 13 Maciej Stachowiak 2011-06-20 06:25:20 UTC
(In reply to comment #9)

> So the W3C process does not provide for this group nor any other group to
> decide "whether a draft is REC-track or Note-track". If the HTML WG decides to
> publish a draft as a Note, then as far as the Process doc defines it, that
> means the group is deciding to end work on that draft.
> 
> What the W3C publication policy does instead provide for is making it clear
> within the draft itself that it is an informative-only draft (if that's what
> the group agrees it is to be). So the right thing to be discussing and getting
> resolved here is an HTML WG policy for the group to decide whether a particular
> draft is informative-only or not.

Informative vs normative and REC vs Note are orthogonal dimensions. The WG certainly has a right to decide that a Working Draft will not advance to Candidate Recommendation or beyond, but will instead eventually become a Working Group Note. It is also common for a Working Group to decide this up front. This is a WG Decision and not within an Editor's discretion.

It is certainly up to Editors (initially) and the Working Group (ultimately) whether a draft will include normative requirements. But it is also up to the Working Group whether a draft will proceed to Candidate Rec and beyond. It seems much better to decide this up front, in an orderly manner, than to go all the way to the point of being ready to go to CR and then having the CR resolution fail.

That is what this bug is about.

I agree with you that no special policy is needed to decide whether a draft should include normative requirements or be merely informative. That seems to be handled fine by the normal Decision Policy.
Comment 14 Michael[tm] Smith 2011-06-20 06:53:39 UTC
(In reply to comment #13)
> Informative vs normative and REC vs Note are orthogonal dimensions.

Agreed. To be even more specific: A Note can contain statements that are intended as normative requirements, and it's possible for a Rec to contain no normative requirements at all, and to just be purely informative.

[...]
> It is certainly up to Editors (initially) and the Working Group (ultimately)
> whether a draft will include normative requirements. But it is also up to the
> Working Group whether a draft will proceed to Candidate Rec and beyond. It
> seems much better to decide this up front, in an orderly manner, than to go all
> the way to the point of being ready to go to CR and then having the CR
> resolution fail.
> 
> That is what this bug is about.

As I understand it, the background on this bug was that during the LC survey, Lachlan stated that he believed a couple of drafts which are currently Working Drafts should be made into Notes instead. And we have two other bugs open now for those.

The reason Lachlan gave what that he does not want those documents to contain any statements of normative requirements, and he mistakenly believes that the way to ensure they don't have any normative requirements is to put them on the "Note track".

But that's not going to achieve what Lachlan thinks its going to achieve; if the documents are turned into Notes -- or if the group decides they are destined to eventually become Notes -- that is not going to prevent the editors of those documents from including statements of normative requirements in them.

So establishing a process in the decision policy for turning documents into Notes is not going to solve the problem Lachlan wants fixed.
Comment 15 Maciej Stachowiak 2011-06-20 08:00:57 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > Informative vs normative and REC vs Note are orthogonal dimensions.
> 
> Agreed. To be even more specific: A Note can contain statements that are
> intended as normative requirements, and it's possible for a Rec to contain no
> normative requirements at all, and to just be purely informative.
> 
> [...]
> > It is certainly up to Editors (initially) and the Working Group (ultimately)
> > whether a draft will include normative requirements. But it is also up to the
> > Working Group whether a draft will proceed to Candidate Rec and beyond. It
> > seems much better to decide this up front, in an orderly manner, than to go all
> > the way to the point of being ready to go to CR and then having the CR
> > resolution fail.
> > 
> > That is what this bug is about.
> 
> As I understand it, the background on this bug was that during the LC survey,
> Lachlan stated that he believed a couple of drafts which are currently Working
> Drafts should be made into Notes instead. And we have two other bugs open now
> for those.

Yes, the comments from Lachlan and others asking for certain drafts to be targeted to become WG Notes led indirectly to this process bug. However, the process issue is not about making Lachlan happy. It's about making a clear way for the WG to decide a matter that should be a WG Decision.

> 
> The reason Lachlan gave what that he does not want those documents to contain
> any statements of normative requirements, and he mistakenly believes that the
> way to ensure they don't have any normative requirements is to put them on the
> "Note track".

There does seem to be some confusion between normative vs non-normative on the one hand, and REC vs WG Note on the other. There is some tangential relationship, because Notes are often not seen as authoritative, whether or not they contain normative requirements. It's definitely great to explain this to Lachlan.

> 
> But that's not going to achieve what Lachlan thinks its going to achieve; if
> the documents are turned into Notes -- or if the group decides they are
> destined to eventually become Notes -- that is not going to prevent the editors
> of those documents from including statements of normative requirements in them.
> 
> So establishing a process in the decision policy for turning documents into
> Notes is not going to solve the problem Lachlan wants fixed.

That may be so, but Lachlan was not the only WG member to suggest converting some or all of our deliverables to Notes and likely will not be the last. We need a way of fielding such requests. Anyone is welcome to get Lachlan to withdraw his request, as well.