Re: [EXTERNAL] Re: Review of Process 2020

On 12/3/19 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 support this rant.

--Wendy

> 
> 
> 
> 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.
> 


-- 
Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office)
Strategy Lead and Counsel, World Wide Web Consortium (W3C)
https://wendy.seltzer.org/        +1.617.863.0613 (mobile)

Received on Tuesday, 3 December 2019 17:12:12 UTC