AW: Getting the ball rolling on a better W3C process

Hi Dom,

I could co-chair with Charles.

Jumping ahead to some later mails, I support Charles' view to tackle the issues by priority.

In the summary on the blog I show groupings of issues and my perception, at the discussion, was we have three main target areas for activities.

1) Early in the process 
2) Late in the process
3) General aspects

The rest can follow.

Adopting an agile model we could prioritize, following Charles' suggestion, and develop possible solutions for each point.

These solutions could then be given to the AB for consideration.

Keep in mind, this process will have to be iterative!
A process based on theory does not survive reality.
A process based on reality will be lived and modified.


> -----Urspr√ľngliche Nachricht-----
> Von: Dominique Hazael-Massieux []
> Gesendet: Dienstag, 15. November 2011 16:45
> An:; Charles McCathieNevile
> Betreff: Getting the ball rolling on a better W3C process
> Hi,
> Thanks to Kai for summarizing the session at TPAC on the blog:

> 2011-session-on-revisiting-how-w3c-creates-standards/
> (and thanks to Steve for starting the first thread on the list :)
> There was a lot of positive energy at the break out session on making
> the W3C process better adapted to the way groups actually develop
> standards, and I would personally want to ensure that we don't lose
> that
> energy by having this group dormant.
> Charles, you've nominated yourself as a chair, so I'm hoping you'll put
> some energy in organizing the discussions here; since you're also an
> Advisory Board Member, I think your participation will be extremely
> useful here.
> I wonder if anyone else would be interested to volunteer as a co-chair,
> to put more energy behind driving this work forward. (I am not, FWIW)
> I think our first goal should be to refine what topics we want to work
> on, what outcome we expect from the group; I think it's fairly clear
> that the Advisory Board would be the ultimate recipient of our input,
> but whether that input is a list of issues, and/or a list of solutions
> is not yet entirely clear to me (at least).
> We should also try to identify which issues need fixing (because they
> prevent groups to work adequately) vs would-be-nice-to-fix (to better
> reflect how groups currently work); another axis of analysis should be
> which can be fixed quickly (for some definition of quickly) and which
> are longer-terms changes.
> Dom

Received on Wednesday, 16 November 2011 09:38:14 UTC