Re: On latest everblue draft

> On Oct 24, 2019, at 15:45, Philippe Le Hégaret <plh@w3.org> wrote:
> 
> Feedback on
>  https://w3c.github.io/w3process/everblue/
> 
> - "a Candidate Recommendation Review Snapshot should be published within 24 months of the Working Group accepting any proposal for a substantive change (and preferably sooner)."
> 
>  are we sure we want a SHOULD here and not a MUST? 2 years is a long time since the last substantive change already... I guess I'm fine with a SHOULD start with and we can adjust later on based on experience.

I'm not entirely sure there's a very meaningful difference between should and must in this case: saying "the team must do foo" works, because the team is hired to to the work of the W3C, and can be held to it. We cannot actively force working group members to do things. We can even less force working groups collectively to do things that require consensus. So we can say "the WG must do foo, or else bar happens". But in this case, there's no bar that would happen, so without this else clause, must and should are mostly the same. must feels like a stronger encouragement than should, so it could be preferable, but I'd rather not open the door to other participants making up their own interpretation of "else", and say things like "it says must, and you didn't do it, so the process is void and I am no longer bound by my own obligations". Not convinced this would hold, but I'd rather not even go there.

> - didn't we agree to not trigger Call for Exclusions for the same document more than once every 6 months?

Right. Still need to add that. I think this ought to be a should, so that we have a little bit of flexibility to meet some externally imposed deadline (like when WCAG needs to be ready before a certain date to serve as the basis for legislation somewhere), or about publishing after 5.8 months to avoid longer delays due the Christmas break or some such.

> - it ought to be possible to move from a  Candidate Recommendation Update Draft (CRU) to Proposed Recommendation without forcing a new Candidate Recommendation Review Snapshot (CRS), as long as no substantive changes where introduced in the CRU since the previous CRS.

Good point. Will add.

> A few folks were suggesting yesterday that it was difficult to understand the proposal. I'd say that it's going to be difficult for Groups to understand or remember the different flavors we'll have within the REC. It's already difficult for them to remember those things with Process 2019... Imho, we'll need to present the materials from the point of use cases, rather rather then Process modifications, ie a version of the REC track for busy people. Depending on the nature of the technology or the nature of the changes, some path will be better than others. For LS folks, maintaining their specs as a Candidate Recommendation at all time will be the way to go. For Groups making incremental changes and/or interested in the Recommendation status, the full REC track or a set of REC updates will be the right fit, depending on the nature of the changes and the signal to the community.

Completely agree. We need an explainer document, and possibly several, targeted on use cases, as you said. It's already in the todo list, but not written yet.

—Florian

Received on Friday, 25 October 2019 06:45:57 UTC