Proposals
The proposals for satisfying the above objectives are organized as follows:
Progression of Processes
The following succession of community-driven processes is expected to make it easier for people to bring new work to W3C:
- Community Proposal Forum. A single global public forum where anyone may begin to generate interest around new ideas.
- Inputs: New ideas and proposals
- Outputs: Broad discussion and proposals about various domains of the Web e.g. new technologies, social implications, etc.; increased participation; community building
- Community Groups. When ideas gain momentum, discussion moves to Community Groups for further development. These groups will be created quickly and (by default) allow participation by anyone for no fee.
- Inputs: Promising, experimental proposals
- Outputs: Pre-standardization specifications, requirements documents, use cases, draft charters etc. as well as other materials (test suites, demos, etc.) relevant to W3C's mission.
- Standardization. When the community determines that standardization will benefit the technology, work moves to the next phase, the "classic standardization track."
- Inputs: Charter, draft specifications
- Outputs: Recommendations and supporting materials with strong IPR commitments and community support
See the comparison table for characteristics of participation, etc.
Value Proposition for Each Process
Note: We expect to work more with the Advisory Board on articulating the value propositions. For all IPR-related issues, we plan to consult with the PSIG, asking them for legal advice given a set of requirements.
- Community Proposal Forum
-
- A single forum within an established and influential community where anyone may draw attention to new ideas (e.g., through public submissions).
- "E-Z transition" to community group.
- Community Groups
-
- Infrastructure tailored to specification development processes
- Mentoring and guidance from experienced full-time staff of technical experts.
- "E-Z transition" to standardization.
- Standardization
-
- Vendor-neutral, consensus-based process with public accountability and transparency in decision-making.
- Opportunity to work directly with the leading companies, organizations, and individuals in the Web world.
- Tremendous community knowledge about principles of Web architecture (including where there is not consensus)
- Access to broader community review (including accessibility, internationalization, architecture) which improves quality and integration with other technologies (and thus interoperability).
- Royalty-Free licensing commitments from organizations
- Access to other standardization processes (e.g., ISO)
- Liaisons with governments and other standards bodies
- Experience ensuring persistence and stability.
- Mentoring and guidance from experienced full-time staff of technical experts.
Details of Community Proposal Forum
The Community Proposal Forum is a lively online forum where anyone may (constructively) build support for new work.
Proposals made to the forum are called "W3C Community Submissions." There are no style requirements other than they must not resemble W3C standards track documents. W3C will provide style guidelines and may have additional requirements (e.g., status boilerplate).
Community Proposal Forum Mechanics
Strong moderation is one of the keys to success of this forum. The expectation is that there be a small number of moderators (probably combining staff with dedicated volunteers).
- In general, the Moderator does not interfere in discussion. However, the Moderator may recommend that discussion move to a Community Group. The Moderator may also limit discussion that should move to a Community Group but doesn't.
- The Moderator may answer questions and otherwise provide useful guidance.
Note: To continue the function of www-talk, messages in the Community Proposal Forum should be cc'd to www-talk.
Ideas for ensuring the success of the forum
- Ensure clear announcements (without too much noise) of new proposals, and also of "Call for Vote" to move to a Community Group.
- Allow easy tracking of prominent discussions.
- Reach out to the the broader community (e.g., beyond the Membership and usual suspects) about this forum through participation in other fora, workshops, etc.
- Ensure transparency in the moderation process. Start with ad-hoc group of volunteers and derive a more stable and transparent process with experience.
- Require identity (for accountability purposes; relates to transparency)
- Do not tolerate disruptive participation. W3C needs a clear participation policy, as well as more tools and training for managing disruptive participants.
Transition to Community Group
Discussions are not intended to carry on interminably in the Community Proposal Forum. At any time, those involved in the discussion may move
to create a Community Group with an identified scope. Some ideas:
- Vote. Where there is unanimity and a minimal level of support, create the group. Where there is dissent and a minimal level of support, consult the Community Supporters. Where there is not a minimal level of support, do nothing.
- Ask for endorsement. Where there is sufficient endorsement (e.g., 3-5 endorsements), create the group. Otherwise do nothing.
Either way, there is a specified response window (e.g., one week). If a motion to create a group fails, there must be a delay before the next attempt to create the group. (This will impose a cost, e.g., on Community Supporters to watch for this, or to create software that does a reasonable job monitoring.)
Existing groups that form outside the W3C that are hosted informally on
other listservs (such as Google Groups) or have their own process may also
propose to become W3C community groups and may do so with the help of the
Community Supporters.
Details of Community Groups
Community Groups develop ideas as well as community support. Ideas typically take the form of specifications — called "W3C Community Specifications" — but deliverables may also be test suites, tutorials, demos, etc.
Community Supporters
- There is a dedicated group of people ("Community Supporters") responsible for mentoring and assisting community groups (e.g., in how the standards process works, accessibility input early in the development of the specification)
- Community Supporters will initially be chosen by the W3C management. The initial set should be small and ideally would include staff, Member employees, and public. With experience, the community will establish a process for renewing Community Supporters (e.g., an election).
- The Community Supporters will be led, at least initially while the program is new, by a Community Development Lead, assigned by W3C management.
- Community Supporters do not (in that role) participate in Community Group (internal) discussions. Community Groups may consult with them, including to help resolve any conflicts. The Community Groups will at least facilitate the right venue for conflict resolution.
- Community Supporters monitor the (automatic) creation of new Community Groups, quickly evaluating whether the creation process was used appropriately and whether the topic is in scope. They may take action (including closing a group) if the topic is deemed entirely out of scope for W3C, offensive, or the result of process manipulation.
- Community Supporters monitor inactive groups, closing them (e.g,. when the number of participants drops below 3, or when there is no discussion for an extended period). Community Supporters must notify a group of the intent to close it and allow for response before closure.
- Because Community Supporters do have decision-making power (to close a group), we will need clear processes for:
- Resolving differences among Community Supporters when they make a decision where there is not unanimity. As a first approximation: Community Supporters will agree to a process (which might vary according to situation) for resolving differences (e.g., ask the Director, or take a vote). Community Supporter decisions should be public, with documentation of dissenting views.
- Appealing a Community Supporter decision (e.g., to close a Community Group). Simplest is to ask the Director. Another path is the AB (already licensed to hear appeals of rejected Member Submissions).
Community Group Mechanics
- Anyone may participate (subject to signing agreements).
- New and closed community groups are announced publicly (e.g., via dedicated mailing list, feed, etc.).
- Groups are not required to have a chair, but it is recommended
- The staff allocates w3.org namespace for use by the Community Group. The group sets its own persistence expectations.
- Allow community groups to choose their own branding (with a default style available). Indicate that the work is hosted by W3C.
Ideas for ensuring the success of a Community Group
- Educate new participants at a variety of times:
- When the group starts, provide a brief introduction to how W3C works. This would include understanding various roles (e.g., Editor, etc.) and responsibilities, and setting expectations about how coordination can lower future costs.
- Organize periodic workshops for how to run a group, use the infrastructure, etc.
- Publish guidelines for good behavior in a Community Group.
- Promote scalability:
- Automate tools for creating group infrastructure, account creation, etc.
- Improve documentation (e.g., work on Chair handbook and make it public) and make it easy for the community to document good practices.
- Train Community Supporters.
- Facilitate connectivity:
- For some work, conduct staff project reviews (internal staff discussions with presentations from other parties).
- Organize online discussions, with, for example, short presentations of new work.
- Seek face-to-face meeting opportunities, including local meet-ups, TPAC attendance, etc.
- Promote broad participation:
- Facilitate language-specific community groups (with English language reporting requirement)
- Emphasize online meetings (rotating time zones, etc.). Note: The global and accessible task force is working on this topic.
- Promote responsibility through reputation
- Use a reputation mechanism to grant committer status for authoritative versions of a specification in development in a Community Group.
- Avoid confusion with standardization process
- Ensure that W3C Community Specifications have a distinct look and feel, different from standards track documents. Do not link to them from the standards page.
- Ensure that community group home pages have clear statement that the group is not working on a standard.
A Community Group may declare "success" with the publication of a Community Specification. In some cases, there may be a desire to advance the document to the standards track.
Transition to Standardization
One goal is to facilitate the transition from Community Group to Standardization. To that end:
- Non-Member employees may continue their participation in a Working Group for a limited duration while their employer makes the transition to Membership. The individual's employer must have fulfilled the organizational patent requirements of the IPR policy.
Note: In general in a W3C Working Group, participation is limited to W3C staff, Member employees, and invited experts.
- Simplified charter creation. For instance, the charter could be shortened to just be scope, chairs and team contact, deliverables list, and initial milestones. The rest of the charter can be included by reference.
- Conducting work in public within W3C should shorten some process times. For instance, the Community Group might give advance notice of a draft (simplified) charter to the Membership. This would not be a formal review, but would alert Members to a potential call for review. The review period might then be reduced to two weeks instead of four.
Details of Standardization
In addition to providing an on-ramp to standardization, this proposal suggests that Community Groups replace (after a transition):
- Incubator Groups
- Interest Groups that are only mailing lists
For reasons of revenue, the proposal suggests keeping other types of Interest Groups available as a Member benefit.
Additional ideas for process changes follow.
Process Tweaks
- Reduce cost of handling external comments. Many people cite the requirement to formally address comments from outside the group as burdensome. There may be ways to shift the review burden more towards the reviewer, while maintaining accountability. Tools may also help (e.g., if the group resolves an issue and records that in a tool like bugzilla, the tool can inform the reviewer). We would discuss ideas further on the chairs list.
- When revising a charter with new normative deliverables, today we require participants to rejoin after the charter has been approved. It may be possible to set expectations that once you have joined a group, you commit to any future deliverables of the group including extended charters without rejoining. Note that participants may always exclude, or leave the group (within 90 days of FPWD) if they do not wish to make RF commitments.
More Substantial Process Changes that may be Easy to Implement
- Drop the Proposed Recommendation phase. In practice, this adds time but does not substantially alter specifications. Gather support from Members through other means. It would become possible to exit Last Call and request to advance to Recommendation provided all the relevant criteria have been satisfied.
Operational Improvements
- Provide better guidance for groups and commenters to ensure people share expectations, to keep discourse civil, and to keep discussion moving forward.
- Chair training. Ensure that Chairs understand the tools available to them to enable groups to make progress.
- Provide more guidance on writing specifications that will be successful (simple, examples, tests (or at least text simple enough so that it is easy to write tests once the text is stable).
Longer term Operational Improvements
- Create an annotated process document with rationale and stories.
- Create tutorials on specification writing and good practices (simple specs, examples, testing)
Not covered in this proposal
- Revising a W3C Recommendation without a Working Group. "Maintenance" is addressed by the Core Task Force.
- Promoting an informal (non-W3C) standard to Recommendation (or other status) through a formal process. Example: WSDL 1.1
- At times there are delays pre-chartering while organizations determine their IPR comfort zones. We wonder whether there would be a way to allow a group to start work but not allow them to publish until participants have made RF commitments. It may be that the best way to do this is in a Community Group.
- There are a number of elements of the process that involve minimum time frames (e.g., 4-week AC review of charter, 4-week AC review of Proposed Recommendation, 150-day patent policy exclusion window).
Review various time requirements to see whether substantive gains are possible. Gains of a few weeks may not be worth pursuing (unless all the time is up front).
- For revised charters, simplify the review by offering a delta view (in addition to an integrated, full charter, which should be the one ultimately published).
About the Process Proposal
The task force identified some goals for the processes:
- It must be easy to understand how each process works. Note: In practice, building standards takes time and effort; that is different from unnecessary process complexity.
- It must be easy to participate, administratively speaking, while having enough mechanisms in place to ensure accountability.
- We should lean in the direction of permissive access, removing write privileges when there is abuse.
- We should lean in the direction of self-governance. Thus groups may use different processes to choose leaders, make decisions, select licenses (from an identified menu). There will be some core requirements such as allowing anyone to participate.
- It must be easy to progress from one process to the next, once the requirements of a given process have been fulfilled.
- It may be possible for work to skip one of the first two processes (e.g., it may remain a Member benefit to request to start a Working Group directly).
Furthermore, the task sought to adapt existing processes (possibly rebranded) rather than add processes. It also had in mind to reduce the total number of W3C processes.
Why these proposals differ from previous proposals
Some of these ideas are not brand new:
- The www-talk mailing list (archive) "is a public mailing list, maintained by W3C, for technical discussion among those developing World Wide Web software." The list has existed since 1991, three years before the creation of W3C. To this day, that list has hundreds of subscribers including a number of staff.
- W3C Interest Groups and Incubator Groups offer some of the same functionality as the proposed Community Groups.
Some differences that we anticipate will improve the chances of success of the new proposals include:
- There will be more explicit allocation of resources towards monitoring the Community Proposal Forum than the more informal subscriptions to www-talk.
- There will be more conscious efforts to build community than just making available a mailing list.
- Incubator Groups have shown that there is a demand for this functionality, but to date it has been reserved as a Member benefit. The expectation that the demand will continue to rise as more people can join the W3C community.
- This proposal simplifies the different types of groups, reducing the number by one.
Process Comparison Table
The following table compares the three processes. The "values" provided for the new processes are sample values.
|
Community Proposal Forum |
Community Group |
Standardization |
| Scope of Discussion |
Unlimited |
Focused (but broad deliverable range) |
Focused (on specifications and guidelines) |
| Statement of Scope |
None (or defined by proposal) |
Short statement of topic scope |
Traditional Charter (with scope, milestones, deliverables, participation expectations, etc.) |
| Who may participate |
Anyone |
Anyone (though other policies may affect who has write access to various resources) |
Members, Invited Experts |
| Access privileges |
Public |
Public |
Public or Member |
| Participation fee |
None |
None |
Membership or invited expert |
| Chair |
N/A |
Required. Selected by group. |
Required. Appointed by Director. |
| Patent license requirement |
None |
See draft IPR policy.
See also the note on non-member participants at transition time |
W3C Patent Policy |
| Document license requirement |
Grant allows W3C to republish (what license?) |
See draft IPR policy |
W3C Document License (or its replacement) |
| Software license requirement |
Determined by software authors. |
Determined by software authors. |
W3C Software License |
| Discussion visibility |
Public |
Public |
Public or Member |
| Discussion moderation |
Initially: Small number of volunteers including staff; then develop process. |
None by default; Chair if present; contact Community Supporters in case of disruptive behavior. |
Chairs and staff |
| Expectations of architectural consistency |
None |
None (but may smooth transition) |
Yes (e.g., Web Architecture Document, TAG) |
| Expectations of consensus within group about proposals |
None |
None (but consensus facilitates transition) |
Yes |
| Expectations of coordination with people outside group |
None |
None (but doing so smooths transition) |
Yes (through reviews) |
| Expectations regarding competition with similar technology |
Competition ok |
Competition ok |
Groups should strive to find a single solution |
| Ongoing reporting requirement |
N/A |
Yes (to be defined; e.g., two summaries per year) |
Heartbeat rule of W3C Process |
| Publication requirement |
Specs must not look like TR document; will need to establish persistenc policy and probably minimal style requirements. |
Specs must not look like TR document; will need to establish persistenc policy and probably minimal style requirements. |
Traditional Publication rules |
| Staff participation (other than administrative, sysadmin) |
Yes, in various capacities (new ideas, moderation, outreach) |
Yes (Community Supporters) |
Staff Contacts |
| Creation process |
N/A |
Voting or endorsement (to be explored). Notes:
- Create manually at first; automate with experience
- Suggested constraint: automatic creation only when proposal initiated in Community Proposal Forum.
|
AC Review |
| Duration requirement |
N/A |
None. |
Chartered duration. |
| Termination process |
N/A |
Several ways: Self-closure, Community Supporters close due to inactivity, Director may close |
Several ways: Charter expires, Director closes |
Relation to existing processes
This proposal takes elements of both Incubator Groups (XGs) and Interest Groups, unifying, opening, and simplifying so that communities currently not participating in W3C can do so. Community Groups thus share elements of both Incubator Groups and Interest Groups.
- Community Groups are created with sufficient public support (instead of three Members for XGs or AC review of Interest Group charter)
- Community Groups, like Incubator Groups, do not have a Team contact while Interest Groups often do.
- Community Group participants are not vetted by W3C staff (that is, there is no invited expert approval process)
- Community Groups do not publish on W3C's "TR" page (Interest Groups may).
- Community Groups are not required to have a charter (Interest and Incubator Groups do)
- Community Groups are not required to have a chartered duration (Interest and Incubator Groups do).
- The licensing and disclosure obligations of the W3C patent policy apply to Recommendation Track documents. Commitments in the Community Proposal Forum and in Community Groups apply to Community Group Specifications and future Recommendation Track work.
- Incubator and Interest Group participants participate in TPAC; we have not yet defined what face-to-face options there will be for Community Groups.
- The Community Proposal Forum is an expansion of the www-talk public mailing list, which has been around since the early 1990s (but is not actively nurtured by staff).
Note: W3C Management did not approve this piece of the proposal in October 2010. It may still be possible to carry out this work if W3C secures additional funding, or parts that do not require funding (e.g., task force).
W3C engages in a variety of liaisons with a number of communities; these liaisons vary in activity and formality. Strengthening our outreach can help W3C develop its reputation among new stakeholders and raise awareness within W3C of innovations.
High-level Goals
- Bring more of a human element to W3C Communications (e.g., video tutorials)
- Promote participation (including the new opportunities in this proposal as well as those listed on w3.org)
- Improve communications about to get work done at W3C.
Outreach to Developers Outside W3C
- Set up a Community Outreach task force (with representatives from Membership, staff (including marcom), and outside influencers) to meet quarterly to identify new communities.
The Task force would inform the Team of potential communities of interest. The Task force could also inform the Membership and seek feedback (since, e.g., some in the Membership may be involved in those communities).
- The Community Outreach task force will be led, at least initially while the program is new, by a Community Development Lead, assigned by W3C management.
- Maintain a publicly-editable database of emerging technologies or groups to liaise with that the Community Outreach task force would review.
- Organize developer gatherings during W3C's annual TPAC meetings (e.g., developer gathering at TPAC 2009)
- Support W3C staff travel and participation in conferences, meetups, etc.
Improved Communications Short-term
- Organize online meetings of Community Groups to share information about new work (e.g., every 6 months).
- Make it easier to understand on the site who is responsible for what and how to contact them (or their supervisor). This can help improve accountability and transparency.
- Make the Chair guidebook public; condense into a smaller useful resource. Put in a wiki and let community maintain it.
- Create videos, tutorials, simple landing page to help people understand and learn how to use the process.
Developer Portal
Note: W3C Management did not approve this piece of the proposal in October 2010. It may still be possible to carry out this work without explicit W3C investment (e.g., in a community group) or if W3C secures additional funding.
W3C should foster community creation of resources useful to developers and designers. W3C offers experience, expertise, and an established community, and by creating services useful to designers and developers, can rebuild trust. In turn, this will increase the likelihood of awareness and connectivity that may translate into people considering W3C as a venue for new work. Members have also indicated that W3C will be of greater value to them when W3C is perceived as relevant to the developer community.
Goals
- Nurture a community of developers and designers around the development of Web best practices.
- Create a multilingual environment to promote international participation
- Raise visibility in the developer community about W3C standards
Value Proposition from W3C
- W3C is a trusted, vendor neutral resource
- W3C is the reference for Web standards-related questions
- W3C has experience with best practices (accessibility, internationalization, mobile, etc.).
- Through Community Groups, motivated participants may influence the direction of W3C standards.
Initial Focus of the Portal: Web Best Practices
- W3C invests (e.g., 6 months) in the development of new content regarding high level Web best practices related to site design, cross-browser interoperability, privacy, security, etc. These will complement existing good practices, already valued resources.
- Host discussion on HTML5 migration good practices
- During this time, W3C will also develop a social networking infrastructure to support:
- Collaborative editing of best practices materials and commenting on ideas
- A Q & A system where the community (perhaps with staff oversight) helps answer questions (which become part of the best practices).
- Some content may be merged with the cheatsheet or other useful tools identified by the community. Coordinate with validator campaign.
- The community may also discuss ideas for new tools (e.g., unicorn modules) and may wish to share code (via mercurial + LDAP). Note: Another task force may do work on testing; Community Groups may offer a venue for people talking about testing frameworks, or specific test suites.
- The creation of new content may lead to W3C organizing online training or webinars to further improve and disseminate best practices.
Future Portal Ideas
- Allow people to annotate specifications (the PHP language documentation illustrates this idea). Allow people to provide examples of use of features, link to tests dynamically, etc.
- Encourage test development and seek feedback from early adopters on specification quality.
- Provide clearer status information about what pieces of specifications are well-deployed and interoperable. This is a well-known challenge, but also a familiar request (e.g., formulated as "Can I use this CSS property reliably?"). People often turn to W3C for these answers but we do not maintain data. Instead, we might enable the community to annotate specifications with status information, and provide useful views of the collective status bits. See also benchmark ideas from the IETF (which they have not adopted).
Infrastructure
Note: W3C Management did not approve this piece of the proposal in October 2010. It may still be possible to carry out this work if W3C secures additional funding.
Below we document short-term infrastructure requirements and medium-term ideas (that will evolve with experience). The following is a quick view of top priorities for the first 3-4 months:
- Automatic account creation
- One-click group creation (reuse exsiting infrastructure, but automate creation)
- Join/leave tool that records and provides views of various commitments (adapt IPP)
- Thumbs/up down tool (use off the shelf tool)
These are further described below.
General requirements
- Because W3C will be engaging with a broader audience and to ensure scalability, all user interfaces will need to be easy to use.
- All user interfaces we provide must be accessible.
- Automation will also be necessary for scalability, although automation should be introduced after we have some experience.
- We recommend professional designers help with branding this new W3C offering. We can also be creative in asking for designs (e.g., a contest), but we are likely to need designers dedicated to this proposal to ensure it is carried out.
Short-term general requirements
Account Creation
- Automatic public account creation process (that will involve some agreement checkbox. Example: agree to participation agreement)
- Need to be able to associate related employees (not just Members).
Straw poll
- Thumbs-up/down or voting tool. Longer term: add weighting by reputation?
Short-term Community Proposal Forum requirements
- Submitted proposals will need persistence.
- It will also be important to be able to clearly distinguish submitted proposals from other work being carried out within W3C. That is: we do not want to confuse proposals with standards.
Short-term Community Group requirements
Group creation
- One-Click Community Group creation process (of base infrastrucutre)
- For group homes, we may want to create a new top-level domain. We probably can reuse the structure of pages we use on w3.org, but a different skin.
- Once we have the system working, allow the creation process to be triggered through various means (e.g., automatically after a motion to create a group, or triggered by staff).
Base group tools/infrastructure
- Spam-protected, archived mailing list with RSS feed. This is likely to be the official communications channel for the group, including where the staff sends messages.
- Wiki. All participants have write access (until problems arise).
- Blog and RSS feed. Everyone in the Community Group is an author.
- cvs (linked to publishing to Web site) and mercurial (latter mostly for test suites, source code) + LDAP group editor rights
- Style for documents that avoids confusion with Rec track documents.
- WBS
Groups may also use external mechanisms such as a twitter hash tag.
Join/participate process
- When an individual employed by a Member joins a Community Group, the Member's AC rep receives (archived) email notification.
- Members will also have a view of employees participating in Community Groups.
- There must be a way to gather and display the variety of licensing commitments that participants may end up being able to make.
Medium-term ideas
- Web identity mechanism
- For the Community Proposal Forum (and possibly for Community Groups): mechanisms to help organize and track proposals (e.g., "recent proposals," "popular proposals," "proposals related to topic X,", etc.)
- Aggregate activity streams. Streams are created both by W3C tools and external ones. Use to create personalized views of news and announcements. The task force is investigating tools for this (e.g., status.net). It has been noted that aggregation will be noisy without filtering capabilities (cf socialcast, for instance).
- Community ranking of threads or postings (to give them more prominence)
- Annotations system (e.g., to comment on proposals)
- W3C tool to push microblogs to multiple targets (e.g., twitter, identi.ca)
- Collaborative specification editing tools (we will need to update the Editor's home page)
On the Importance of Public Discussion of Infrastructure
It will also be valuable and necessary to open a public discussion on infrastructure. We can start this conversation in the Community Proposal Forum.
We conducted a public survey where the results suggested, for instance, that spam-controlled mailing lists are considered important, along with wikis.
We also asked a question about additional infrastructure, which suggested that issue tracking tools, version control systems, comment handling, and test suite harnesses are also considered important.