W3C home > Mailing lists > Public > public-w3process@w3.org > October 2013

Re: [TR] Status Section Requirements

From: Marcos Caceres <w3c@marcosc.com>
Date: Thu, 31 Oct 2013 12:15:35 +0000
To: Arthur Barstow <art.barstow@nokia.com>
Cc: W3C Process Community Group <public-w3process@w3.org>
Message-ID: <2A0753A892B54E5B9481B11404F23B06@marcosc.com>

On Thursday, October 31, 2013 at 11:30 AM, Arthur Barstow wrote:

> On 10/31/13 3:22 AM, ext fantasai wrote:
> > # Every document published as part of the technical report development
> > # process must clearly indicate its maturity level, and must include a
> > # section about the status of the document. The status section
> > #
> > # 1. must be unique each time a specification is published,
> > # 2. must state who developed the specification,
> > # 3. must state how to send comments or file bugs, and where these  
> > are recorded,
> > # 4. should explain how the technology relates to existing international
> > # standards and related work inside or outside W3C,
> > # 5. should include expectations about next steps, and
> > # 6. should explain or link to an explanation of significant changes
> > # from the previous version.
> Oh dear. I thought one of the problems this effort was supposed to fix  
> is the pervasive mixing/conflating of requirements for publication, Team  
> responsibilities, Chair responsibilities, descriptions of maturity  
> levels etc., but I guess that hasn't happened (at least not entirely) :-(.
> My vote on the issues you raise above would be to move this entire  
> section to a separate `TR publication process` type document with musts,  
> suggestions, best practices, etc. that can be easily updated if/when the  
> tide changes, as well as give the producers of the doc some flexibility.
> (BTW, I'm not sure about the intended audience(s) for this doc but  
> having such an authoritative list right after the ToC would probably  
> cause a lot of newbies to stop reading.)

Agree. All the boilerplate stuff, including the copyright, should be somewhere less prominent - like at the end of the document - so that the document can have a “real” status section that is actually useful to the reader. Also, a bunch of those things that are useful (e.g., link to bug tracker) usually appear at the top of the document instead of the SoTD, so it seems kinda pointless to repeat that stuff in the SoTD section.  
Marcos Caceres
Received on Thursday, 31 October 2013 12:16:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:35:09 UTC