Re: [EXTERNAL] Review of Process 2020

On 12/6/2019 2:01 PM, Florian Rivoal wrote:
>
>> On Dec 6, 2019, at 2:01, Jeff Jaffe <jeff@w3.org> wrote:
>>
>>
>> On 12/5/2019 12:02 AM, Florian Rivoal wrote:
>>>> On Dec 4, 2019, at 4:35, Jeff Jaffe <jeff@w3.org> wrote:
>>>>
>>>> On 12/3/2019 12:56 PM, Carine Bournez wrote:
>>>>> On Tue, Dec 03, 2019 at 05:10:21PM +0000, Michael Champion wrote:
>>>>>> <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?
>>>>> +1
>>>>> As I said in my earlier email:
>>>>> "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."
>>>> Well there is a certain elegance to just calling everything a Recommendation.  Everything is first class!
>>>>
>>>> To turn this question around - Florian and Fantasai - what would we lose if we called everything a REC?  What process features would be harder or impossible to describe if we don't distinguish a REC from an EREC?
>>> Working Groups and other internal parties of W3C would lose no ability. This is just removing a constraint. So from that point of view, it is absolutely doable.
>>>
>>> However, the goal of this distinction is not internal. It is to allow the outside world to distinguish between Recommendations as they have always been (fixed feature set, possibly gaining fixes to errata over time) and Recommendations that can gain new features, which is different what what W3C Recommendation has meant until now.
>>>
>>> It seems useful to distinguish RECs that can accept new features (not just fixes) for two reasons:
>>>      - We don't really want to cause a bunch of other standards bodies to have to reevaluate whether normatively referencing W3C Recommendations is acceptable for them, due to the fact that we have changed what they mean. (Note that the ability to fix bugs in RECs is in itself not a change. It's been painfully bureaucratic until now, but it has always been allowed.)
>>>      - Some external standards group actually do want to be able to point to specs whose feature-set doesn't change, and if we deprive them of that, they'll link to dated publications instead the undated ones which are getting fixes.
>> I agree that we don't want other standards bodies to re-evalute references to us.
>>
>> I also agree with Mike's separate post about producers and consumers.
>>
>> Here is what I would propose to get the best of both worlds.
>>
>> 1. Let's just call everything a REC to simplify everything.
>>
>> 2. Let's add a practice to add something in Status of the Document whether this particular REC went through the Section xxx provision to revise a recommendation without looping back through the entire process.
> I think I can live with that as long as we're making a conscious choice here.
I confirm being conscious about this choice.
>   I wanted to start with the more conservative approach in keeping the meaning of Recommendation (without qualifiers) in line with the original one, and only allow feature additions in things that can be identified separately, but if we collectively agree we don't need that distinction, I'll fold.
>
> Two questions:
> 1. is this something we agree on between the participants in the current discussion, or do we want to raise that question to the broader AC? Simplifying things before we as the AC if they like the whole thing helps, as it makes the hole thing easier to understand, but I also a little worried about dropping this now, and later have someone push back on the whole thing because they would have wanted that distinction, and weren't aware of the discussion where we concluded to drop it.

I think that when we take a document to AB approval in February and AC 
review in March, we want to have as few open switches as possible.  
Hence I agree with your first point - simplifying things help.

I do appreciate your other point that people may push back on the whole 
thing because they have different assumptions.  I believe that applies 
to many things (even those that might want EG :)).  I would support the 
following action early next year if the Process CG thinks they are 
ready.  They could write to the AC telling them (a) here is the draft 
Process 2020, (b) here are key design decisions - why we took them - and 
alternatives, and (c) if people would like to discuss further they 
should join the Process CG calls on 8, 22 January; 12 February.

> —Florian

Received on Sunday, 8 December 2019 00:00:45 UTC