search

w3c / process

W3C Process Document
https://www.w3.org/policies/process/drafts/
190 stars 127 forks source link

process should clarify how Superseded state interacts with other maintenance processes (e.g., new versions, edited/amended recommendations) #183

Closed dbaron closed 5 years ago

dbaron commented 6 years ago

The creation of the superseded state has caused some confusion in the CSS working group, in particular related to the discussion in w3c/csswg-drafts#2589.

My memory of the creation of superseded was that it resulted from objections to calling something obsolete that was actually superseded by a later version.

However, this has created the impression to some in the CSS WG that this creates an obligation to mark things as superseded. The process should be clearer which sorts of revisions cause one specification to automatically be superseded by another, and which sorts require marking something as superseded. For example, does it matter if something was an edited/amended Recommendation (versus maintenance that adds new features), or whether it had the same shortname, or whether it was produced by the same or a successor working group, or whether it has the same name (but maybe a different version)?

dwsinger commented 6 years ago

Oh dear. This state was an opportunity to clean house. There is neither obligation nor automation, rather, opportunity to clean /TR of historical references, which remain available for reference, but we want to steer new readers and implementers to something later.

Sent from my iPhone

On May 2, 2018, at 5:00 PM, L. David Baron notifications@github.com wrote:

The creation of the superseded state has caused some confusion in the CSS working group, in particular related to the discussion in w3c/csswg-drafts#2589.

My memory of the creation of superseded was that it resulted from objections to calling something obsolete that was actually superseded by a later version.

However, this has created the impression to some in the CSS WG that this creates an obligation to mark things as superseded. The process should be clearer which sorts of revisions cause one specification to automatically be superseded by another, and which sorts require marking something as superseded. For example, does it matter if something was an edited/amended Recommendation (versus maintenance that adds new features), or whether it had the same shortname, or whether it was produced by the same or a successor working group, or whether it has the same name (but maybe a different version)?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

dbaron commented 6 years ago

BTW, I think one reasonable place to draw the line might be:

dwsinger commented 6 years ago

I don't think I understand what line you are trying to draw. We wanted to be able to do two things (a) clean up the /TR page so it only showed 'current' versions, not historical and (b) if someone lands on an old spec., somehow, they get alerted that it's been superseded by something newer, and that's what they should implement, consider current, etc. Often, the new spec and the old have the same name but different version numbers, but sometimes there is a change of name (to protect the innocent) and what superceded what is not at all obvious to the non-cognoscenti of the web...

dbaron commented 6 years ago

I'm trying to draw a line for when a WG should use the Superseding process.

In other words, what my line would say that if CSS 2.0 has a "Latest version" link that goes to CSS 2.1 (which I believe is in the process of being fixed), then there's no need to publish a Superseded Recommendation for CSS 2.0 pointing to CSS 2.1. But at some point in the future, CSS 2.1 will be superseded by other CSS modules but there isn't a single target that the WG can ask to have its "Latest version" link pointed to, then there is a need to publish a Superseded Recommendation describing what has replaced it.

chaals commented 6 years ago

Noting that there is no requirement to supersede a Recommendation, I would approach it differently.

As far as I can tell, CSS 2.0 is superseded - by 2.1 - and it makes sense to republish it to make that clear.

While bits of CSS 2.1 are superseded by individual modules, the spec as a whole is not superseded.

IMHO it would be helpful to publish a new Recommendation which contains the "still live" bits, points to the relevant modules, and mark the current 2.1 as superseded by that.

If 2.1 were entirely superseded by new modules, and the WG doesn't want a "core" Recommendation spec, it would also be reasonable to publish 2.1 as superseded, and note that it is superseded by some collection of specs.

In either case, this is up to the WG to decide, since they are still active.

vfournier17 commented 6 years ago

Egads! This seems far too complicated! I agree with publishing a new version of a spec (2.1) and calling the prior version (2.0) superseded.

However, I wouldn't want to be the poor implementer who has to try to patch together "some collection of specs" that supersedes the prior spec (2.0). I think the logical expectation is that each version (2.1) supersedes the version before it (2.0)

chaals commented 6 years ago

Lucky for you, you are not that implementor.

Reality turns out to be messy. Some implementors have actively requested that specs be broken into various pieces, others that apparently unrelated things be bundled together. Where (and if) the lines are drawn ends up being somewhat ad hoc... and is generally guided by input from implementors.

I think we need to recognise that, allow for the diversity of reality that Working Groups face, and trust them to make reasonable judgements.

vfournier17 commented 6 years ago

How would you determine essential patent commitments and exclusion opportunities with a spec that's a hodgepodge of documents, or a one-off customized specification? I understand facing reality, but patent owners probably don't want to inadvertently grant a RF patent license because a customized or bundled spec was created, without an exclusion opportunity (e.g., combination claim patents).

nigelmegitt commented 6 years ago

