Elevating a TAG document to W3C Approved Status

[jeffjaffe]

The AB and TAG have discussed that there should be a method for a TAG document to be elevated to W3C Approved Status. For example, the TAG might want certain TAG findings to become official W3C documents. We don't have a formal procedure of review to achieve that. The proposal is to create a review process that results in W3C endorsement of TAG documents.

[michaelchampion]

What's wrong with the Recommendation process for this? https://www.w3.org/TR/webarch/ is a Recommendation created by the TAG. It's not clear to me why they couldn't do the same for other work they want to get published as "official W3C documents."

[jeffjaffe]

Thanks @michaelchampion . I didn't say there was anything wrong with the Recommendation process. We could use it as is, or tweak it. Today, formally, it only applies to WGs. https://www.w3.org/2020/Process-20200915/#Reports

[dwsinger]

There is substantial discussion of this in the member-visible AB Repository, including a suggested resolution (which this link points to) and some refinement following that. It would probably help to take that as a starting point, or even to ask the community to comment there and avoid forking the conversation.

[jeffjaffe]

even to ask the community to comment there and avoid forking the conversation.

Just a reminder that public participants in the Process CG community may not have member access to https://github.com/w3c/AB-memberonly/issues/35#issuecomment-722566134

[chaals]

Speaking as an AC representative, I believe we should use the AC review process for this.

It's not clear that we need a Candidate Recommendation phase unless the TAG decides to advise doing things that no WG has actually done and made into a Recommendation. So there are some potential differences we might consider, especially to avoid more process work than necessary.

On the other hand the Recommendation track incorporates the Patent Policy, whereas the TAG freelancing on proposals without any corresponding obligations on anyone regarding IPR might be a bad idea.

(For clarity, it's also why I think there is potentially merit in a charter for the TAG, but only so long as that is periodically reviewed and specifically describes deliverables, otherwise we might as well just define the TAG in the Process only, but that's really a different issue).

[dwsinger]

My proposal in the other thread is (a) the TAG is not allowed to make implementable recommendations (for all sorts of reasons including patent policy) (b) can ask that they make a document that has W3C Consensus (not just TAG consensus) and (c) we basically use the AC-review/wide-review/Director-approval process for getting that consensus (essentially hitching a ride on the existing mechanism) and (d) we call such consensus non-implementable documents something new, eg W3C Report.

I think this reflects what @chaals is saying too. Does it?

[chaals]

@dwsinger I think our proposals are on parallel lines. The differences are:

