Re: Review of Process 2020

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

To be explicit, “I understand, but I think  it's not important".

> 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

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

These rationales refer to the *consumers* of W3C standards.  The issue we’re trying to address by offering some flavor of “living” standards came from many *producers* of W3C standards: The current Process is too complex and time-consuming for their needs, and they prefer something more like WHATWG’s. See for example https://github.com/w3c/w3process/issues/346#issuecomment-554701435


So the challenge to those updating the Process is to find the right balance between the needs of producers and consumers of W3C’s product. Producers (generally) want a streamlined process that documents today’s reality or the expected reality in the near future.  It gets “wide review” from actual usage, and responds quickly to real-world feedback to improve the spec quality.  Consumers (generally) want more stable, authoritative, and well-vetted standards that don’t need to be updated faster than their own processes can handle. If W3C is to survive and prosper for another 25 years, it must engage people with both perspectives and help them communicate to produce standards that meet the real needs, if not deepest desires, of both.

So when considering a Process update, ask yourselves: Does the complexity/friction the new Process imposes on Producers tangibly benefit actual Consumers?  In this case, think about some new distinctions between (what the TPAC presentations called) Extensible Recommendations vs regular Recommendations.  I don’t believe the distinction offers enough benefit to Consumers to justify the complexity for Producers.  Not to mention the additional time and effort for people developing the process and patent policy.

BTW, I have similar feelings about the distinction between CR Update Drafts and CR Review Drafts, or whatever they’re currently called.  In WHATWG “Review Drafts” have no status as standards, they are simply stable snapshots for attorneys to review for patent commitment purposes. In other words, they serve an IPR Policy purpose, not a Working Mode purpose.  I suggest W3C adopt this model, especially by not calling IPR snapshots “Candidate Recommendations.”    I can imagine that there are other audiences who might want to refer to a CR that can be expected not to change, but again you have to ask yourselves whether the additional process complexity adds enough benefits to Consumers to justify the confusion/overhead/busy work for Producers.

Sorry to repeat the sermon those who I served with on the AB have heard before, but I’m retiring in a few weeks and won’t have a pulpit to preach from much longer 😊

From: Florian Rivoal <florian@rivoal.net>
Date: Wednesday, December 4, 2019 at 9:02 PM
To: Jeff Jaffe <jeff@w3.org>
Cc: Carine Bournez <carine@w3.org>, Michael Champion <Michael.Champion@microsoft.com>, public-w3process@w3.org <public-w3process@w3.org>, Wendy Seltzer <wseltzer@w3.org>, Philippe Le Hégaret <plh@w3.org>
Subject: Re: [EXTERNAL] Review of Process 2020

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

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

—Florian