Re: [EXTERNAL] Re: Review of Process 2020

On 12/3/2019 12:10 PM, Michael Champion wrote:
>> It sounds a bit too close to "expendable" to me :D
>> Maybe we could indeed ask for more suggestions. I don't
>> think I have good ones: "elastic", "organic"
>> Ever-something seems a better idea, but we'd need to find the something.
> 
> <rant>
> How about “Recommendation.”  You have to ask yourselves whether the distinction between “Recommendation” and “Living/Extensible/Expandable/Elastic/whatever Recommendation” will matter in the real world.  Who (outside the W3C process community) will understand or care about the distinction?  If they do care to some extent, do they care enough to invest the time wordsmithing/building consensus on how to describe the distinction and defining the different processes?
> 
> I’m skeptical that this naming problem is worth the effort being put into it.  Recall that ”naming things” is  one of the canonical hard problems in this field. https://www.martinfowler.com/bliki/TwoHardThings.html.  Words mean what they come to mean in practice in some community.  For example, IETF “Request for Comment” documents are treated as “standards”  *if* they are implemented, referenced, maintained, etc.  The Real World, not some political/bureaucratic process, determines whether specs have the various desirable characteristics such as stability, interoperability, accessibility, privacy protection, internationalizable, etc
> 
> If, for the sake of argument, you conclude that the distinction is worth making, I suggest sticking with Living Recommendation.  Semantically, yes it implies that regular Recommendations are non-living, i.e. “dead”.  But  the web standards community has learned what “Living” means in this context. And the various alternatives also imply that regular Recommendations imply the semantic opposite of the qualifying word: static, inelastic, constrained,  or for that matter Divinely Created rather than Evolving 😊
> </rant>

I think it's perfectly fine to call them Recommendations as well, except 
for the Living Standards.

Note that, if we conclude that the Process document has to differentiate 
them (such as we can make distinctions in charters for example), this is 
still not a showstopper to just keep calling them Recommendations on the 
outside. A parallel is how we do "Edited Recommendation" or "Amended 
Recommendation" today. It's mentioned in Process 2019 [1] but we don't 
make much of a distinction in the documents themselves [2].

For the Living Standards, those are "profiles" or "workmode" on top of 
the Candidate Recommendation stage, not the Recommendation one. Some 
will care about the distinction and some won't. We could do for example 
something like:
"W3C Candidate Recommendation - Living Standard, 3 December 2019"
or
"Living Standard
W3C Candidate Recommendation, 3 December 2019"

In other world, they remain CR but are advertised as Living Standard.
This would distinguish them from the other "normal" Candidate 
Recommendation.

Philippe

[1] https://www.w3.org/2019/Process-20190301/#revised-rec
[2] https://www.w3.org/pubrules/doc/rules/?profile=REC-AMENDED#dateTitleH2

> 
> 
> From: Carine Bournez <carine@w3.org>
> Date: Sunday, December 1, 2019 at 11:56 PM
> To: Florian Rivoal <florian@rivoal.net>
> Cc: Jeff Jaffe <jeff@w3.org>, public-w3process@w3.org <public-w3process@w3.org>, Wendy Seltzer <wseltzer@w3.org>, Philippe Le Hégaret <plh@w3.org>
> Subject: [EXTERNAL] Re: Review of Process 2020
> On Mon, Dec 02, 2019 at 04:20:38PM +0900, Florian Rivoal wrote:
>>      2. I still don't like "Extensible".  Several alternatives were proposed.
>>      What is our process to bikeshed the name?
>>
>> Ideally, I'd like more than 3 people involved... but switched it to Expandable
>> for now.
> 
> It sounds a bit too close to "expendable" to me :D
> Maybe we could indeed ask for more suggestions. I don't
> think I have good ones: "elastic", "organic"
> Ever-something seems a better idea, but we'd need to find the something.
> 
>>      3. 5.2.6.  There has been discussion in the W3Process CG that it might make
>>      more sense to allow every WG to decide what to designate as an Extensible
>>      REC rather than having this done in the Charter.  While I don't feel
>>      strongly, I felt that this opinion was getting greater traction from
>>      reviewers.  Taking that path might simplify some of the Process document
>>      text.
>>
>> The goal of placing a constraint on non-Expandable RECs is not to better fit
>> the WG's work-mode, but to make a promise to the outside world that a REC will
>> not gain new features.
> 
> It won't be always easy to determine whether the REC will or will not be
> extensible at charter time. The best solution would be to have a MAY:
> the charter MAY indicate that the deliverable is an extensible REC,
> otherwise the WG will determine later.
> 
> I like the subsequent proposal to merge and only have 1 kind of REC,
> because since the start of the development of the evercolored process
> I've seen a risk of getting a "low-class REC" compared to the other.
> 
> 
> [...]
> 
>>      9. 6.2.  I think we have a capability now for Documents to come in at CR
>>      level (i.e. CR = FPWD for those documents).  I don't know if that is clear
>>      enough in the process doc.  We are using it, for example, for DOM and HTML.
>>
>> Hmmm. Interesting problem. I don't think there's anything in the process that
>> allows for that. FPWD is supposed to come before CR, and the Patent Policy
>> seems to have this as an assumption (not sure anyone has evaluated the
>> consequences of breaking that assumption).
> 
> It's been used a couple of times, and the PP FAQ mentions something
> about the exclusion opportunity length, IIRC (the FPWD opportunity
> covers the CR one).
> 
>>      10. 6.2. CRUD.  I thought we were going to work on the acronym.
>>
>> Lol. Done.
>> s/CR Update Draft/CR Udate/
>> s/CR Review Snapshot/CR Snapshot/
> 
> I find this distinction still rather confusing (just my 2 cents).
> The goal of having it is unclear in the document.
> 
>>      11. 6.2. Rescinded CR.  I'm not clear on why we need that.  We seem to have
>>      too many states already.  Can we just call it a Note?
>>
>> No, because rescinding something has implications for patent obligations. If we
>> adopt the updated Patent Policy which applies obligations to CRs, we will need
>> to be able to rescind CRs as well as RECs.
> 
> Making assumptions on a future PP is a bit speculative. If you start
> with a simpler process and complicate it only if the PP needs it, we
> might end up with a simpler process as a result.
>

Received on Tuesday, 3 December 2019 20:07:10 UTC