• I don't think we should say "non-implementable" because I think it will cause more work than it saves to decide what that means and explain it.
• I do think it makes sense to charter the TAG so proposed deliverables are floated to the AC before a lot of effort is spent delivering them. (You may agree with this, but I don't think you said so explicitly).

[dwsinger]

@chaals Yes, I'm using non-implementable as a shorthand, but I do think it has to be a real restriction as I cannot see how the TAG can issue a document that invokes and carries licensing commitments, which is one of the main characteristics of a Recommendation. These documents need a new name, and status, (I suggest W3C Report, in contrast to W3C Recommendation) which make this clear.

I am not a fan of a charter for the TAG; approving or disapproving a charter for an elected body gets us into all sorts of hard what-ifs. I am, however, supportive of the concept of what you're saying; that if the TAG feels the need to develop something that they intend to achieve W3C consensus status, it would be prudent and courteous to say that early on, so arguments of the kind "we should not publish a document of that type" can be raised before they do a lot of work.

[samuelweiler]

My proposal in the other thread is .... (b) can ask that they make a document that has W3C Consensus (not just TAG consensus) and (c) we basically use the AC-review/wide-review/Director-approval process for getting that consensus (essentially hitching a ride on the existing mechanism) ...

Asking a broader question: how do we want to determine W3C Consensus in a post-director world?

I'm used to an SDO where the whole community can weigh in on consensus calls, and that makes asking the AC - and implicitly not the rest of our community - feel weird. It seems like it excludes many voices. If we're actually asking everyone ("wide review"), then why are we separately asking the AC? Can't we instead only ask everyone?

Having asked everyone, who's going to judge that consensus?

(I'm also accustomed to having the IAB, arguably IETF's TAG equivalent, routinely publishing RFCs under their own name. They usually ask for community input (in part by publishing as internet-drafts first, and in part by explicitly asking) but they don't constrain themselves to only publishing with "IETF Consensus".)

[fantasai]

@samuelweiler “Asking a broader question: how do we want to determine W3C Consensus in a post-director world?” is a separate issue, please file it separately.

[jwrosewell]

I'm in favor of Process simplification and the removal of anomalies. Placing TAGs responsibilities in an Interest Group seems worth exploring as a remedy.

[css-meeting-bot]

The Revising W3C Process CG just discussed TAG documents with W3C approval.

The full IRC log of that discussion

<fantasai> Topic: TAG documents with W3C approval
<fantasai> github: https://github.com//issues/461
<fantasai> florian: chaals seems to be maintaining his position
<fantasai> florian: As far as I'm concerned ...
<fantasai> florian: Seems we all want the TAG to be able to issue documents with AC approval
<plh> --> https://www.w3.org/TR/2020/NOTE-design-principles-20201110/ Web Platform Design Principles
<fantasai> florian: The question is are they RECs or not
<fantasai> florian: A bunch of us are saying that they can't be because invokes Patent Policy
<jrosewell> q+
<fantasai> florian: chaals says it has to be REC but doesn't say why
<fantasai> florian: idk if we have consensus or not
<fantasai> florian: If we go with a class of doc that is like a REC but no Patent Policy, should only TAG be able to publish or should all groups be able to?
<fantasai> dsinger: I would say let any group make such things
<fantasai> dsinger: Might be useful for HRGs
<dsinger> ack jrose
<fantasai> jrosewell: Reading through thread, why is TAG different from other Interest Groups?
<fantasai> florian: TAG is an elected body
<fantasai> florian: has a special status
<fantasai> florian: revisiting that is a whole new question
<fantasai> florian: and I'm not sure there's a lot of appetite for such question, first time I'm hearing it
<fantasai> fantasai: That question is a completely separate issue. If it's an issue to pursue, file it separately. Shouldn't block this issue.
<fantasai> dsinger: Agreed.
<plh> q+
<dsinger> ack plh
<fantasai> dsinger: So next step would be to draft out the Process text for such a W3C Consensus document
<fantasai> plh: Agree giving to other groups than TAG
<fantasai> plh: Difference between TAG and other groups is that Director is part of the TAG.
<fantasai> plh: Other groups, need Director to approve, but Director is part of TAG so TAG approval includes Director approval
<fantasai> florian: That's true in theory, not so much in practice these days
<fantasai> florian: Willing to draft the text
<jeff> q+ to address plh's issue
<fantasai> florian: but also, we also have issues of disentangling Notes and RECs
<fantasai> florian: Might be easier to do this after untangling those also.
<dsinger> q?
<fantasai> dsinger: Related question, can we create different visual identity for things which are group consensus and those that are W3C Consensus?
<dsinger> ack jeff
<Zakim> jeff, you wanted to address plh's issue
<florian> The issue I mentioned is https://github.com//issues/342
<fantasai> jeff: Issue about visual identity of RECs and other documents, already an issue filed elsewhere. Let's not entangle that here.
<fantasai> jeff: Raised important issue of Director ruling in case of conflict of interest
<fantasai> jeff: Simple fix, unsure where to document it
<fantasai> jeff: Extreme case, TAG has a Finding and Director is involved in the discussions
<fantasai> jeff: Goes to AC approval, and there's an FO
<fantasai> jeff: Use case of plh's concern wrt conflict of interest.
<fantasai> jeff: Easy fix would be that the Director acting on the FO needs to recognize the conflict of interest and delegate the Director function of handling the FO to someone else
<dsinger> q?
<fantasai> dsinger: OK, task for editor to draft up text
<fantasai> dsinger: Side-issue that nobody likes the name 'W3C Report'
<fantasai> dsinger: if anyone has a better name?
<fantasai> fantasai: "W3C Guidance"? Kinda like REC but not? :)

[chaals]

@jwrosewell wrote

Placing TAGs responsibilities in an Interest Group seems worth exploring as a remedy.

To me it seems like an idea that can be dismissed out of hand, so I am curious what problem it solves and why you think it seems worth exploring. Can you expand a bit on that?

[frivoal]

Let's keep issues focused. This is largely orthogonal to the initial problem, so if you want to discuss changing the TAG into an ordinary IG, I suggest you open a separate issue for that.

[dwsinger]

So, modulo maybe needing a better name than "W3C Note" for a document that has W3C consensus status but that is not a Recommendation (i.e. not a spec.), my proposal is

• Only chartered groups (hence, formed of members) can make W3C Recommendations. Elected groups cannot.
• Rename Note to Group Note, and mandate that it clearly document its subtype and status (e.g. 'this is an abandoned attempt at a Rec.', 'this is a Finding of an answer to a specific question', 'this is a guidance document on considerations on XXX (e.g. accessibility)', and so on).
• Require that a document called a Note cannot specify implementable technology; the W3C requires that all such documents be Recommendations.
• Allow both chartered and elected groups to produce Group Notes (though I doubt the AB will), without a requirement that they be mentioned in the charter
• Allow any group that produced a Group Note to request elevation to W3C Note status; that triggers wide review, AC Review and Director assent.
• Drop the TAG charter; it's not maintainable and adds no value, and means something quite different from the usual 'should we have a group with this charter?' as the TAG always exists
• Make sure we address the styling question (which is separate, but this would raise its importance).

I don't want to get into the details of styling, but we need to differentiate:

• W3C consensus from group consensus from individual work
• recommendation track and note track are different
• finished work is different from work-in-progress

[fantasai]

@dwsinger Nice list. One issue I have with it is “Require that a document called a Note cannot specify implementable technology; the W3C requires that all such documents be Recommendations.” -- many of our notes specify implementable tech, because they're discontinued or exploratory designs for implementable tech or suchlike. :) So I don't think we can make this a requirement. But we can require that elected groups cannot publish notes that specify implementable tech. And we can also require that groups should not publish notes specifying tech that they want to recommend for implementation. (Distinguishing here between a document that describes tech that can be implemented vs one that we recommend be implemented.)

Wrt naming, maybe using the more formal “W3C Memorandum” instead of “W3C Note” would work and help differentiate the increased status better?

[fantasai]

Wrt clearly distinguishing NOTEs, btw, there's #342 which seems worth taking up.

[plehegar]

+1 to NOT require "that a document called a Note cannot specify implementable technology; the W3C requires that all such documents be Recommendations."
Here are examples of Notes that specify implementable technologies:

• https://www.w3.org/TR/2020/NOTE-css-2020-20201222/
• https://www.w3.org/TR/2020/NOTE-lpf-20200319/
• https://www.w3.org/TR/2020/NOTE-json-ld11-streaming-20200507/
• https://www.w3.org/TR/2020/NOTE-merchant-validation-20201208/

[dwsinger]

doh, yes of course, stupid oversight

• A document intended to be a Note should not specify implementable technology,
• A Note does not receive a Patent License under the Patent Policy;
• A Group Note specifying implementable technology cannot be elevated to W3C status.

[fantasai]

A document intended to be a Note should not specify implementable technology,

A document intended to be a Note should not specify technology the group recommends for implementation,

[fantasai]

RESOLVED: Accept proposal for W3C-approved NOTEs, they SHOULD NOT specify implementable tech--if so transition request MUST include rationale for not being on REC track

[fantasai]

RESOLVED: Go with Memorandum in the PR for now, bikeshed the name later.

[css-meeting-bot]

The Revising W3C Process CG just discussed Elevating a TAG document to W3C Approved Status, and agreed to the following:

• RESOLVED:: proposal for W3C NOTE SHOULD NOT specify implementable tech, transition request MUST include rationale for not being on REC track
• RESOLVED: Go with Memorandum in the PR for now, bikeshed the name later

The full IRC log of that discussion

<plh> Topic: Elevating a TAG document to W3C Approved Status
<plh> GitHub: https://github.com//issues/461
<plh> David: +1 to not require Notes not to contain implementation technology
<plh> ... [reading his notes on GH]
<plh> q+
<plh> fantasai: CSS working group produced a Note that was an interesting proposal informing others
<plh> ... we should clarify that Notes don't receive IP commitments
<dsinger> q?
<dsinger> ack plh
<cwilso> zakim, who is here?
<Zakim> Present: dsinger, fantasai, wseltzer, jeff, cwilso, weiler
<Zakim> On IRC I see plh, Zakim, dsinger, jeff, tzviya, astearns, timeless, cwilso, misalias_, github-bot, Mek, fantasai, florian, wseltzer, weiler
<wseltzer> plh: example of MSE, where we published a tech mapping
<wseltzer> ... as a note. That had implementable tech
<dsinger> q?
<fantasai> proposal: proposal for W3C NOTE SHOULD NOT specify implementable tech, transition request MUST include rationale for not being on REC track
<plh> +1
<fantasai> RESOLVED:: proposal for W3C NOTE SHOULD NOT specify implementable tech, transition request MUST include rationale for not being on REC track
<plh> zakim, close this agendum
<Zakim> I do not know what agendum had been taken up, plh
<plh> fantasai: what about the naming?
<jeff> q+
<plh> fantasai: "W3C Memorandum"
<dsinger> q?
<plh> david: ok with me
<dsinger> ack jeff
<wseltzer> ask the TAG, who wants to produce the things?
<plh> jeff: at some point, we should send this to the TAG for them to comments
<wseltzer> q+
<dsinger> q?
<plh> wseltzer: feels legal to me :(
<dsinger> ack ws
<plh> fantasai: it is used in various context
<wseltzer> "working paper"
<weiler> [and memorandum seems.... not-self-explanatory. it's clearly new, but it doesn't help the outsider]
<fantasai> UK definition for non-legal usage: "an official report about a particular subject that is written for a company, organization, or government to consider"
<wseltzer> "paper"
<wseltzer> "whitepaper"
<plh> david: we can use "note", "report", "memorandum", "white paper"
<plh> fantasai: having separate names would help depending on the level of consensus
<plh> david: ok, we'll do a poll in the pull request
<plh> ... I'll go with memorandum for now
<fantasai> RESOLVED: Go with Memorandum in the PR for now, bikeshed the name later
<wseltzer> q+

[nigelmegitt]

Sorry, a bit late to this party, and I may have missed a discussion, but this proposed requirement about not specifying implementable technology in a Note sems to have two problems:

1. It implies the need for a definition of "specify implementable technology". I don't think it is a workable requirement.

For example, a WG might write as a Note a guidance document about possible implementation approaches for a separate Rec. The Rec specifies the normative requirement, the Note adds more informative detail, but it could be perceived as "specifying implementable technology".

For example https://www.w3.org/WAI/WCAG21/Techniques/ is informative and though it doesn't make clear if it is a Note or not, I assume it is one. It includes specific techniques that implementers may use to meet the requirements. I doubt it is anyone's intent to suggest that it shouldn't be allowed.

This seems like a terminology rabbit-hole we should avoid.

On the other hand, it would be redundant to say that a Note must not include any normative provisions, since that is already true by definition.

2. It seems to contradict the Process

• RESOLVED:: proposal for W3C NOTE SHOULD NOT specify implementable tech, transition request MUST include rationale for not being on REC track

Further, doesn't the resolution contradict the Process, in that the Process requires that abandoned Rec track work is published as a Note? Seems odd if the Process requires one thing and also says "SHOULD NOT" about that same thing somewhere else.

[dwsinger]

@nigelmegitt Yes, we need to make it clear that though implementable technology can be discussed, or documented as abandoned Rec-track work, it is (a) not Recommended for implementation and (b) receives no license under the Patent Policy.

We're saying that Group Notes that nonetheless contain implementable tech will not, in the normal course of events, be elevated to W3C Memorandum status (the correct vehicle for a W3C-consensus document of implementable tech. is a Recommendation), and if a group wants to elevate an implementable Group Note to W3C Memorandum, they're going to have to justify that in the request to elevate to W3C Memorandum status.

[dwsinger]

Putting it all together, one more time

• Only chartered groups (hence, formed of members) can make W3C Recommendations. Elected groups cannot.
• Rename Note to Group Note, and mandate that it clearly document its subtype and status (e.g. 'this is an abandoned attempt at a Rec.', 'this is a Finding of an answer to a specific question', 'this is a guidance document on considerations on XXX (e.g. accessibility)', and so on).
• Both chartered and elected groups may produce Group Notes, without a requirement that the Notes be mentioned in the charter
• Introduce a new class of W3C consensus publication, called a W3C Memorandum
• Allow the group that produced a Group Note to request elevation of that Note to W3C Memorandum status; that triggers wide review, AC Review and Director assent.
• Neither a Group Note nor W3C Memorandum receive a Patent License under the Patent Policy; the document status must clearly state that this;
• A document intended to be a Note should not specify technology the group recommends for implementation;
• A Group Note specifying implementable technology should not be elevated to W3C Memorandum status; if it does, the transition request MUST include rationale for why it should be elevated, and why it is not on the Recommendation track.

Separately, we recommend:

• Drop the TAG charter; it's not maintainable and adds no value, and means something quite different from the usual 'should we have a group with this charter?' as the TAG always exists
• Address the document styling question (which is separate, but this would raise its importance), to differentiate:
  • W3C consensus from group consensus from individual work
  • Recommendation track from Note/Memorandum track
  • Finished work (final rec, final Group Note, final W3C Memorandum, etc.) from work-in-progress

[nigelmegitt]

@dwsinger , that doesn't seem to match up with your previous comment, so I'm not sure I've understood. Should:

A document intended to be a Note should not specify technology the group recommends for implementation;

instead be:

A document intended to be a Memorandum should not specify technology the group recommends for implementation;

?

[dwsinger]

Just chiming in to say I don't think "Note" is the necessarily a consensus product of a group. Back in the day, we would publish Notes that were essentially proposals from various vendors as a Note. (Trolling https://www.w3.org/TR/?status=note toward the bottom of the page.)

I think that the group has to have consensus to produce the Note; I think it's fine if the Note itself is a documentation of an inability to reach consensus, of opinions that were interesting but did not get traction, or the like.

[frivoal]

Why not just stick with Note

The TAG's ability to produce Notes despite the Process for producing notes not including the TAG is a bug we need to fix (by fixing the process, not by disallowing the TAG to produce notes)

if we're not comfortable with TAG publishing Recs

I want it to be possible for W3C as a whole to endorse documents made by the TAGs. RECs give you that plus a hook into the patent policy. That hook doesn't actually work properly, as it is designed to apply to WGs, and making the patent policy apply to the TAG isn't the goal of this exercise. Hence needing a new class of documents which is roughly "Note+AC Review"

I've just introduced #489 to do these two things.

[fantasai]

Only chartered groups (hence, formed of members) can make W3C Recommendations. Elected groups cannot.

Specified in the Process already: only Working Groups are allowed to do the things on the REC-track.

Rename Note to Group Note,

We actually call these group notes already. Or more specifically, "Working Group Note", "Interest Group Note" etc.

and mandate that it clearly document its subtype and status (e.g. 'this is an abandoned attempt at a Rec.', 'this is a Finding of an answer to a specific question', 'this is a guidance document on considerations on XXX (e.g. accessibility)', and so on).

I think this is the responsibility of the Abstract and SOTD, and not something we particularly need to require in the Process. For abandoned REC track documents specifically, the requirement already exists in https://www.w3.org/2020/Process-20200915/#abandon-draft (but see also #342).

Both chartered and elected groups may produce Group Notes, without a requirement that the Notes be mentioned in the charter

Specified in frivoal@8d37bfa.
Do you particularly want to mention the bit about the charter (in light of complaints about the process doc being too long ;) ?

Introduce a new class of W3C consensus publication, called a W3C Memorandum
Allow the group that produced a Group Note to request elevation of that Note to W3C Memorandum status; that triggers wide review, AC Review and Director assent.

Drafted in frivoal@168d7ef

Neither a Group Note nor W3C Memorandum receive a Patent License under the Patent Policy

This is already clearly specified in the Process and the Patent Policy, however...

the document status must clearly state that this;

We need to update the templates. They are absolutely not clear about this, and in fact often contain references to the Patent Policy in the SOTD identical to the ones in the REC-track SOTDs. :/ Filed w3c/specberus#1092

A document intended to be a Note should not specify technology the group recommends for implementation;
A Group Note specifying implementable technology should not be elevated to W3C Memorandum status; if it does, the transition request MUST include rationale for why it should be elevated, and why it is not on the Recommendation track.

Done in dae9fdb

[frivoal]

On the bikeshedding side of things, since few people love the term "W3C memorandum", how about:

• W3C Statement
• W3C Position

[torgo]

On the bikeshedding side of things, since few people love the term "W3C memorandum", how about:

• W3C Statement
• W3C Position

I think both are better than Memorandum. I favour Position as it seems like it could cover a broader class of things.

[nigelmegitt]

I favour Position as it seems like it could cover a broader class of things.

I was going to say I favour Statement for exactly the same reason! Position sounds like a consensus 'opinion' but Statement could be that, or could be some other declaration.

[LeaVerou]

Basically, what @torgo said. Both are much better than Memorandum, slight preference for Position as it seems to better represent a larger percentage of the class of things we are trying to describe.

[dwsinger]

I started with Report, which I still kinda like.

'Position' is generally when there is a question, often with a spectrum of opinion or possible response. I am not quite sure whether that is broad enough.

But I love the brainstorming, keep it going!

[jeffjaffe]

While I don't love Communiqué, it is both distinctive and sounds very important. Perhaps too officious.

[frivoal]

This has been resolved by CG resolution by merging #489