Revising W3C Process Community Group

Revising W3C Process Community Group
Skip to toolbar
Skip
My W3C Account
Revising W3C Process Community...
W3C Process Community Group
Examine the way W3C works. Propose improvements to the formal processes. These will be given to the Advisory Board, which currently manages that process.
w3c/process/
Group's public email, repo and wiki activity over time
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
Director-free Process Initial Draft Call for Early Review
Elika Etemad
Posted on:
December 12, 2022
The Process CG has finished preparing a first “complete” draft of the Director-free Process for 2023, and we are ready to ask for an
early informal review

By “complete” we mean that every prepared part of Director-free has been
incorporated, and the Director has been completely removed from the Process.
By “first draft” we mean that there are still a number of open Process 2023
issues, and we are not done with this cycle. We will send a “finished” draft
for your review later.

We wanted to send this unfinished version for early review so that the
community can review and discuss the Director-free aspects while we continue
work on Process 2023.

You can file issues against the Process in the
Process CG repository
and join the Community Group to be part of the discussion.

For those of you not yet aware, Director-Free is a project of the W3C Advisory Board in which we are replacing the roles of the Director (Tim Berners-Lee) at W3C to
accommodate Tim's retirement and to create a more community-driven governance
for W3C standardization activities. It includes things like defining the W3C
Council to resolve Formal Objections, which we have been experimenting with
for the past few years.

The Process CG is working under delegation from the Advisory Board to draft up this plan.
How we work
Wendy Seltzer
Posted on:
January 26, 2021
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.
Process 2020 Adopted
Wendy Seltzer
Posted on:
September 15, 2020
Adobe Blog: The W3C Updates Process for More Agile Standards Development
Coralie Mercier
Posted on:
January 18, 2014
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. ]]
W3C Process: Tracking Issues, Bugs and Actions
Arthur Barstow
Posted on:
June 10, 2013
Here is the database for tracking process-related Issues, Bugs and Actions:
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
A proposal for a new Recommendation Track
Chaals
Posted on:
June 5, 2013
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
Last Call and Candidate Recommendation are merged into a single step
Proposed Recommendation is automated (effectively it is still there, but not as a seperate stage, and it begins at the same time as LCCR)
There are some clearer obligations for W3C to address dissent,
before
publishing a Recommendation
There are some changes to the requirements for editing a Recommendation – it no longer suggests that errata can somehow just be incorporated by reference.
Some MUSTS are now SHOULDS (e.g. identifying editorial changes), and vice versa
Requirements for explaining testing are a little stricter
The new Last Call Candidate Recommendation stage was the main motivation to develop this draft. It tries to achieve several goals:
Make the transitions matter
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.
Focus on interoperability
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…)
Don’t depend on changing the Patent Policy
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.
Other considerations
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.
Results from TPAC 2011 session on “Revisiting how W3C creates standards”
Kai Scheppe
Posted on:
November 15, 2011
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
Results of the TPAC session
General
specs are too large
the process is too long and too complex
process documents do not match the development model we use
process itself is fairly old fashioned as evidenced by ad hoc spec development elsewhere
stakeholders need stability
there is tension and conflict between needed stability and a dynamic environment
Early phase
ideas that the group might have might not fit the charter, but amending the charter takes too long
finding intersted parties to work on a given problem
getting input from necessary but uninterested parties
in the charter the deliverables are fixed, but not the true goals
a large scope may inhibit participation due to IPR concerns
Mid-process
the draft in TR space is continuously out dated
within a spec it is not possible to distinguish between different types of changes
suitable stability points are not clearly identifyable. Need to be metrics based (see also CSS WG)
Late phase
many reviews happen only at LC and not before
LC often is far too late in the process
LC often is not truly the last call
LC is in general overloaded with communication efforts, actual comments, prop. edited CR
LC contains intense and lengthy communication with other groups
CR phase is like a 2nd review phase, breaking the intent of LC
a single, large document should not be the only thing we publish
IPR
patent protection kicks in only after REC status has been achieved
LC is an IPR milestone that takes long to pass
Proposed solutions
In order to address these issues the suggestion was made to form a community group that can find solutions for the individual points
create small, clean, orthogonal specs
Tools for this group
Learn about available Community Group tools and how to configure a group's site to include links to tools on w3.org or elsewhere.
Mailing List
@ public-w3process
@ internal-w3process
Wiki
Chat
IRC
Slack
Slack invite
GitHub repo
RSS
Meeting minutes: 5 most recent on w3process
Contact This Group
Get involved
Learn more about how to join a group.
Anyone may join this Community Group. All participants in this group
have
signed the
W3C Community Contributor License Agreement
Join or Leave this group
Chairs
Brent Zundel
Participants (
55
View
all participants
Archives
December 2022
January 2021
September 2020
January 2014
June 2013
November 2011
Categories
rec track
Uncategorized