-
Notifications
You must be signed in to change notification settings - Fork 132
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
Concerns about Amended Recommendations #137
Comments
I wouldn't want to make things too hard, since I feel that good maintenance of specifications is important, and the desire for maintenance is what I think led to the creation of Amended Recommendation. I would think the goal would be for changes (e.g., incorporation of errata) that are small enough that chartering a new working group wouldn't be appropriate. Maybe that should be stated explicitly if it isn't already? Maybe some additional protection might be appropriate, such as:
|
I think we're going to run with the formal process for the next year, and see how well we do in clearing backlogged maintenance without causing more problems than we're solving. I encourage everyone to watch the process and see whether things slip through cracks. |
Separate Obsolete and Superseded, clarify that Amended Rec has patent policy implications. See also #137
I share @dwsinger 's concerns about Amended RECs. But also, as far as I know, since the idea was introduced, the W3C has never actually issued an Amended REC. As there have been complaints about the Process being too long, a controversial area that isn't getting used seems to be a good candidate for removal to me. It was for a time a trendy idea that working groups should be shutdown once they've have accomplished their main goal. I don't believe this is a popular view any more, and that we now generally prefer to keep working groups around when the technology they've specified is in active use, so that they can do maintenance. A number of changes in Process 2020 should make that easier too. If we really want some way for the Team to do something with specs that no longer have a working group, we could still do away with Amended RECs, and allow the team to annotate out-of-charter RECs with candidate corrections |
The Amended Recommendation path was indeed never exercised so far. WebCrypto was the prime example for it but lhas been lacking an individual to do the actual work. Spatial also came close to use it but then is choosing the path to recreate a Working Group instead. I also concur that the latest thiinking is to swiotch WGs into maintenance mode rather than closing them. |
@frivoal Don't Candidate Changes also require a WG? I think we should make it easier for WGs to be chartered to or transitioned to maintenance mode, but in cases where there is no one interested in participating in a WG and the Team concludes that a change is necessary, it seems reasonable to allow it. But wouldn't we need to add some allowance in the Process for the Team to make such annotations then? |
Candidate changes are class 2 changes, and based on sections 6.2.11.2, the Team can do publish new RECs with class 2 changes:
I think this could use a bit of editorial tweaking, to say "The Team" instead of "W3C", and probably split it into two sentences to make it easier to read. 6.2.11.1 has similar phrasing, which could be tweaked for readbility as well. 6.2.11.1 Current:
Proposed:
6.2.11.2 Current:
Proposed:
|
Maybe this also need the following insertion in 6.1.5
|
Maybe we also need something in 6.1.4 allowing the Team to maintain errata when there's no WG. This could be done by adding this at the end of the last paragraph (or as a new paragraph after it)
|
Resolution recorded at https://www.w3.org/2020/09/16-w3process-minutes.html#x030 |
From Andreas in AC review:
Amended Recommendation
Change
Comment
Although this is not marked as blocking comment (to not disrupt the process), there are strong concerns regarding this change. The intent, to bug fix a recommendation when the responsible working group does not exist anymore, is understandable. But the current form leaves a lot of questions open and possibly also gives to much freedom to the W3C team to change a recommendation. The context for an Amended Recommendation need to be better defined. It should be defined which requirements could lead to an Amended Recommendation. What attempts have been made to re-charter a Working Group or at least what have been the reasons to not start such an attempt. The W3C team may not always have the subject matter experts. How do they decide to adopt a change or not? Can an Amended Specification supersede an existing recommendation or make it obsolete?
The text was updated successfully, but these errors were encountered: