W3C home > Mailing lists > Public > public-w3process@w3.org > February 2012

AW: "Living Standards"

From: Scheppe, Kai-Dietrich <k.scheppe@telekom.de>
Date: Fri, 3 Feb 2012 10:24:03 +0100
To: "public-w3process@w3.org" <public-w3process@w3.org>
Message-Id: <63930C77AA7F3A4C8C7D5D7F2BB2FFEA7CFC9F15A8@QEO40072.de.t-online.corp>
Hello all,

I just realized that this group has been very quiet, with the last post pretty much exactly a month ago.

If I may attempt a quick recap.

Chaals had proposed a discussion on the Living Standard.
Marcos proposed following a model roughly as WHATWG does.
Jeff proposed following W3C process as it exists now.
Discussion then went into more detail, for a couple of posts, and stopped.

I believe that truth lies somewhere between the current W3C Process and WHATWG, as is so often case in real life.


The main problem I perceive is that W3C standards could be better delineated as far as their stability goes.
I do like versioning or some other clear mechanism that says "This standard is now different".
I don't like that so much time is spent discussing details, while remaining at purely theoretical level.

Wouldn't it be better to have real implementation, real feedback, be the ultimate judge on whether solution A or B is the right one?

Taking hints from agile development methods one could envision the following:

1. Standard creation, following a 80/20 rule
  - addressing the major issues
  - dealing with major compatibility issues
2. Issuing the document as some pre-cursor
  - get implementations
  - get first feedback
  - declare stable what can be reasonable seen as such (sectioning)
    (notwithstanding coming further development, changes in technology, etc.)
3. Setup a transparent process to move the standard forward
  - collect all feedback from the community and create changes
  - have clearly defined goals for the next release
  - have a clear schedule when that release will be ready
  - issue changes to the spec according to that schedule
4. Revisit
  - Reiterate this until done


This way, at least as I can envision it, the advantages would be:
- much earlier inclusion of the public community
- earlier and reality based feedback from that community
- focus on the important issues first
- proven implementations
- avoid, as much as possible, philosophical arguments about approach
- clearly defined stability and instability



So, just some thoughts to prompt further discussions.

Putting on fire retardant suit
Kai

Received on Friday, 3 February 2012 09:26:17 UTC

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