[Draft] Proposal for Community-Based Specification Maintenance

Background

• In many cases, W3C maintains specifications through Working Groups.
• However, at times the community may wish to revise a Recommendation even though W3C does not have a Working Group dedicated to the topic.
• Furthermore, in many cases, W3C has helped to build a community only to see it look elsewhere for a home after a Working Group has closed.

Goals

• Make specification maintenance a scalable community-driven process
• Devise a process that also allows W3C to dedicate resources to maintenance when W3C management chooses to do so (e.g., editors).
• It is not a goal to seek additional IPR commitments from organizations that help to maintain a Recommendation (that us, who work on editions after the first edition). We will obviously accept any new RF commitments that are offered.

Roles

• Editor: Incorporates proposed corrections into a revised draft.
• Errata maintainers: One or more people who record in a well-documented place known errors and proposed corrections.
• Review committee: Small group of people responsible for managing comments that are made during the Proposed Edited Recommendation phase.
• Director: The person who determines the outcome of transition requests. In practice, the Director delegates this role.

Process

Note: This process makes use of a proposal from the new standards task force that involves the creation of lightweight community groups.

Community Groups Manage Errata

The community (or W3C staff) creates a Community Group to manage maintenance of a Recommendation. W3C Working Groups will no longer do maintenance. This can be discussed; there may be some WGs that want to manage errata until they close.

The Community Group will allow public participation without fee. The Community Group may, of course, be populated by the participants of the Working Group that produced the Recommendation (indeed, that is a very good thing).

The Community Group is self-governing. It persists indefinitely.

The Community Group chooses Errata Managers who have write access to the site and who help to log errata. (People may wish to use tools offsite, but that should be discouraged, and the data should routinely be archived at w3.org.). W3M may choose to assign staff as Errata Managers, but their responsibilities are still to be confirmed through the processes chosen by the Community Group.

The Community Group establishes a process for approving corrections. It should be consensus-based. (I expect we will provide straw-polling tools to assist in this process.) Strong objections to proposed corrections must be noted along with the corrections chosen by the Community Group.

Steps in the Maintenance Process

Request to Advance to Proposed Recommendation

At some point, the Community Group decides that it wishes to fold errata normatively into a new edition of a specification.

• An Editor must produce a new pubrules-compliant draft.
• The Community Group sends a transition request to the Director who reviews it for completeness. The request must identify a review committee of at least three people who have been participating in the Community Group (with their permission, of course). Those people are chosen by the Community Group to take responsibility for responding to review comments. Note: Why three people? The idea is to ensure that there's consensus for the proposed corrections.
• The request must also be sent to a public list for PER requests (and chairs should be alerted as well, e.g., by subscribing the chairs list to the public list for PER transition requests).

Director Handling of the Request

• If the request is complete, the Director initiates the PER. The Editor works with the comm team and webmaster to announce the publication and start the review.
• The Director may also send the proposal back to the Community Group for more work. The Process Document defines an appeal process.

Request to Advance to Recommendation

The review committee, working with the Community Group, manages incoming comments and making edits. People may register formal objections to changes.

Once comments have been processed, the review committee sends a transition request to Recommendation, including documentation of changes since PER and any Formal Objections.

The Director either approves the request or publishes rationale for rejecting it. If approved, the Editor works with the Comm Team and Webmaster to publish and announce the revised Recommendation.

FAQ

In general Community Groups can compete. What happens if two pop up for errata about a particular spec?

That seems unlikely. We'll deal with it if it happens.

What is more likely is that someone will object to changes within a single Community Group.

What are the risks of a community driven errata management process?

@@To be completed with information about possible need for staff oversight.

Copyright © 2010 W3C ^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.