Re: AW: "Living Standards"

On 2/3/2012 4:24 AM, Scheppe, Kai-Dietrich wrote:
> 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.

Actually, my position was far more nuanced than this.  Key points were:

  * Early development in CGs with a thought that when ready technology
    ends up in WGs.
  * Overlapping turns in technology when ready for WGs
  * These turns should be done rapidly, in an agile fashion, on schedule


> 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.

+1

>
>
> 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
>