How we work
Posted on:The Process CG does most of its work through GitHub issues and pull requests. Join the group to contribute and to receive notice of meetings, approximately twice monthly.
Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
Chairs, when logged in, may publish draft and final reports. Please see report requirements.
The Process CG does most of its work through GitHub issues and pull requests. Join the group to contribute and to receive notice of meetings, approximately twice monthly.
I just happened on this post on the Adobe Blog, The W3C Updates Process for More Agile Standards Development, posted a few hours ago by Steve Zilles, who gives an overview of the purpose of the W3C updates to its Process Document to make Standards Development more agile.
Here are a few selected bits, but I recommend reading the whole short piece:
[[ The World Wide Web Consortium (W3C) has undertaken updating its process to allow more agile standards development. Over the last five years, the W3C has opened up much of its standards work to public participation on a daily (if desired) basis. But, there are aspects of the current W3C Process that act as barriers to more agile standards development. One of these is the assumption that all parts of a potential standard will progress at the same rate; that is, all parts of a standard will be accepted and reach deployment at the same time. ]]
[[ So, the W3C is proposing that (where possible) standards be developed in smaller, more manageable units, “modules.” ]]
[[ With these changes, it becomes much easier to develop all the aspects of a standard – solid specification, wide review, implementation experience and interoperability demonstrations – in parallel. This will help shorten the time from conception to reliable deployment. ]]
Here is the database for tracking process-related Issues, Bugs and Actions:
<https://www.w3.org/community/w3process/track/>
This DB should be writeable by all of the members of W3C Process Community Group. If you do not have write access to this DB, please send your issue or bug to:
<mailto:public-w3process@w3.org>
W3C gave their permission to publish a derivative of chapter 7 – the chapter that defines the recommendation track.
I wrote a proposal as a heavily edited version. it fails to identify what is removed (sorry – I’ll try to find time for that) but it does show to try what has changed or been added. Since we apparently can’t publish plain files HTML in the Community Group (or I haven’t worked out how to do that), I’ve put it where you can download it (with a bonus Russian lessson: “Скачать” means “Download”).
The main changes are
The new Last Call Candidate Recommendation stage was the main motivation to develop this draft. It tries to achieve several goals:
Last Call is very important in terms of Patent Policy, and used to be a vital step in the Process, when CR didn’t exist. But it is a trivial step for a Working Group, and there is a sense that making multiple last calls is an easy way to get review. Review should happen as bits of the spec are solidified, in what I have called Heartbeat Working Drafts.
Meanwhile, Candidate Recommendation was a serious step process-wise, yet shouldn’t change as much as it does – people should be building test implementations earlier, so their last call comments can be backed by reality instead of imagination.
The requirement for exiting LCCR has changed. It seems somewhat wishy-washy as written “must show that independent implementations of the specification are extremely likely to be highly interoperable”. The idea is to avoid cases where two implementations is clearly not going to produce the desired result (e.g. WebSQL), or where there is good reason to believe the specs will be implemented increasingly better (e.g. because there is an active process of making a next one and the one after…)
Actually, I would like to change the Patent Policy. I just think don’t want to depend on that in order to make a useful improvement.
I also tried to frame it in terms of requirements on who does what. It is currently about half the size it was. But some things that were good advice have been removed and perhaps should be re-added.
The Advisory Board saw a slightly different draft already, and have made a couple of comments. They suggested this draft be published to gather wider input for their work of revising the Process.
Comments, criticisms, and suggestions are very welcome on the mailing list.
At TPAC 2011 a session was held on potential problems and solutions regarding the W3C process.
There was much participation and active discussion.
Due to the number of points brought out it was decided to keep the session to brainstorming, record the points made and delegate dealing with the points to another opportunity.
That opportunity is this community group.
Following is a partial repost, for the sake of having the information visually available, of the summary at
http://www.w3.org/wiki/TPAC2011/Revisiting_how_W3C_creates_standards