w3c / standards-track

Best Practices for Bringing Work to the W3C Recommendation Track

standards-track

Best Practices for Bringing Work to the W3C Recommendation Track

Repo to host AB work on the matter

standards-track's Issues

what is restricted by the criteria: Charter? what WG can do before FPWD? publishing FPWD?

The requirement for an incubator spec could make it harder to get new work into a WG Charter (depending on what is actually meant be the proposal). Charters often last 2-3 years.

When an incubator spec is ready to move to a WG, does it wait (possibly a couple of years) to get into a WG Charter or are is the expectation that WGs would re-charter? (Rechartering requires everyone rejoining the WG to work under the new Charter.).

Or is their no restriction on specs being allowed in a Charter and the restriction is on when the WG is permitted to work on the spec? E.g. any work on X must be done outside the WG until the criteria are met?

Or is the restriction on when a WG is permitted to publish a FPWD (WG is allowed to do its own incubation in preparing for a FPWD, but can't publish a premature FPWD before criteria are met)?

It should be clear which of these is intended, or if it is the WG has a choice of which of these in their Charter.

typo in "Clear RF licensing commitments?"

1. Are the technologies in the initial available under terms that are compatible with the W3C Royalty-Free licensing requirements?

word missing at "initial".

is it "incubation draft"?

Updates for Director-free process changes

The 2023 Process introduces changes, in particular a Director-free approach and thus, this useful document (which has six mentions of Director decisions or Director involvement) should be updated to take these into account.

definition of "aspirational" should be further clarified

I think the definition of "aspirational" in the RTRC should be further clarified with additional prose and examples.

"gaps in the patent commitment" needs to be clarified - suggesting CLA problem?

In the bullets after "Arguments against focused on mandating using W3C Community Groups to incubate proposals "

There may be gaps in the patent commitment if all spec contributors to the incubation don't join the WG

Does this mean: "When incubation does not occur in an environment with a patent policy like a W3C Community Group under the CLA, there may be gaps in the patent commitment if all spec contributors to the incubation don't join the WG "

Or is it suggesting the W3C Community Group section on use in W3C specs isn't sufficient?
9.2.1 in https://www.w3.org/community/about/agreements/cla/

arguments against incubation - clarify one on team participation

It may be valuable for W3C team to help develop one or more proposals in the incubation stage

Does this mean: "If incubation is done outside W3C CGs or WGs, it may be more difficult for ther W3C team to help develop one or more proposals in the incubation stage"

I wasn't at the meeting where these objections were discussed, but W3C staff do participate in and sometimes lead CGs. Was this that they are less involved, rather than not able to be involved?

That bullet should be clearer on what was suggested as preventing team participation.

target audience section doesn't include AC in decisions it shares with Director

The target audience for this document includes:

• the Team and Director when evaluating proposals to create new Working Groups or rechartering existing Working Groups to put new work in scope;
• working group Chairs determining whether to publish First Public Working Drafts of specs that are in a group's chartered scope,
• Advisory Committee representatives reviewing charters and Proposed Recommendations.

What the team and director consider should be the same as what the AC considers -- they both consider charters and PR - but the two bullets differ only by PR included in the Director bullet. It also should be clearer what about the charter should be considered.

Created PR for proposed wording change #13

Also -
What should the Director consider at Proposed REC time? Seems the Director/AC look at the current draft and what kind of review and input it had, and at that point it doesn't matter if that was during incubation or after that as long as it was done by Proposed REC. There are already criteria for Proposed REC in the process. So I think that part should be clarified or removed.

User's community

I miss a more explicit reference to the interests of specific user communities (as opposed to implementers' interest only). An obvious example:

An initial draft of the technical specification has been written down and socialized in a community where web site / app developer, framework/took developer, and core technology implementers are represented.

I think we should emphasize that all incubations by groups at least should (if not must) prove that the proposals are driven by the concerns of real end-users.

Another example of a similar pattern:

The proposal enumerates the types of products (browsers, servers, frameworks, applications...) would need to support the spec for it to be successful

We should not only talk about products. User communities' adoption (e.g., language/I18N requirements, accessibility, but we may also talk about the needs of online marketing, publishing, etc. whatever is appropriate) should be clearly identified and represented. Or, at the minimum, it should be made clear by the proposals that this check is planned to be part of the planned Working Group's jobs.

I believe this is, actually, an editorial issue, but important nevertheless.

Should there be a proof of initial consensus?

The W3C process requires proofs, before letting a document through the process to become a standard, showing that a reasonable consensus has been found in the WG during the development process, including reviews by other communities. However, no such formal process exists for Community Groups, for example (by design). This means that an incubation group may arrive to a proposal dominated by one or two major players, and which does not, in fact, represent community consensus (or may even reflect major disagreements that are overruled by some strong players). There is no real way of knowing this.

The section on "Socialized Proposals" does refer to something similar but not strongly enough for my taste. Maybe it should also state that proof should be provided for a reasonable consensus or references to major disagreements should be made known. Alternatively, a separate section should be added spelling out this criterium.

Note that it may be possible for a Working Group to be formed without the incubation leading to a complete consensus, if the WG's stated job is to find such a consensus. But knowing the relevant history on this is important.

Clarify the stage at which screens apply

Lots of good advice in here for assessing standards-readiness. Though I agree we shouldn't label an early-stage tech without evidence of useful support "Recommendation track," I wouldn't want us to interpret the guidance to prevent W3C team involvement in early-stage discussions of technologies, or even in the development of some of those alternatives.

I would differentiate between listing something as a named Rec-track deliverable, and letting work be incubated in a chartered group -- possibly an IG or WG, not just CG. While we don't want to make heavy investment (of Consortium or Member resources) in early-stage work, we might want to make small investments in a portfolio of early work, expecting some of it to fizzle and some to succeed.

Rubber stamp should not be an 'additional consideration'

The section on rubber stamping is, in my view, an essential readiness criterium.

Although the proposal does refer (in the introduction) to the danger of:

• If a CG incubates a spec that gets implemented in the browsers, it's hard to motivate them to take it to a WG for broad review

• If the CG did not work by consensus, the de facto standard might be imposed by a single strong editor or cabal of the top browsers

I am not sure how this problem is addressed among the essential criteria. At the minimum, the incubator group should explicitly consider the issues listed in the section on rubber stamping. Hence moving it to the essential criteria section, and mark it as "strongly recommended".

This is also related to Issue #3.

Incomplete sentence in ¶ "Is it clear the proposers are not seeking a rubber stamp from W3C?"

It appears that the last sentence of the paragraph is incomplete:

"Likewise, proposed Recommendation-track work should not promote"

Promote what?

Document and analyze obsolete RECs

This request comes from the following email thread:

https://lists.w3.org/Archives/Member/w3c-ac-forum/2016OctDec/0143.html

In that thread there was an assertion that "aspirational standards" often do not make good RECs. There were two problems that the discussion raised. The first was that it was clear that there were varying definitions for "aspirational standard", which is documented as an issue here: #23. The second was that there did not seem to be any solid research data, although there does exist anecdotal evidence, that supports the various theories around why standards fail.

The REC Track Readiness Criteria should be based on data, especially criteria that is intended to increase the success of a group. This requires that the W3C:

1. Research and document past W3C successes and failures.
2. Derive additional W3C Rec Track Readiness Criteria from that research and include it in the REC Track Readiness Criteria document.
3. Seek consensus among the W3C Membership for the new readiness criteria.

Assertions that specs fail for specific reasons, without the data to back up those assertions, will continue to be met with skepticism until this is done.

I suggest that the first step is to document which specifications are clear failures and which ones are clear successes (up to the AB to define the criteria of what a 'success' and 'failure' is). The second step may be to interview the Chairs/Editors of the groups (if they're still around) to ask them why they think they failed or succeeded.

Role of the W3C staff and core process?

Although the proposal makes it explicit in a relevant section that the goal is not to rubber stamp, do see a possible problem with the lack of W3C staff presence. Indeed, at present, the staff is not supposed to spend much time in Community Groups. There is a danger that if the bulk of the spec work is done in the incubation period without staff participation than the genuine issues raised in that section will come "too late" for the proposers who would lobby against (some of) those (because "the job is already done"). Warning against such problems may be one of the jobs of the staff.

Maybe an approach is to set up a "early warning" mechanism whereby a CG would contact the W3C staff early enough in the process with the message that "we would like an extra interest from W3C because we plan to submit this technology for standardization in 6 months" (or something like that). That would allow early check/review against potential problems, staff participation in finalizing the proposals, etc.

(The situation does not occur with Interest Groups which do have staff contacts.)

needs a README with short summary and link to actual readable document

actual readable document: https://www.w3.org/Guide/standards-track/

We are not talking only about traditional Web Sites and browsers

W3C's concerns are not restricted to traditional web sites and browsers; we address a number of other areas with our technologies (server side issues, data on the Web, digital publishing, hybrid mobile applications, etc). Overall, the proposal is open in this sense (i.e., this is an editorial comment), but the examples should make it clearer to avoid misunderstandings. For example, the impression given by the example list in the Problem statement:

What are websites forced to do without this feature being available in a standardized way? What fraction of web sites / applications are implementing a similar feature in a non-standardized way? How would users benefit from this feature if standardized?

could be extended to include some of the non-browser and/or non-client examples.

Wording of consensus based argument against mandatory incubation

In list after "Arguments against mandating using W3C Community Groups to incubate proposals until they met empirical criteria included"

If the CG did not work by consensus, the de facto standard might be imposed by a single strong editor or cabal of the top browsers

I think that wording minimizes the problem. I suggest rewording it as:

CG rules allow them to be controlled by a single person, while W3C WGs guarantee fairness. Requiring external incubation (somewhere like a CG) could lead to most key technical decisions being made in forums dominated by a few, reducing the level playing field provided by W3C to when implementation makes it too late.

volunteer as co-editor

Volunteered to help out as co-editor of this document at today's W3CAB meeting.