- From: David Singer <singer@mac.com>
- Date: Thu, 21 Mar 2019 17:16:59 +0000
- To: Jeff Jaffe <jeff@w3.org>
- Cc: fantasai <fantasai.lists@inkedblade.net>, Chris Wilson <cwilso@google.com>, Michael Champion <Michael.Champion@microsoft.com>, "public-w3process@w3.org" <public-w3process@w3.org>
> On Mar 20, 2019, at 22:23 , Jeff Jaffe <jeff@w3.org> wrote: > > > On 3/20/2019 6:17 PM, fantasai wrote: >> On 3/20/19 10:41 AM, Chris Wilson wrote: >>> On Wed, Mar 20, 2019 at 10:37 AM Michael Champion <Michael.Champion@microsoft.com <mailto:Michael.Champion@microsoft.com>> wrote: >>> >>> > "Current work" in that model is a bunch of unmerged pull-requests, >>> Unmerged pull requests don't have "truth" status. Active participants in spec development have >>> to look at the unmerged PRs, sure, but implementers/website developers/framework developers/etc >>> don’t need to, do they? >>> >>> +1 to this. Once there's sufficient belief that it represents consensus and is error-free (determinations a WG could decide their own rules for), they would get merged. I should have said "current truth" rather than "current work". >> >> For a spec to be REC-level, it needs >> a) consensus under wide review >> b) tests >> c) two implementations >> >> I don't imagine that an Evergreen Recommendation would be any different, >> therefore each change as it goes in must have all of the above. > > Indeed for ERs, we require: > > a) A marking that a feature has had sufficient time (180 days) for wide review > > b) ??? Do we need to add anything to indicate tests? > > c) A marking that a feature has implementation experience I’m not sure we require marking for all those; indeed, I think we should probably require that to get *in* to the Evergreen spec., you have the specs and implementations already. Marking age on every feature is impractical. In case of doubt, pull a 180-day-old version and see if the feature was there then. It’s cooked if (a) it was and (b) there are no pending objections, errata (which DO require marking). > >> However, >> there's often a time gap between having a) and having b) and c). The >> amount of time lag between agreement on a proposal and two demonstrably >> interoperable implementation can vary greatly, from a few weeks for a >> well-coordinated fix, to years. >> >> If the agreed changes are not known to implementers, then implementers >> working on that area of the codebase will not know about them, and may >> end up compounding the amount of work necessary in the future and/or >> implement the wrong thing. Additionally, anyone reviewing a spec needs >> to know about impending changes. It's one thing to have a PR with >> tentative changes while you discuss them for a couple weeks to get the >> wording right. It's another to have pending changes that represent >> consensus hanging around in a PR for months and years. >> >> ~fantasai David Singer singer@mac.com
Received on Thursday, 21 March 2019 17:17:25 UTC