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

[TR] Status Section Requirements

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 31 Oct 2013 00:22:04 -0700
Message-ID: <5272051C.7080700@inkedblade.net>
To: W3C Process Community Group <public-w3process@w3.org>
# 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.

First Issue

2, 3, 4, and 6 are fine requirements, but should not be required
by the Process to show up in the status section. These are things
that are best moved out of the status section (along with much of
the boilerplate) into their own positions in the document template.
This isn't the case at the moment, but let's not have the Process
become a blocker on improving the document template. :)

Second Issue

1 is generally not followed. Most status sections are complete
boilerplate. Even if they weren't, it's hard to come up with some
reason to write something unique and different every time the
document is published. The more frequently the document is published,
the more this is true.

Also, nobody really reads the status section because it's full of
boilerplate junk. So there's little incentive for the editor to
spend much time on it.

I recommend to remove the uniqueness requirement. It was, afaict,
intended to force the status section to say something relevant
and informative, but isn't a reasonable requirement given
   - we have tons of boilerplate
   - we would like to encourage frequent publication,
     and things like an up date to "fix typos" should not require
     a change of status text for the same of changing status text
   - enforcing uniqueness when the goal is being informative and
     relevant is rather sideways

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:51:16 UTC