Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More clarity on where a "candidate addition" lives #248

Open
marcoscaceres opened this issue Aug 19, 2021 · 8 comments
Open

More clarity on where a "candidate addition" lives #248

marcoscaceres opened this issue Aug 19, 2021 · 8 comments

Comments

@marcoscaceres
Copy link
Member

marcoscaceres commented Aug 19, 2021

When taking a spec to Rec that [=allows new features=], it's unclear where "candidate additions" snapshots live.

Consider.

  1. A Proposed Rec that "allow new features" is published.
  2. Document is then published as REC
  3. "New feature" is specified (candidate addition).

Is a "candidate addition" published to TR at a "Working Draft"? Or do they get a special label?

I'm a bit unsure from:
https://www.w3.org/2020/Process-20200915/#candidate-changes

this text in particular:

In addition to their actual maturity level, published REC Track documents with candidate changes are also considered, for the purpose of the W3C Patent Policy [PATENT-POLICY], to be Working Drafts with those candidate changes treated as normative.

I was expecting something like "Candidate Addition Draft" or something similar to a CRD.... if it's just a regular "WD", that works :)

@marcoscaceres marcoscaceres changed the title More clarity on where a "candidate addition" addition lives More clarity on where a "candidate addition" lives Aug 19, 2021
@frivoal
Copy link
Contributor

frivoal commented Aug 19, 2021

It's published as a REC again, with the candidate addition being an informative addition showing what the spec would change to if it were adopted. Here's an example:
https://www.w3.org/TR/css-contain-1/#c1

(This example is a candidate correction rather than a candidate addition, but that they're are not different in this respect)

@marcoscaceres
Copy link
Member Author

That’s hugely helpful, @frivoal. Thank you! Should we clarify that in the Process doc? I wasn’t able to figure the above out from what’s currently there.

@marcoscaceres
Copy link
Member Author

Also, I guess we can add as many informative sections (candidate additions) as needed… what’s then the timeframe for re-publishing as REC? Is it every 6 months?

@frivoal
Copy link
Contributor

frivoal commented Aug 27, 2021

You can republish a REC to add (or remove, or update) candidate corrections as often as you want. Daily would be fine if you had a need for that.

However, when you want to elevate candidate corrections to proposed corrections, that triggers patent review, AC Review, etc. That's heavier, and shouldn't be done more often an once every 6 months per spec.

@marcoscaceres
Copy link
Member Author

Thanks @frivoal! That's really helpful. I have a feeling this is going to come up a lot as we shift more and more specs over to this model... I've seen a fair bit of reluctance from folks to move off CR to REC because they are worried that the above is going to be painful (which, given your description, it isn't really... tho the update every 6 months minimum might be).

Having said that, could you suggest some place were we could capture the information above that I can point to people? I think it would really help elucidate what's involved.

@frivoal
Copy link
Contributor

frivoal commented Aug 31, 2021

could you suggest some place were we could capture the information above that I can point to people?

/Guide, announced to the chairs, with a reminder break-out session at TPAC (possibly for a few years)?

@plehegar
Copy link
Member

plehegar commented Sep 21, 2022

This issue should be transferred to /Guide .

@frivoal

This comment was marked as resolved.

@frivoal frivoal transferred this issue from w3c/process Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants