Maintaining Recommendations

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