Do we need a lighter-weight process for superseding when it's "obvious"? #324
Comments
|
I think it can be valid for 1.7 and 2.0 to both continue to exist and be maintained (and therefore for 1.7 not to be declared as superseded), for instance if 2.0 has an expanded scope, a some users of the specification count on it having a fixed scope (and be maintained). This is generally not terribly important for the web itself (https://www.w3.org/2001/tag/doc/evergreen-web/), but other industries linking into our specifications sometimes care. If we don't maintain 1.7, marking it as superseded seems the right thing to do, since 2.0 has all the bug fixes in addition to having all the new features. Wwho gets to make the call that we will, or will not, maintain 1.7? That sort of feels like an AC decision, but at the same time, if a WG can't/won't do the actual maintenance, maintaining the fiction that 1.7 isn't superseded isn't really helping anyone. |
right. it is a choice. SMIL1.0 was used much more than SMIL2.0, for example.
Right, the normal (and uncontroversial) case is that 2.0 is the best thing to read if you are coming in fresh.
I almost wonder whether the AC should be involved if the WG has done something that 1.7 is still a viable spec. That's the odder case. |
|
So, I propose: In the case of two specifications issued by the same Working Group, where the name of the specifications differs only in the version number, the working group alone may decide that the later supersedes the earlier; neither AC nor formal Director Review are needed. |
|
David Singer <notifications@github.com> wrote:
So, I propose: In the case of two specifications issued by the same
Working Group, where the name of the specifications differs >only in the
version number, the working group alone may decide that the later
supersedes the earlier; neither AC nor formal >Director Review are
needed.
This makes a lot of sense.
…--
Using Opera's mail client: http://www.opera.com/mail/
|
|
The Process doesn't have a well defined notion of version number (this might be something we want to fix as well, but for now it doesn't). So I'd suggest tweaking your proposal not to rely strictly on it. With a couple of extra tweaks, maybe something like:
|
|
Hmm. In order to publish a new Recommendation, there is already a review. The extra work to note that another spec will be superseded, as part of that review, is trivial - about as lightweight as you can get. So I am not sure we are solving a problem by adding this extra piece of process machinery. |
|
@chaals this is roughly what we're asking; in cases where it's obvious — like the WG producing and sending to PR and Rec an obvious new version — we surely don't need the full Director and AC review we use today. I'm not sure it even needs saying in AC review of the new Rec. I'd like the WG to be able to say that JSON LD 1.1 supersedes JSON LD 1.0, as indeed the opposite — that we continue to Recommend the older spec. in addition to the newer one — is the odder case. |
|
I believe the point (in David's example) is that when the WG takes JSON LD 1.1 to the Director/AC for approval as REC, by merely "saying" that it supersedes 1.0 they are getting Director/AC approval with no extra work. So the process machinery does not buy you anything. |
|
+1 to @jeffjaffe . Supporting the use case mentioned (the "obvious one") basically requires a sentence in the transition request noting that one document supersedes another, the team to ensure that is in the AC review request, and the editorial work to prepare for that to be implemented, with no new process required. |
|
It's possible, indeed that a sentence that the request to supersede may be combined with the PR progression of the superseding document, would suffice as well. But that would the case where the progression happened without this sentence, alas, which might be quite a bit of cleanup (both of history, and for WGs that forget to ask this on their PR progressions). So, two choices (so far):
or
|
|
Actually we can combine this: make the future simpler and enable cleanup of the past.
|
|
pointed out that the AC should nonetheless know and be able to object:
|
|
still some doubt over whether we need the second part... |
|
and since the first part is practice, does it need mention? close? |
|
+1 to closing |
|
The Revising W3C Process CG just discussed The full IRC log of that discussion<fantasai> Topic: Superseding<fantasai> github: https://github.com//issues/324 <plh> david: we saw recently a survey to supersede JSON-LD 1.0 <plh> ... that's something the WG can decide <plh> ... my suggestion is to allow groups to supersede their own spec with a new spec <jeff> q+ <plh> David: (read his proposal) <plh> q? <chaals> q+ to speak against the proposal <jeff> q- later <plh> florian: I dont' feel the urge but support the proposal <plh> q+ <plh> q? <dsinger_> q? <jeff> q- later <florian> s/the urge/the urge as strongly/ <dsinger_> ack cha <Zakim> chaals, you wanted to speak against the proposal <plh> chaals: don't think we should do this. this seems procedural. <jeff> q- <plh> ... there are cases where WGs might think the world moved to change a new version and the world disagree <dsinger_> q+ to respond to chaals <plh> ... the AC is moderately a reflexion of reality in this case <plh> ... it should still be an explicit review <plh> ... in your PR review, you may do this <dsinger_> q? <dsinger_> ack plh <fantasai> plh: There were two aspects of the proposal which helps with chaals's concern <fantasai> plh: One is if ... and we forgot to task the AC as part of its review. <fantasai> plh: Second, it only allows WG to do that if there is a newer version <fantasai> plh: There's no newer version if you don't have a REC that's been approved by the AC <dsinger_> q? <fantasai> dsinger_: We're talking about superseding, not obsoleting <chaals> [Yeah, I do want the AC to have that specific review] <plh> david: we're not talking obsoleting, just superseding. both versions remain available and there is always a long transition for the market to update <plh> ... it is just a statement of the fact that there is a newer version <dsinger_> q? <plh> chaals: unconvinced but won't block <dsinger_> ack ds <Zakim> dsinger_, you wanted to respond to chaals <jeff> q+ <plh> florian: if the AC feels strongly about something <jrosewell> Agree with @dsinger that there is an established norm to transition from one version of a specification to another and it's up to implementers to decided when to transition from one standard of interoperability to another. <plh> ... you can state that in the charter <chaals> s/won't block/won't block consensus if I am the only dissenter <plh> david: yes, and you can always object after the fact <plh> fantasai: can we require an announcement to the AC list. give a 2/3 weeks to allow for objection. <plh> david: yes, that would work <fantasai> s#2/3#2-4# <fantasai> s/objection/objection, otherwise it passes <jeff> q? <plh> florian: you can't apply it today since it calls for an explicit AC review <plh> [some wordsmithing] <jeff> q? <dsinger_> q? <dsinger_> acj jeff <plh> david: ok, will leave it open for cycle but we're converging <dsinger_> ack jeff <chaals> [One reason I don't think this is a critical issue is because we have gone a couple of decades without solving this minor part of the versioning problem, so taking a couple of years to normalise superseding doesn't seem like a terrible problem.] <fantasai> [I could go either way. I neither feel strongly that we need this, nor that we should not have it.] <dsinger_> q? <plh> jeff: today, we do an AC review and if no one objects, it goes through. we're now proposing a notification now. looks like we're adding a new process because of a mistake <plh> david: there is a long tail of things that should have been superseded but too much process to go through <plh> florian: for the notification, it heard it was just announcement but giving the opportunity for folks to object <plh> david: asking trivial questions, we diminish the visibility of other surveys <dsinger_> s/there is a long/q? <dsinger_> s/q?/there may be a long/ <dsinger_> q? <plh> jeff: seems like we want to fix a mistake by process <tantek> +1 right we don't need anything now for this, just more practice with superseding and obsoleting <dsinger_> ack fanta <plh> david: ok, then maybe we don't need the second sentence <plh> florian: we're already doing the first sentence by practice <plh> ... so, we may not need to add the first sentence <plh> jeff: close the issue? <plh> david: I'll leave it open but it's now a candidate to close <plh> ... with nbo action <plh> s/nbo/no/ |
|
The Revising W3C Process CG just discussed
The full IRC log of that discussion<fantasai> Topic: Superseding<fantasai> github: https://github.com//issues/324 <fantasai> RESOLVED: Close no change |
css-meeting-bot
removed
the
Agenda+
Forked from #213
There seem to be three cases of interest.
Only one document actually appears on /TR, the 'latest version' link in all of them point to that document. No action needed, you have effectively superseded. The WG or team can edit the old ones if they like and can (without changing their name or date or URL), but the existence of a different document at the Latest link should be enough warning to readers.
Both documents exist on /TR but one is clearly later, e.g. BadThing 1.7 and BadThing 2.0. They have the same specification name, and so on.
There is a document on /TR which has been superseded by something that's non-obvious or perhaps not even a W3C document (e.g. IETF has taken over work in this area). The process in the process should be proceeded with to ensure correct process procedure.
Case 1 is the subject of that issue/pull-request: (no, the formal supersedes process is pointless and un-needed here, and that pull will clarify it.)
Case 3 is covered by the existing full "do the AC and Director and everyone agree?" process.
But the process for case 3 might be much too heavy for case 2. Do we really need to ask the AC and Director to approve labeling BadThings 1.7 as no longer current and superseded by BadThings 2.0? Could we perhaps allow the WG to decide when that label would be helpful to readers of BadThings 1.7 (that if you're coming in new and without any reason to stay at 1.7, we think you ought to move to 2.0)?
What are the edges of that authority? That the specs were issued by the same WG and have (except for version number) the same name?
The text was updated successfully, but these errors were encountered: