Section 6.2 does not acknowledge Perpetual CRs #406
Comments
|
I'm not sure why we would remove the cited text since it applies in many cases. Perhaps we can say: "whether the specification is appropriate as a W3C Recommendation or provide any other feedback" |
|
@jeffjaffe I heard earlier today that some groups are not interested in ever achieving Recommendation and therefore the membership should not be asked/requested to provide feedback on this topic in general. |
|
@palemieux some groups may not be interested, but they may change their views. HTML and DOM are interesting use cases. The WHATWG does not feel that there is a need for W3C RECs for these specs. But we've all agreed on a process where W3C is bringing them to REC - because there is a demand for that. |
Perhaps... the membership should however not be asked to provide feedback (which requires work) when the group has explicitly they are not interested :) [edit: typo] |
|
I am inclined to leave the text. A CR should be suitable as a Rec., even if the WG doesn't intend to take advantage of that suitability. |
@plehegar mentioned that the CR can have substantive issues opened against it, making it inappropriate for REC, right? |
I think he said that after entering CR a spec. might have issues opened against it, and we don't require it to back out of CR. We do have some cleanliness requirement when entering; but we shouldn't be surprised if we encourage people to implement, and they find issues when doing so. |
It may not be intended to become a REC, but it still out to be appropriate for becoming a REC. Choosing not to follow the steps after CR does not lower the quality expected of a CR. I think we could replace "is appropriate" with "would be appropriate", but I don't think we should remove this altogether. I think you might also be supportive of the following addition:
|
This point seems to have migrated here from #402, so reposting slightly edited version of #402 (comment): CR being the intended end state should not be acceptable. This is like saying "the intended state is permanent lack of clarity about the status of this work in the industry". W3C should never support this as an end state for a Rec track document. Even in the "Rec snapshot of continually updated document" model there are at least fixed points of clarity. |
|
Also to add, I know there are groups that have a lot of specs seemingly permanently in CR status, but that should not (must not) be the intended end state. I've assumed that we accept this situation as something transient, albeit over a number of years. There's no other way this situation can be acceptable. |
|
To be concrete about a proposal for discouraging perpetual CRs, one option for discussion would be as follows:
This proposal would require WGs to state the CR exit deadline, but gives the AC the explicit opportunity to see, and comment on the proposed maximum CR period during Charter review, thus providing a strong mechanism to support the suggestion that @jeffjaffe made at #402 (comment) It would also be possible for WGs to establish a "keep-alive" pattern by republishing a CR with modifications for example reducing the scope by marking features as at-risk, and in doing so, extending the deadline. |
We are trying to balance a whole load of possible undesirable aspects; documents that are kept permanently in draft because they are easier to keep up to date; recs which don't represent truth because maintaining them is a pain; documents that naturally slowly iterate and evolve; clarity for the industry as to what the approved state is, the current state, the best practice, the open questions; dealing with the W3C being famous for having no idea when things will 'finish' (if ever); and so on. I'm not sure that I want to apply a rule that "Recommendation status is the gold standard" to every case (just as I wouldn't apply WHATWG's "Living standard is the gold standard" to every case either). So I would rather go easy on new rules. yes, CRs need to pass various criteria, and be clear what they claim, including being suitable as a Rec. Let's see what happens, what cases arise, and so on, before we pre-emptively rule. |
This is the crux of the issue: suitability as a REC involves AC review and demonstrated implementation experience. Neither of which apply to a CR. The process document need to either:
I am not sure why there is resistance to making this explicit, esp. in introductory prose. One way to discourage TRs from remaining CRs at perpetuity is to make transition to REC easier:
|
Those review steps don't, but we require that the document itself be suitable as a Rec.:
There is resistance to making anything more explicit because it's making a change from current practice, which is that CRs do not have deadlines and can (and have in the past) stayed in CR for long periods. 'Indefinite CRs' are not an invention of this iteration. |
A requirement is meaningless and time consuming if it is not enforced -- the worse kind of requirement :)
The process is specifically modified to accommodate them, so I do not think this statement is entirely accurate. |
We do enforce it. The team and others have pushed back on CR transition requests when the document is not of this quality. |
The Team is not the W3C membership, and the CR transition request does not evaluate implementability, let alone interop. |
That is a different point. The purpose of a CR is to get community input on implementability and interop. You claimed that the requirement for CR quality is not enforced; it is. I believe that we, overall, the team and Director, have refused CR transitions in the past. |
I indicated that "suitability for REC" cannot be enforced during CR transition since CR transition does not include AC review and does not evaluate implementability, let alone interop -- as I understand it anyway. I am uncomfortable with the process facilitating perpetual CRs without acknowledging them. A simple sentence would address my concern. |
@dwsinger Understood, and I agree this is not simple. Rather than trying to solve all of that at once, but looking at what I think is a big problem: "dealing with the W3C being famous for having no idea when things will 'finish' (if ever)" is something we can do something about, and my proposal would a) produce a published timeline for exactly this and b) provide additional impetus to encourage WGs to meet the timeline.
Sure, and if a WG does not want to get to Rec then they shouldn't be in the position of publishing a CR.
We've seen what has happened, this is far from pre-emptive. The problem has existed for years, and continues to exist. This is not a new thing. |
|
@nigelmegitt I rather like the idea of including guidance about moving along the REC track as you indicate below.
However, the specific example guidance that you provide is rather coercive. It includes requirements to abandon specs because some deadline is not achieved. We all know that deadlines are missed for all sorts of good reasons. Even well intention deadlines included late in the cycle have been known to fall if (for example) some new privacy issue is discovered. And I see that there is also resistance to providing such guidance This entire notion is quite complex and coming quite late in the cycle to get consensus around new text. Would it make sense to open a new issue called: "Guidance for moving along the REC track" and address that as part of Process 2021? |
@jeffjaffe I agree with all of this! The proposal does deliberately allow the deadline to be extended by republishing with changes, and my intent in allowing that was to accommodate these sorts of issues. In other words, it possibly looks slightly more coercive than it actually is, again, intentionally. I'm unclear about the deadlines for Process 2020 (sorry, I just haven't gone back to look at the documentation that no doubt already exists) but perhaps it would still be worth verifying whether or not we do have consensus before assuming that we do not? There hasn't been a lot of time since I posted the proposal, so it is likely that people are still thinking about it, but nobody has so far objected. |
|
By the way, #406 (comment) is not intended to be mere guidance, it is a specific proposal for a change to the Process that includes normative provisions the effect of which is intended to change the balance of incentives for WGs so that they are more likely to complete specification work to Rec stage, or abandon it, and not leave specs in CR in near-perpetuity. |
@nigelmegitt here are the timelines for Process 2020:
I agree with you that we should verify whether we have consensus. My reading of comments made by David and Florian above and Fantasai's comment on #402 (#402 (comment)) gave me the impression that we don't have consensus - but we should verify that. My view is that if I am correct that we cannot get consensus in a month we should push it off for P2021. |
|
Bear in mind @jeffjaffe that introducing the P2020 changes while failing to address perpetual CRs may also lead to difficulty during the AC review. I've responded to this issue in an attempt to get to a solution that would reduce those issues before they arise; I understand your concern that my proposal may in fact create new issues. I'd be interested to know if the AC's opinions have been informally canvassed, and if so, what the result was. |
|
re: #406 (comment) I don't think we should adopt language that has several musts and such broad applicability and potential impact across the consortium without careful conversation with the chairs, team, and AC. I have been frustrated at the W3C's inability to establish target dates and stick to them (there was a famous multi-year incident with MPEG and SVG, IIRC), so I am not averse to addressing the question. I am very hesitant to do so at such a late stage. Actually, opposed; I think it imprudent. (And it is not, as Nigel says, a new problem, but one perhaps highlighted by the P2020 changes). I'm not even sure that it is a problem; the IETF runs on CR-equivalents (RFCs), though those do say something different from our CR-status:
|
|
@nigelmegitt I don't think your proposal in #406 is workable. Arbitrary deadlines have never motivated volunteer engineer-driven efforts in continuously-evolving tech such as we have in the web platform WGs. We've had deadlines in charters for years, and they've never functioned as anything other than noise. I think my position is that there will be CRs that remain CRs indefinitely. Process 2020 was designed to allow for that, because there was demand for that kind of thing. But indefinitely doesn't necessarily mean in perpetuity, and if some subgroup decides to push a CR towards REC to get W3C endorsement as opposed to only WG endorsement, and to clearly acknowledge a greater state of interoperability, that's a good thing and we shouldn't write in rules that would discourage such efforts. |
|
I agree with a lot of what @nigelmegitt is saying, including the fact that how we handle this issue now will have an impact on the formal AC review of the Process document. I believe that the sort of thing Nigel proposes can be made feasible and not terribly onerous. That said, the question should be put to the community, as we do in AC review, because there are issues of what the community actually wants and is prepared to put up with and do. As I have said a number of times, I believe we are trying to solve the problem of versioning without mentioning versions, and I believe that's leading us to conclusions that are sometimes suboptimal, without explaining why we should do that. A versioning strategy like "request the transition of a document to CR of version x and FPWD of version x+1" can be built in the existing process giving you get two branches of a spec - one that you remove things from if anything doesn't work, and one that you add things to because you're still developing it. Given such a scenario it is possible to set the expectation that W3C will withdraw the status of CR for anything that isn't at Proposed Rec 9 months after entering CR. After all, if there are lots of changes then in practice it is still a working draft and there needs to be more review and so on anyway. Of course it depends whether we believe that things can be done right in each version, or assume that a Recommendation isn't really a final thing, just a time-stamped reference point so people who value stability over having the latest of everything don't have to individually select a particular draft for each agreement they make. Which is essentially a restatement of how I understood the feedback from PSIG on continuous patent review, generalised to cover people who are not specifically interested in patent claims but also do not want to be capable of writing the spec, just want to use it. (See the "priority of constituencies" ...) |
That's fair, we should present this. I'm not sure what "careful" implies here, but I certainly would welcome the views of those constituencies on the severity of the issue and the range of proposed solutions, going from the fairly hard-line one I proposed, to the softer "make it easier to get to Rec", or indeed doing nothing. I could write up my thoughts and the proposals here in a wiki page or somesuch, if that would help - suggestions welcome. [IETF-style CR as RFC]: Changing the status of a CR would be an option, but if we were to do that, we would be rebadging it as the final stage and doing away with AC review, even of due process, and implementation experience. My prediction is that we would see hardly any specs ever go to Rec.
To be clear, I do see CRs staying at CR perpetually (given the way that CR and Rec are defined now) as being a big problem:
On the second bullet, the formal referencing problem, we do not have any mechanism, when republishing or amending a CR, for tracking those specs that reference the CR being changed, and therefore we leave it up to the WGs whose specs might be affected to notice the change and handle it. Those WGs may no longer exist. |
@fantasai I'm not proposing an arbitrary deadline imposed by the W3C, but a deadline proposed by the WG themselves. Another key difference relative to previous deadlines is that in this case I am proposing an assigned action to take if the deadline is not met, with a way out if it there are genuine mitigating circumstances. This is materially different to anything we have had before.
Sorry to contradict, but practically, I believe that's exactly what it means.
Indeed, and no part of my proposal is discouraging it. |
|
@chaals I agree, modifying this to deal better with versioning may well work, and may well be an improvement. If Rec is merely a time-stamp though, then this issue could be resolved by diluting the requirements for getting to Rec. However I still value the fact the two key planks of Rec relative to CR today, which are implementation and AC review. I would still value this AC review even if it were changed as per @palemieux 's proposal to establish only that a) process has been followed and b) the spec represents the consensus of W3C. |
|
I think the problem is that the introduction to 6.2 roughly and incorrectly paraphrases the detailed descriptions in 6.2.1 et seq. I would do the following light, non-normative (since it's only introductory text) edit:
|
|
Same thing as a diff, if that helps anyone else review: When advancing a technical report to Recommendation,
typically a series of Working Drafts are published,
each of which refines a document under development
to complete the scope of work envisioned by a Working Group's charter.
For a technical specification,
once review suggests the Working Group
- has met their requirements satisfactorily for a new standard,
+ has met their and their dependencies' technical requirements,
+ and has received wide review,
there is a Candidate Recommendation phase.
This allows the entire W3C membership to provide feedback
- on whether the specification is appropriate as a W3C Recommendation,
+ on whether the specification would be appropriate as a W3C Recommendation,
while the Working Group formally collects implementation experience
to demonstrate that the specification works in practice.
The next phase is a Proposed Recommendation,
to finalize the review of W3C Members.
If the Director determines that
W3C Member review supports a specification becoming a standard,
W3C publishes it as a Recommendation. |
|
Answering @palemieux #406 (comment) how about this addition? When advancing a technical report to Recommendation,
typically a series of Working Drafts are published,
each of which refines a document under development
to complete the scope of work envisioned by a Working Group's charter.
For a technical specification,
once review suggests the Working Group
- has met their requirements satisfactorily for a new standard,
+ has met their and their dependencies' technical requirements,
+ and has received wide review,
there is a Candidate Recommendation phase.
This allows the entire W3C membership to provide feedback
- on whether the specification is appropriate as a W3C Recommendation,
+ on whether the specification would be appropriate as a W3C Recommendation,
while the Working Group formally collects implementation experience
to demonstrate that the specification works in practice.
+ There is no limit in this Process to the duration of this phase.
The next phase is a Proposed Recommendation,
to finalize the review of W3C Members.
If the Director determines that
W3C Member review supports a specification becoming a standard,
W3C publishes it as a Recommendation. |
|
The proposed changes do not address my primary concern which is that the membership should not be asked to review a specification for appropriateness as a REC if there is no intended to ever publish it as such. |
|
The membership, the industry, is being asked to assess whether it meets that quality. We go by state, not by intent. And even if there is intent, it can be changed on request (please publish a snapshot Rec.) |
Recommendation-level quality requires demonstrated implementation experience, which some perpetual CRs will never meet, by decision of the WG. Why would you ask the membership to provide feedback on something that the WG is never intent on addressing? |
|
@dwsinger What does "on whether the specification is appropriate as a W3C Recommendation" bring to the introductory paragraph? This allows the entire W3C membership to provide feedback on the specification, while the Working Group formally collects implementation experience to demonstrate that the specification works in practice seems to describe accurately what is being asked of the industry and the activities of the group. |
|
I see a hard conflict between @dwsinger and @palemieux . David wants to continue to ask whether the spec is appropriate as a REC and Pierre objects in certain cases (Perpetual CRs). Much earlier in this thread, I proposed a compromise: "whether the specification is appropriate as a W3C Recommendation or provide any other feedback" This retains the "ask" that David wanted. It leaves open that the feedback is not only about the REC. David, can you agree to this? Pierre, above, seemed to have issues with my compromise. I didn't fully understand his issues. Now that Pierre has been exposed to the degree of resolve from David, Florian, fantasai, et.al., I would like to ask again whether this compromise could work. If not, then I would ask Pierre - knowing as he currently does - the perspective of the others if there is a different compromise he could provide which addresses both his issues as well as David's. |
|
@jeffjaffe I have asked @dwsinger to explain why he believes the clause on whether the specification is appropriate as a W3C Recommendation is important. |
|
I believe that this sentence could be changed to: "whether the specification would be appropriate as a W3C Recommendation", it still works for that specs that are actually intending to go to REC soon, and for those which might be at CR indefinitely, it still works in the sense that a CR is expected to have the quality of a REC (minus implementation experience), and so asking whether that's the case functions as quality control. Also, I want to point that a spec being in CR indefinitely is not the same as a spec being in CR permanently. The lack of a decision to go from CR to REC is not the same as an enforceable decision never to do so. I do not think we should endorse a process which made it possible to make a spec that gets to CR and then cannot got to REC. There might not be any immediate plan to take it to REC, and current members, if asked, might answer that they have no interest in doing that, but it should still be a possible next step, and as such a CR-with-no-immediate-plan-to-move-to-REC should still be as capable of moving to REC as any other CR, should we actually push for it. And therefore, validating "whether the specification [is | would be] appropriate as a W3C Recommendation" is relevant. |
|
Also, I want to insist that we have not created a new "perpetual CR" animal. We took the explicit decision to not create a separate process with a different track, one leading to REC, one not. We just have FPWD, WDs, CRs, PR and REC, as we always had, and the entrance / exit criteria of each stages is unchanged, very much by design. Progress along that track has always required, and continues to require, group consensus. Absence of consensus to move further means we may remain at a particular stage for indefinite periods of time, not that a group can enforceably decide that moving further will be permanently impossible. |
|
we agreed to Change "This allows the entire W3C membership to provide feedback on whether the specification" to "This allows the entire W3C membership to provide feedback on the specification"; leave the Note as a Note for now; file an issue to clarify CR and Rec quality and maybe convert the Note or parts of it into Normative text (for a future process). |
frivoal
added
AC-review
Section 6.2 states:
For a technical specification, once review suggests the Working Group has met their requirements satisfactorily for a new standard, there is a Candidate Recommendation phase. This allows the entire W3C membership to provide feedback on whether the specification is appropriate as a W3C Recommendation, while the Working Group formally collects implementation experience to demonstrate that the specification works in practice.
Suggest removing on whether the specification is appropriate as a W3C Recommendation since some CRs are not intended to become Recommendations.
The text was updated successfully, but these errors were encountered: