- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 20 Mar 2019 16:21:14 -0700
- To: W3C Process Community Group <public-w3process@w3.org>
- Cc: "Michael Champion (MS OPEN TECH)" <Michael.Champion@microsoft.com>
Breaking the thread because it's a new topic... On 3/20/19 10:37 AM, Michael Champion wrote: > fantasai wrote: >> 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. The problem isn't getting consensus. It's coordinating a set of changes that all a) have consensus b) have been edited in c) have wide review d) have tests e) have two implementations f) have an implementation report and DoC documenting all of the above without losing track of changes which only have some subset of the above. And then dealing with (imho) an excess of formal process to get a new publication. The reality of changes to a spec like CSS2 is that their lifecycles are not synchronized. However a REC can only be published if all of its content satisfies abcdef. Thus, to publish an update we'd have to either remove all content that doesn't satisfy abcdef, or never have edited it in in the first place. The problem with not editing in the resolutions is that then they're just agreements sitting in our internal records and nobody looking at the spec knows what we're aiming at, and we can't get wide review either. The problem with editing them and then removing them for publication is that it's a silly amount of make-work, and also means that the ED is still the "source of truth" for implementers and most everyone else. Lastly, issuing an updated REC with substantive changes under the current Process requires cycling through CR, PR, then REC, which involves a substantial amount of process overhead that nobody is excited about and that doesn't seem particularly useful either. Thus, the CSS2 spec has remained unmaintained since its REC publication in 2011. ----------------------------------------------------------------------- The ingenious solution that Tantek and gsnedders came up with last year is to incorporate all the agreed changes as inlined "notes", which are editorial and therefore not substantive, so can be published in place through the short-circuited editorial REC update process. (This also has the added advantage of calling attention to the change.) Then periodically, we would evaluate which changes have passed conditions abcdef, fold them into the mainline text, compile a DoC / changes list / implementation report, and then pass them through the REC update process. The remaining Process issues then are: a) It's an untoward amount of work for the Staff Contacts to update a REC because it needs to cycle back into CR, then PR, then REC, along with all that entails in transitions and publications, etc. b) It's confusing to the public at large to go through this cycle, because it apparently demotes the spec from REC to CR. (Then of course there's also the problem of resources: CSS2 now has a 7-year editing backlog, we've not done it yet so there's still some mechanics to figure out as well as working through edits, and nobody is funding gsnedders or anyone else to actually pull this off... on the topic of which, if anyone wants to fund CSS2 maintenance, lmk so we can get something coordinated. :) > 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. Agreed. ~fantasai
Received on Wednesday, 20 March 2019 23:21:39 UTC