Comments on the W3C Process Update "List of Concerns" document

The W3C Process Update "List of Concerns" document is at:
http://lists.w3.org/Archives/Public/www-archive/2012Mar/att-0007/AB_List_of_Concerns-20120306.htm

My comments to get things started:

Process Implementation: Educational materials for Working Group Chairs might help the Process be understood better and implemented more consistently.
1- This would be useful and should contain a quick reference checklist

Process Implementation: Aspects of the Process are inconsistently enforced
2- Some aspects of this (good standing, heartbeats) could benefit from some flexibility.
3- Only those things worth enforcing in all instances should be process rules. The rest might inform best practices.

Process Implementation: Do the roles & responsibilities of identified people need updating
4- This wouldn't hurt.
5- But the most important issue is that Groups and Editors should never contravene the consensus of the group (especially when votes have actually been taken)

Process clarity: Process clarity: Going to Last Call (LC) is misleading for Candidate Recommendation (CR) changes
6- Agree. Perhaps circling at CR should be possible.

Process clarity: How should implementation integrate into process
7- Agree that waiting till CR is too late. Instead, there should be talk about implementation throughout with clear disclaimers that prior to CR, things can change so early implementers need to understand that.

Complexity of Process Document
8- Agree with all. See my comment #3

Speed of document production
9- These delays can be frustrating but not sure how to get around them. One possibility that could also help implementers could be the ability to lock certain parts of the document that the group feels is done. And to ensure this, the pub rules checker might be able to detect if there have been changes to locked areas.

Contextual/Social Framework: Desire for stable reference
10- Stable references are very important. It is very useful for an email in the list to be able to point to a stable section of a stable document.
11- On the other hand, if the area of a recommendation continues to evolve quickly, why should a document ever be "done"?

Can we improve input from 'horizontal' groups (WAI, I18N, ...).
12- It is tricky to balance the need of WGs to move forward on specs with accessibility (I18N, security?) review, especially when it is well known that accessibility is easier when built in from the beginning. First public draft seems too late for the first review. Perhaps a review should occur on the requirements or similar document at the outset? And perhaps WGs could receive a checklist of type of things that, when added to spec, will trigger accessibility issues so they will be less surprised when things are flagged later and perhaps be more likely to proactively seek accessibility input?


Cheers,
Jan

(MR) JAN RICHARDS
PROJECT MANAGER
INCLUSIVE DESIGN RESEARCH CENTRE (IDRC)

T 416 977 6000 x3957
F 416 977 9844
E jrichards@ocadu.ca

Twitter @OCAD
Facebook www.facebook.com/OCADUniversity 

OCAD UNIVERSITY
205 Richmond Street West, 2nd Floor, Toronto, Canada  M5V 1V3
www.ocadu.ca
idrc.ocadu.ca

Received on Monday, 2 April 2012 14:31:39 UTC