Re: Evergreen Formal Objection handling (ESFO)

> . Maintaining REC documents is so onerous that we have not maintained CSS2,
Very interesting! Could you elaborate?    

I've been seeing the ER process as having the advantage of making maintenance easier, but not necessarily as the appropriate way to maintain traditional Recommendations.  If it was hard to get consensus on a Recommendation, there's no reason to think that there ER process would work smoothly.  But if the traditional Rec Track is putting additional non-technical barriers in the maintenance process, those are bugs that should be fixed with or without adding an ER track. 

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

-----Original Message-----
From: fantasai <fantasai.lists@inkedblade.net>
Date: Wednesday, March 20, 2019 at 10:11 AM
To: "public-w3process@w3.org" <public-w3process@w3.org>
Subject: Re: Evergreen Formal Objection handling (ESFO)
Resent-From: <public-w3process@w3.org>
Resent-Date: Wednesday, March 20, 2019 at 10:10 AM

    On 3/20/19 9:24 AM, Chris Wilson wrote:
    > It sounds like you are already getting everything you need from the REC process, which is great. 
    > There's no requirement to move away from that process if it works for your group.
    
    We're not. Maintaining REC documents is so onerous that we have not
    maintained CSS2, and it is notably out of date at the moment.
    
    > The problem is that there are situations where the process (transitioning to new maturity levels, 
    > but even just the group-resolution-to-publish requirement) *is* onerous.
    
    Groups are allowed to have an "evergreen" group-resolution-to-publish,
    and many do.
    
    > The whole point of ES is to have one source of truth, not "look here for the current REC, but over here if you want to track 
    > current work."
    
    "Current work" in that model is a bunch of unmerged pull-requests,
    so actually you still have to look in two places.
    
    ~fantasai

Received on Wednesday, 20 March 2019 17:37:33 UTC