This page details some common issues working groups may experience when working on standards. The document lists "symptoms" of issues, a "result" of these symptoms (which are the core issues experienced), and ways to solve these by defining a list of qualities for a "Successful Working Group".
"WG" is used within this document to represent the term "Working Group".
If you are visiting this page you may be experiencing some issues with progressing or completing the standards defined in your group's charter or you're being extra prudent to make sure issues do not happen within your currently well-working working group. In any case, to use this document go to the Common Symptoms section and see what symptoms you or others have experienced in a working group. The Common Symptoms have related Common Results which can be serious issues which affect the performance of a working group. Some advice on how to solve or avoid these symptoms and issues is given in the Defining a Successful Working Group section.
Below is a list of common symptoms of issues experienced by working groups. It includes working group member imbalance, lack of experts, perfectionism and lack of drive. Those items which could be a W3C Process violation are marked. The results are explained in Common Results.
- Description: The technology being standardised has a huge impact on the web and industry. Or, the hype around the impact of the technology is extremely high inducing blog posts, speakers referencing the technology at large events, impacts corporate strategy or even news articles. This places a large burden on the standardisation effort. This can lead to further symptoms such as Perfectionism and Tight Deadline. Leads to Scope Creep / Super-Spec, Incomplete Spec, Never-Ending Discussion.
- Description: The standardisation process is unable to keep up with innovation in the area. In this scenario a WG will find that the standard is taking so long to finalise that the innovation in the area had moved forward. Leads to Scope Creep / Super-Spec, Incomplete Spec.
- Description: In general specification and implementation operate in parallel at W3C. Sometimes implementations push further forward than the specification which may cause a specification to be lead by one implementation, or incite symptoms Overly Assertive Implementers and Overly Assertive Experts. Leads to Never-Ending Discussion, Failed Spec. The W3C Process details information on implementaion experience needed to progress a specification.
- Description: Functionality is continually added to the scope of the specification, often as more and more WG members bring further requirements or requests. Leads to Scope Creep / Super-Spec, Incomplete Spec.
- Description: The deadline set by the charter or by the editors and chairs is too restrictive. The time allowed does not allow for the standardisation process to complete, it does not allow for all of the experts to comment, or possibly even allow for the editor to complete the draft. This leads to Incomplete Spec. Can be addressed with SMART, Diplomatic Leadership.
- Description: Two or more implementations exist, but the extent in which they differ mean one spec cannot meet both specifications. One or both implementations will need to adapt; this can lead to Never-Ending Discussion and Incomplete Spec.
- Description: An "Existing Implementation" exists, which may bring aspirational improvements to a spec in conflict with the implementor's resistance to change code/break sites already relying on the implementation. Leads to Scope Creep / Super-Spec, and Incomplete Spec.
- Description: Only one implementation of the draft exists. This can results in Incomplete Spec as other implementation issues have not yet arisen and could also lead to Failed Spec as when further implementations do arise the issues they experience may require the spec to be completely re-evaluated. The W3C Process gives details on implementaion experience needed to progress a specification.
- Description: No implementation of the draft exists. Not only does this result in Incomplete Spec but also results in Failed Spec as when implementations do arise they’re not tested in real world scenarios and end up being phased out or not completed. The W3C Process gives details on implementaion experience needed to progress a specification.
- Description: In working groups across standards organisations there are sometimes individuals who assert themselves over others. In this case either the Implementers or the Experts (or both, or individuals who are both implementers and experts) assert themselves firmly over others in the working group. This is not to say that their opinion is incorrect; but that the method of assertion may be too strong. Leads to Scope Creep / Super-Spec, Incomplete Spec, Never-Ending Discussion. This situation may also produce a Code of Ethics and Professional Conduct violation.
- Description: No-one from the working group is willing or qualified to write the specification. Alternatively, no-one from the working group has time allowance to complete the spec. This leads to Incomplete Spec.
- Description: The Working Group suffers with a lack of understanding in one or more particular areas related to the technology being standardised, building the specification, the standards process, developer expectation or implementer expectation. Can incite other symptoms such as Clashing Implementation or Overly Assertive Implementers. Leads to Failed Spec. The W3C Process informs on wide review, and it's need in progressing a specification.
- Description: In this situation the charter and scope of work may be well defined but there is no drive within the group to complete the work. This may be fuelled by Expert Lack and Leadership Needs Improvement. Leads to Incomplete Spec, Never-Ending Discussion.
- Description: The group persists on making a “perfect” specification. This can be fuelled by Huge Impact. Leads to Scope Creep / Super-Spec, Incomplete Spec, Never-Ending Discussion.
- Description: Everyone starts somewhere. Sometimes new chairs and team contacts may not have the experience or tools needed to push the group to consensus or encourage authors to progress documents. Finding ways to support these chairs is key. Leads to Scope Creep / Super-Spec, Incomplete Spec, Never-Ending Discussion, Failed Spec.
- Description: It is generally felt that if a group brings in test cases, they are more likely to converge more quickly. Testing also helps implementation, interoperability, and aids the editors to understand how the spec will work within real world scenarios. If no tests exist it can lead to a Failed Spec.
- Description: New ideas for standards come from industry, implementers, developers and others. Incubation takes these ideas and preps them for standards work, by allowing some experts in W3C process and implementations to comment and guide new ideas. A lack of or incorrect incubation may lead to Incomplete Spec, Never-Ending Discussion, Failed Spec. Early incubation through the Web Platform Incubator Community Group or a dedicated Community Group which includes the right Expert Mix can help here.
- Description: The Wroking Group continues to bring new ideas or expansions to a specification, continuously incubating these new ideas which results in stalling the completion of the specification whilst these improvements progress though the incuation process. Leads to Scope Creep / Super-Spec, Incomplete Spec and Never-Ending Discussion.
- Description: Other Standards Organisations have their own working practices which may work well for their standards development but may clash with the W3C process. This may lead to Never-Ending Discussion, Incomplete Spec and Failed Spec.
- Description: Some specs require an understanding of others or underlying technologies in order to be successfully implemented and used. For example, understanding WebIDL is important for certain spec development, in-depth understanding DOM may be crucial for others. Lack of understanding of these dependencies can lead to Failed Spec.
- Description: The group cannot come to a consensus on a topic. Can lead to Never-Ending Discussion and Incomplete Spec. The W3C Process gives information on consensus and steps which can be taken when consensus isn't reached.
- Description: Specifications which allow for extensibility are often more successful in the long term. An extremely restrictive or opaque specification may be implemented, but may not be used in the long term and will result in being a Failed Spec. Can be solved with Extensibility or Versioning.
- Description: The specification missed negative security or privacy implications. If the spec ever reaches standard status, implementers refuse to maintain it or developers refuse to use it as it puts their users at risk. Can lead to Failed Spec.
- Description: An organisation or attendee blocks the development of a specification through various means. This could be by continued discussion, incorrect assumptions, or raising impossible targets. Another kind of blocker could wish for the working group to produce specifications, but only with their particular view. They are not open to collaboration and compromise. Finding a way to leverage their passion without disrupting the group can be very challenging. This may lead to Scope Creep / Super-Spec, Never-Ending Discussion, Incomplete Spec and Failed Spec.
Below is a list of issues which result from the symptoms outlined above. It includes scope creep, incomplete specs and lack of extensibility. Solutions are suggested.
- Description: A WG charter describes the scope of the standards to be completed within the WG during the charter period. Even so, due to many factors (such as Huge Impact and Spec/Innovation Race Condition) the scope of the spec begins to creep to include aspects that some members of the working group or public have expressed as important for the current working draft version of the spec. The specification becomes complicated and decisions on the new ideas are rushed.
- Solution: Can be solved by Versioning, Extensibility, Drive to Ship, Diplomatic Leadership.
- Description: The specification remains incomplete. Either the draft was not written, implementations were not built, tests were not conducted or the standards process did not complete (or has not completed).
- Solution: Can be solved with Expert Mix, Diplomatic Leadership, Scope-Strict Charter, Implementation, Drive to Ship, SMART.
- Description: The working group has a tendency to constantly discuss issues without making decisions and moving forward. It is likely the group cannot reach consensus around a topic and so continues to discuss a topic without coming to a resolution. In other cases, the group may be turning into a “talking shop”; discussing key issues without taking action.
- Solution: Can be solved by Diplomatic Leadership, Scope-Strict Charter, Drive to Ship, SMART.
- Description: A specification can be classed as failed if it is [1] never implemented or has few implementations, [2] never or little used by developers, [3] becomes confusing for developers and implementers to work with and support, and [4] symptoms other issues to cause an implementer to cease support for the standard. This is not an exhaustive list. Effectively a Failed Spec is one which is not used, not understood and / or not safe.
- Solution: Can be solved by all Defining a Successful Working Group points.
A working group can be successful without the below, but ensuring these are in place will give a working group the best chance to succeed:
Below is a list of expertise which should be within the group or have links to external-to-the-group individuals who can provide guidance on particular areas. Sometimes this guidance can come from Horizontal Reviews, sometimes it's best to request this guidance from other Working or Interest Groups before progressing past a Working Group Draft.
A working group should have expertise in implementation and testing from throughout the deployment chain:
- Market / business and end-user needs in the area of the specification
- Developers who produce content
- Content production and management software,
- Developer-facing libraries like React, Dojo (there are many of these)
- Consumption software - e.g. browsers or processors
Working groups will be less likely to be unpleasantly surprised by horizontal review quality requirements if they either have relevant expertise, or get early review, in a number of areas:
Accessibility
This is an important consideration for any specification. Accessibility groups within W3C can provide guidance here.
Internationalisation
These will be an important consideration for any specification dealing with user-facing components - interfaces or information ultimately presented to users.
Architecture
This is an important consideration for any specification. Inventing a new architecture imposes a significant barrier to developers learning to use the technology, and choices between existing architectural patterns can have significant consequences including for the other aspects mentioned here
Privacy
This should be reviewed for any specification, especially those which give the device or browser some ability to see data or know something about the user. Individuals who work within the W3c Privacy Activity can help here.
Security
These aspects should be reviewed for almost any specification from protocols to user interfaces - there are many ways to go wrong for one or both of these requirements in almost all areas of development.
In some cases a working group will also need regulation and policy expertise. For example payment is subject to strict and widely varied regulatory frameworks, so understanding that variety is important to develop technology that can be successfully deployed.
It is helpful to have more than one perspective in any area where there is scope for different interpretation, rather than assuming a single embedded expert will always produce the right answer to a given question.
Effective leadership is key to a successful working group. Chairs should have technical understanding of their group's topic, they should have a drive to complete the work and the skills to encourage their group members to work on their scoped specifications. They should be organised and approachable. Chairs should also be fair and accepting of all groups members.
The group related W3C team contact should be approachable, knowledgeable about the working group subject (although possibly not as much as the chair) and have an indepth understanding of core common dependency specs and the W3C process. The team contact should have a host of tools to call on to aid the chairs in their working group responsibilities.
Charter scope should be defined during the working group planning phase and should be strict. Working on extensible, smaller specs within a timely manner is advised. See SMART.
Objective should be SMART (this model is well known for a reason!). This means objectives, including standards deadlines and scopes should be Specific (well defined within the scope), Measurable (in W3C, this is most likely a completed standard with ''x'' number of implementations), Attainable (able to be achieved), Relevant (indicated by whether the industry, developers and implementers want this specification to exist) and Timely (within a defined and achievable time period).
Specifications need implementation to complete the W3C process. Your working group must work with implementers to develop implementations. Implementations allow for interoperability testing and usage testing as well as being a proof point and the core element of a successful specification.
Working on specs is both difficult and time consuming. If there is no drive to complete work then the specifications will fail. Your group must have drive to complete its scoped work. This could come from:
- Developer Community: developers express the need for a new specification to allow for functionality which does not exist on the web platform, or they wish for a current ill-defined spec to be altered.
- User Community: users are consuming a technology which is currently not built onto the web platform (e.g. VR)
- Industry: drive from the affected industry to deliver new web functionality
- Web End Point Innovation: a web end point, usually a browser vendor, develops key innovation which would benefit the web.
Scope Creep can occur when specification editors and working groups wish for specifications to include all necessary elements in the first version of the spec. Using a Scope-Strict Charter and SMART the working group can define and utilise clear versioning to push a spec iteratively forward.
Extensible specifications can be successful in their own right as well as inciting other successful specs which are built on top of them. Having the right Expert Mix (especially implementers and editors of any original extensible specification) will aid the development of an extensible specification within your working group, but predicting the need for extensibility and designing the right extension points is generally very difficult. If you feel like your group does not gave the right Expert Mix to build an extensible specification, please ask your team contact to help connect you to the right individuals.
Breaking down specifications into smaller parts which, together, can be used to build solutions which adapt to the required needs. Specifications which may result in Scope Creep / Super-Spec can greatly benefit here; as breaking down the specification into smaller specifications makes it possible to finish parts of a solution in a shorter timeframe, get feedback, and iterate on the remainder. Some groups also incubate each of the sections / smaller specifications; this way the group or specification proponents have guidance from the outset.