Re: [EXTERNAL] Review of Process 2020

On Thu, Dec 05, 2019 at 02:02:19PM +0900, Florian Rivoal wrote:
> > 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.
> 

They could gain features by going through a new REC process and
were generally producing a new versioned REC. 

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

ISO would probably consider a given version of a REC, even if it's an
ever-REC. Dated links will still be there.

> Of course, we don't need this distinction in the Process in order not to add features to a REC: we can simply refrain from adding them. But this allows us to visibly and reliably promise to the world we will do so for certain documents.
> 
> I'm ok with dropping the distinction if we collectively acknowledge that this is what it would give us, and that we prefer simplification over this signaling ability. But I feel I've explained this a few times already, and keep getting asked "why do we need this", rather than being told "I understand, but I think it's not important".
> 

What if we just change in the other way: Versioned REC vs. (ever-?) REC 
We'd say that if the WG chooses to use a version number in the title,
it's supposed to be feature-frozen and subsequent RECs will have a 
higher version (that does not prevent from using the same REC->CR->REC path
for additions).

Received on Thursday, 5 December 2019 08:14:58 UTC