If a spec is updated and bits of the old one remain unchanged but other bits are changed, and the overall scope of the spec remains the same, then the new spec should be a "whole new truth" so that the previous spec can be superseded in its entirety. In other words, we should normally copy across the unsuperseded parts rather than refer back to a "partly superseded" previous version. There are certainly examples where this approach has been taken.

Helping folk understand what has changed and not changed is important - that's why change summaries and logs and diffs are useful.

There's a separate conversation to be had here about best practices when modularising specs, but that's a whole other topic.

dwsinger commented 6 years ago

@vfournier17 happily we are only talking about slapping the label "superceded", and some text explaining where better to look, here. The actual development of the hodge-podge, mish-mash, or whatever, is part of the normal process, along with commitments, comments, and so on.

One of the reasons for the superceded status is where Bananas 1.5 was not superceded by the obvious Bananas 2.0, but by Veg and Fruit 1.0; or vice versa, where Veg, Fruit and Cheese 10.7 was superceded by Fruits 1.0, Veg 1.0, and Dairy Products 3.0 (which in turn superceded Milk 2.0). Labels and text are needed in this case to avoid the innocent getting stuck in apparent dead-ends.

vfournier17 commented 6 years ago

@dwsinger Got it, thanks.

fantasai commented 6 years ago

I would like to point out that the shortname of CSS2.0 and that of CSS2.1 are identical, i.e. 'CSS2'. (Historically, we had /TR/REC-CSS2 being 2.0 and /TR/CSS21/ being 2.1, but they were merged under the same shortname some years ago.)

@chaals This means that a republication of CSS2.0 to mark it superseded would have to be published as an update to CSS2.1... which makes no sense.

chaals commented 6 years ago

Hmm. https://www.w3.org/TR/REC-CSS2/ takes me to the CSS 2.0 Recommendation from 1998. https://www.w3.org/TR/CSS2/ takes me to the 2.1 Recommendation as edited in 2016. Republishing the 1998 document as superseded by the CSS2.1 recommendation doesn't seem like a problem to me - what am I missing?

Note by @frivoal : While true at the time of writing, "https://www.w3.org/TR/REC-CSS2/ takes me to the CSS 2.0 Recommendation from 1998" is no longer true as of 2018/10/02, as the redirect mentioned in https://github.com/w3c/w3process/issues/183#issuecomment-386848395 has been put in place

dbaron commented 6 years ago

The CSS WG has asked the team to redirect https://www.w3.org/TR/REC-CSS2/ like it also redirected https://www.w3.org/TR/CSS2/ and https://www.w3.org/TR/CSS21/ to the latest CSS 2.1. That was just an omission.

Given that it was an omission -- is the right thing to do to ask the team to fix the "latest version" link that was missed along with all the other latest version links -- or is it to go through the superseding process? That was part of my original question.

chaals commented 6 years ago

OK, I think I understand.

There are various versions of CSS 2.0 and 2.1 at various URLs. Some say they are outdated, others don't. It makes sense to me republish 2.0 specs as superseded, with pointers to whatever superseded them.

It may be sensible to point to some moving target of "the latest Rec", or it may be better to point to the next thing in the chain and let people follow the path. Or both. That is something I hope the CSS WG can figure out, because as far as I am aware there is no currently agreed best practice...

In the meantime, it's reasonable to ask the team to rationalise the various shortnames that have been used, again as the CSS WG thinks is most helpful.

frivoal commented 6 years ago

I think that:

Under these set of rules, all the CSSWG needs to do is to make https://www.w3.org/TR/REC-CSS2/ (undated) 301 to https://www.w3.org/TR/CSS2/, which we have resolved to do anyway.

dwsinger commented 6 years ago

Yes. I think those are fine guiding practices. I think we kinda expect "latest version" to point at something later when the shortname has not changed, so formal "superseded" may not be needed (but it's harmless). The case to use the state is where otherwise the order of succession is not clear.

dwsinger commented 6 years ago

Is any action needed on the process document for this issue? If so, a pull request or clear edit would be nice.

frivoal commented 6 years ago

The Process itself doesn't speak of shortnames, and I don't think we should introduce that in there normatively just for the sake of this. However, I would suggest adding (a rephrasing of) my earlier comment as a note in the process, to help people understand how this part of the Process is meant to be used.

frivoal commented 6 years ago

I made https://github.com/w3c/w3process/pull/213 to resolve this issue.

frivoal commented 6 years ago

On the process CG call, some thought PR https://github.com/w3c/w3process/pull/213 was fine, and some thought it made things even more confusing. Will put back on Agenda+ once we've reached some more agreement.

wseltzer commented 6 years ago

@plehegar has offered to look at the CSS questions more closely, and shared this diagram: https://w3c.github.io/tr-pages/deprecation.svg

I think we can answer without changing Process.

dwsinger commented 5 years ago

will be handled as part of a general clean-up of this, as it'll need attention as we revise the Rec track and/or introduce Evergreen standards. Removing 2020 milestone.