Re: Review of Process 2020

On 12/2/19 2:56 AM, Carine Bournez wrote:
> 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.

Florian did mention "Ever-extending" as a possibility (referencing 
https://en.wikipedia.org/wiki/XMDF_(E-book_format)) ), if you're looking for 
Ever-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.

The proposal already allows for this:
   https://w3c.github.io/w3process/everblue/#charter

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

The Snapshot has Director's approval and CR-type patent implications (because 
it triggers an exclusion opportunity), and the Update does not (is equivalent 
to a WD).

There's (at least) two reasons for this:
1. The lawyers working on the WHATWG policy concluded that having snapshots 
was what they were willing to work with, so we're adopting the same PP model
2. This is a close model to the process we have today: CR does not change, 
other than to change its name to "CR Snapshot", and the ED gets published on 
/TR as the "CR Update".

See https://www.w3.org/wiki/Process2020 for more explanations of why we're 
doing it this way.

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

As the current PP has a facility for rescinding specifications, I think it's a 
fair assumption that it will continue to have such a process.

As for applying licensing obligations to CRs in addition to RECs, this is the 
main purpose for updating the PP, and one of the goals of the Process 2020 
update. If we're not going to do make that change, there's no reason to update 
the PP.

As for working under the assumption of an updated PP: we don't have time to 
wait for PSIG to adopt a new PP and then start working on Process edits to 
match. We have to work in parallel. If for some reason we can't update the PP, 
it's easy to remove the section. It's less easy to add it later when we're 
under a time crunch.

~fantasai

Received on Tuesday, 3 December 2019 06:26:10 UTC