RE: [TR] Status Section Requirements

-----Original Message-----
From: fantasai [mailto:fantasai.lists@inkedblade.net] 
[SNIP]
On 10/31/2013 03:31 AM, Tim Berners-Lee wrote:
> This is a section dear to my heart. [...] That is the spirit I suspect 
> of the process document document's requirement to have a paragraph 
> which is unique.
> Yes, you have to think, and that adds effort to publishing a document.

I think that spirit is not captured in the requirements here at all. :)
[SNIP]
> On the other hand it is really valuable to tell a reader exactly what 
> is different, however minor and trite -- if the status has not 
> changed, why publish

This is what the Changes section is for. It's at the bottom of the CSS specs for a reason: if you're looking for it, you'll find it easily from the TOC (maybe even easier once we have a better document template), but if you just landed here for actual information, you start with interesting things rather than a list of differences from the previous version (which is only interesting to someone who has done a detailed study of the previous version).

SZ: The main problem with too many of the "Changes" sections is that they list (as they should) all the changes that were made. Not all changes are equally important. The intent of the requirement in question was to highlight major changes on which the WG is looking for review. In moving to an agile, iterative process, we noted that various parts of a specification mature at different rates. And, when a new WD is released, there are specific sections on which the WG wants immediate feedback. Because, in an agile process, implementation is often proceeding in concert with specification, it becomes more important to get initial reviews as soon as a section matures, even if the whole document is not yet mature. So that potential reviewers have an opportunity to see what is new (at the 50,000 foot level), it is desirable to put that information in the Status section (and, ideally, have a link to the "Changes" section). Then we can tell potential reviewers to check that section to see if they need to review this version of the document.  This agile, iterative process is really asking for a more continuous review (not necessarily of the whole document) than does the Last Call approach. But, Last Call is often too late to fix important problems where implementations have been largely completed. Having better Status sections seems like a small requirement to getting a more flexible, agile process.

~fantasai

Received on Thursday, 31 October 2013 22:01:07 UTC