This is the home page of a task force with the mission of making W3C the place for new Web standards. Questions? Contact Ian Jacobs <firstname.lastname@example.org>.
News on #openw3c on twitter
- 1 Background
- 2 Goals for a Proposal from this Task Force
- 3 Use Cases
- 4 Outreach
- 5 Questions to Keep in mind
- 6 Expected outcomes and deliverables of Task Force
- 7 Ideas and proposals
- 8 Work Plan
- 9 Communication
- 10 Participants
- 11 References
- 12 Notes
W3C Value Proposition
- Clearly state the value of the classic process as well (work with the AB on this).
Goals for a Proposal from this Task Force
- Make W3C an attractive venue for developing Web technology.
- The expectation is that not all work will be standardized, but the community doesn't know in advance what will be most interesting to standardize.
- The community will decide how far it wants to go.
- Make it extremely easy for individuals (not just organizations) to participate actively in the W3C community
- But since W3C RF patent policy benefits from organizational commitments, think about transition from individual to organizational commitments.
- Individual participation may increase international participation as well
- Create a smooth path from "new idea" to "standard", while not expecting or requiring all products to use all mechanisms.
- Look at the entire standardization process, from "germ of an idea," through "small group of very motivated people not interested in broad consensus" through "widely supported, well-reviewed, consensus-supported spec" to "de jure standard."
- It is not a goal to scrap the W3C Process. If there are process barriers, we should lower them. Examining the whole process should be useful up front to establish context.
- Promote outreach to communities not yet connected to W3C to learn from them and encourage them to bring new ideas to W3C.
- Revisit our liaisons work; identify ways to help ensure that outreach remains an ongoing activity.
- It is not a goal to discourage innovation outside W3C. Indeed, liaison efforts will have the effect of encouraging outside groups.
- Survey asking for input from the community. See also the unused first survey draft.
- Criteria for what makes a group or a spec a good candidate?
- Ian wrote to Incubator Group chairs to ask them to complete the survey.
Some specs that have been mentioned (with no evaluation yet of whether to engage):
- OStatus (Salmon Protocol, ActivityStreams, Pubsubhubub, ...). See comments from HH
- Atom (case study?) See notes from Tim Bray
- Interactive Whiteboard common file format
- Open Graph Protocol
- W3C-DTF (date time format)
- File I/O.
These are some groups that have been mentioned (with no evaluation yet of whether to engage):
- OpenARML. Phil Archer to provide contact information (IanJ to follow up)
- Web Directions. IanJ will reach out to John Allsopp
- Who from the linked open data community? Ian plans to start contacting Richard Cyganiak, Peter Mika, and David Woods.
- WhatWG. IanJ talking with Henri Sivonen, Anne von Kesteren
- IETF. IanJ talking with Ray Pelletier and Scott Bradner. Idea of alternate stream?
- A List Apart
- OWF. Eran on task force
- Webdesign-I (mailing list)
- Other W3C liaisons
Verticals / Ontologies
- There is an ITU-T Focus Group on cloud computing
- Payments (Micropayments and Macropayments - solving the paywall problem) - PaySwarm
- Augmented Reality? See W3C Workshop on this topic
- Virtual worlds? See Journal of Virtual Worlds Research, Volume 2, Number 3 Technology, Economy, and Standards
Questions to Keep in mind
- different membership models (e.g., individual at no cost, organization at low cost)
- sponsored participant (Member visibility)?
Impact on Membership
- impact on value of membership
- what other business model is necessary? useful?
- any new benefits (e.g., sponsored participants)
- Relationship to membership by (EU) projects; see FAQ entry on project members
Impact on Staff
- more liaison role?
- use project reviews to do community building?
- Team contact ideas
- rotating team contacts (or pay to keep one around)
- Is a team contact necessary in all WGs?
- staff investment early in XGs makes them more efficient.
- dedicated staff looking at "future work"?
- proactive community-building; scouting out idea
- maybe run quarterly workshops online for how to use the w3c infrastruture; or Office Hours (e.g., weekly or monthly / IRC channel)
- Pay W3C to get an editor?
- if we have more new work coming in that is not initiated by team, what impact does that have in w3m decision-making process about WG proposals? Are staff contacts required for all WGs?
- do more to explain what people's roles are in the organization? [public job descriptions]
- make it easier to find out how to contact someone's supervisor in case of issues?
- how to work under good faith from the start, and transition?
- what disclosure obligations and/or licensing commitments over XG reports?
- relationship between OWF non-assert and W3C RF license?
- (sometimes blurry) relationship between software and documents; relation to licensing
- RF commitments over XG reports? (This would have benefit of not forcing some work to the rec track that may not be core.)
- do people who are employed by companies really make "individual" commitments; or do their contracts imply organizational commitments and thus some employed individuals may not be able to participate in incubator work.
- Is it even necessary to deal with RF commitments? Does a non-assert by participants combined with "bad PR" suffice?
- anticipate many flowers blooming, with some urging to coordinate?
- any architectural filter for accepting work?
- any architectural constraints for advancing (e.g., Accessibility review)?
- International participation
- Collaboration approaches
- is there a W3C Rec track that does not involve a Working Group? Use cases include:
- maintenance of specs by W3C when there is no longer a WG ("sunsetting"). EU funding for maintenance (since Members may not be interested in ongoing support)? For instance, it seems there may be resistance to finalizing CSS 2.1 out of concern it will not be maintained once a Rec.
- are there lighter-weight forms of WG (e.g., ad hoc set of people) that would be useful? Who provides authoritative technical issues? What accountability is required? What would IPR commitments look like?
- coordinate with core task force on this issue
- Role of testing?
- Role of certification?
- mature, implemented, deployed specification (seeking, say, RF commitments) arrives, ready for short Candidate Rec
- does the IG-paired-with-WG model work well? does it reflect the natural tendancy to have a small number of committed participants and a larger interested community?
- where we have emphasized schedule, what has that experience taught us?
Branding and promotion
- How to get people who are ready to contribute real work to participate?
- Association of W3C brand with output of these groups
- How will we promote the new mechanisms? Attend conferences? Participate in online fora?
- What do similar organizations (like W3C) do to promote offerings (infrastructure, etc.)?
Expected outcomes and deliverables of Task Force
- “Process” for pre-standards work
- Improving liaisons
- W3C operations and culture improvements
- W3C infrastructure improvements
Measures of success
- How will we know if this has worked? N "incubator groups" launched? Statements from the community in support of W3C revised process?
- 10-year aspirations?
- To get there, where do we have to be in 3 years?
- Improved classic track
- Updated patent policy?
- To get there, what do we need to do over the next year?
- Lightweight incubator?
- Annotated process document?
- Program for outreach, start conversations
Ideas and proposals
There is now a draft proposal.
Below is list of ideas people have suggested; scratch pad for proposals.
Offerings (Process, Tracks)
- Infrastructure + IPR policy for prototyping formats, protocols, APIs, tests, etc. to improve the Web experience. Offer a menu of IPR policies. No requirement to move work to rec track. No requirement not to compete with other groups. Minimal staff allocation (just enough moderation to ensure the group is functioning). Offer W3C brand. Community would steer most useful results to rec track. Business value proposition is to W3C is make W3C more valuable overall (and thus to Members). For more, see MikeC's strawman proposal
- OpenW3C (Harry, Ian)
- Outposts (Robin Berjon, Dan Appelquist)
- Open-ended charters (the community lives on)
- Existing Incubator Activity process
- Notes from Arnaud on process streamlining. What are the best places to streamline? For instance, it is likely that shortening the charter review process below 4 weeks will meet with resistance from companies that do IPR reviews. But is moving from 4 to 2 even useful? What are the "big slowdown" points? If the answer is "in being accountable to the broader public" what are ways to adjust the slider in a way that maintains quality while reducing burden on the WG?
- Tell stories so that the process document (not built in a day) makes more sense to people. Tell stories about Recs, too. Tim Bray's annotated XML spec was cited as an example. Strong support for this idea in the task force. Examples:
- Why is there CR? Implementation experience helps ensure spec clarity; avoid "another CSS2" [CMN]
- What are charters scoped? So that organizations with IP portfolios know what they are making available RF.
- Some people think that labels don't matter or that people may not understand how tracks differ.
- Label "[Draft] W3C Community Specification" seems to have some traction for non Rec-track specs.
- What matters is RF patent policy and understanding "how mature."
- Importance of running code
- Ability to maintain a live spec with occasional snapshots; see suggestion from Robin Berjon as well as some IETF ideas for wrapper.
- May be useful to articulate audiences for W3C including those who want stability, and those who want dynamic expressions of the state of implementation.
- Promote case may be dealt with by setting up a WG to take a specific doc to LC. But note cost of charter, charter review, 150-day exclusion period.
- is rejoin required for charter revision or does first commitment + review + opportunity to leave + opportunity to exclude suffice? [IJ and Rigo to investigate]
- charter delta reviews? (pros and cons...)
- allow chartering without RF commitments but not permitting publication of FPWD?
- when extending a charter with new deliverables, can we rely on AC review without requiring rejoin?
- easy graphic on various options and costs/benefits of each (e.g., mailing list, xg, wg, existing wg, ...)
- time requirements include "hidden ones" such as (1) pre-charter discussions among Members related to their IP porfolios and (2) timing requirements of patent policy (e.g., 150-day exclusion period after fpwd).
- Clearly there are improvements possible through tools and guidance for functioning smoothly. But there are also ways to shift some burdens off of WGs onto reviewers (rather than, say, removing the obligations entirely). Need better guidance for groups and commenters to ensure people share expectations, to keep discourse civil, and to keep discussion moving forward.
- need to be sure that we are not creating possibility of denial of service attacks
- compare community group, wg, ig, xg in a table
- what is impact on interest groups if we create a community group structure?
- community groups needs to provide incentive structure for sorting out issues around specs.
Reaching more people (Liaisons, Proactive Outreach)
- Individual member category (e.g., $100/year) with a small number of benefits that includes newsletter about work, interesting issues, potential work.
- Simple landing page, possibly corresponding to use cases, that explains how to start something new.
- Video "how to make a standard"
- Create a database for tracking potential specs/groups. Set up a task force (e.g., with some from staff, members, offices, public) to help track?
- Promote workshops, IGs, online discussions, and other connectivity with communities (e.g., Web Designers) who may not want to participate in WG daily operations, but who may want to provide input during requirements gathering, for example. Do a better job promoting these participation opportunities. Other outreach also important, e.g., speaking at developer/designer conferences.
- Talk to (Members and other) companies more about value of bringing new work to w3c. Organizations may be dissuaded from having lots of competitors involved in a big group; incubators can offer a more congenial environment where a small number of orgs exercise control initially.
- Make /Guide public?
- More human face artifacts.
Some audiences and ideas for reaching them;
- design firms: subscription program for access to content tailored to design firms
- startups: good source of "what's hot." give place to start discussion. must have seamless UI and be easy to use.
Note: The expectation is that the PSIG will be involved in any proposals related to licenses. This task force is only discussing legal issues informally.
- 6-month licensing commitments; renewable. Maybe other ways to increase the degree of certainty, like:
- First, only commit not to sue
- Then RF commitment but for certain use
- Then RF commitment forever but only if moves to WG
- Project (not-individual) based, graduated fee. Cost for a couple of people should be relatively small. But the bigger the group and the more infrastructure they use, greater the cost.
- Members have other influence for their dues than participation in groups.
- Sponsorship model; find companies who are willing to pay extra to sponsor a project. Can have multiple sponsorship levels.
- Emphasis on easier entry to market
- Larry Rosen formulation: "Come to W3C for guidelines; adopt our low-impact processes; consult a staff eager to mentor; and ultimately earn the imprimatur, if you do it right, of the most open standards body in the world."
- Simpler process will make it more likely that more people will be aware of W3C process, and more comfortable with the organization.
- simpler explanations (e.g., common craft?)
- Resources to improve civility of discussion (e.g., microformats mailing list discussion guidance). Are there constructive ways to limit the right to comment while remaining fair, open, accountable, and including people who may have valid comments but aren't known to the community?
- Chair training
- Mentoring young people (and thus improving their participation in the standards process).
- How to write a spec, how to organize a spec, what traps can you fall into? How to write about fault tolerance, for example.
- Language barrier to international participation, but also people unfamiliar with standards processes (e.g., in some countries, there is more govt leadership; people need explanations when first joining). See other recommendations from global and accessible task force for increasing participation.
- Part I: What People Want (June)
- Interviews with (3-5) potential customers
- Use cases and requirements
- Identification of process, legal barriers (perceived and real)
- Part II: What We Should Do (July)
- For each proposal (say 1 to 3), develop proposed solutions see Questions to Keep in mind
- Part III: How We Should Do It (August)
- Detailed plans and answers to Questions to Keep in mind
- Any commitments from candidates?
- Membership has advised us to look at transition to de jure standards bodies (a topic not being addressed by this task force).
- On twitter, #openw3c
We are actively collecting use cases and experiences of different communities. We welcome the contributions of any persons who would have concrete proposals for moving forward. These proposals need to be documented and explained and focus on get the things done.
- Work in public (public-vision-newstd, wiki, irc.w3.org #newstd)
- 2-3 hours per week commitment
- See tracker for open action items
- Preferred meeting time is Mondays, 11:30am ET
- No ftf meetings planned
- OpenW3C (Harry, Ian)
- Outposts (Robin Berjon, Dan Appelquist)
- Open incubator ideas (Ian)
- MikeC's strawman proposal
- Diagram from idea to de jure
- Toward a Saner Standards Process, Simon Saint-Lauren
- Elements of a Successful Standard Community, Eran Hammer-Lahav
- A Standards Quality Case Study: W3C, Arnaud Le Hors
- RFC 2932: The IESG and RFC Editor Documents: Procedures
- Agile development (wikipedia)
- RFC 5620 - RFC Editor model
- Reducing the Standards Track to Two Maturity Levels (IETF)
- draft-ietf-newtrk-repurposing-isd-04.txt (discontinued) which suggested a dynamic wrapper to provide updated status information (kind of like a profile of what is used in reality)
- mozilla good practices for crowdsourcing a project
- HTML WG list guidelines
- Camera-Ready Copy and the Social Denial-of-Service Attack
Mails illustrating issues
- Not planning to talk about setting up repositories at W3C (e.g., hosting an ontology for a group).
- Implementation costs:
- Editor for any process document changes
An unused Member-only home is also available.