-
Notifications
You must be signed in to change notification settings - Fork 49
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Document the way the WHATWG operates
- Loading branch information
Showing
9 changed files
with
309 additions
and
9 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,277 @@ | ||
| <!doctype html> | ||
| <html lang="en"> | ||
| <head> | ||
| <title>Web Hypertext Application Technology Working Group Working Mode</title> | ||
| <link rel="stylesheet" href="/style/tabbed-pages"> | ||
| <link rel="icon" href="https://resources.whatwg.org/logo.svg"> | ||
| </head> | ||
| <body> | ||
| <h1> | ||
| <span class="the">The</span> | ||
| <strong class="what">Web Hypertext Application Technology</strong> | ||
| <span class="wg">Working Group</span> | ||
| </h1> | ||
| <ul class="navigation"> | ||
| <li><a href="/" rel="home">Home</a></li> | ||
| <li><a href="https://spec.whatwg.org/">Standards</a></li> | ||
| <li class="this"><strong>Working Mode</strong></li> | ||
| </ul> | ||
|
|
||
| <h2>Working Mode</h2> | ||
|
|
||
| <p>The WHATWG develops standards and assists in maintaining their corresponding tests, thereby | ||
| fostering independent implementations. The WHATWG adheres to a shared | ||
| <a href="https://wiki.whatwg.org/wiki/Code_of_Conduct">Code of Conduct</a>. | ||
|
|
||
| <p>While discussing and working on standards, it’s always useful to keep these questions in mind: | ||
|
|
||
| <ul> | ||
| <li>What do implementations do? | ||
|
|
||
| <li>What do the tests reveal? | ||
|
|
||
| <li>What should the processing model look like? | ||
| </ul> | ||
|
|
||
| <h3 id="standard">Standard<a class="self-link" href="#standard"></a></h3> | ||
|
|
||
| <p>Each standard (ideally) has: | ||
|
|
||
| <ul> | ||
| <li>An active community of contributors. | ||
|
|
||
| <li>An assigned editor and zero or more deputy editors. | ||
|
|
||
| <li>A changelog. (A tidy Git repository with linear history.) | ||
|
|
||
| <li>An issue tracker. | ||
|
|
||
| <li>Corresponding tests. | ||
| </ul> | ||
|
|
||
| <h4 id="editor">Editor<a class="self-link" href="#editor"></a></h4> | ||
|
|
||
| <p>The editor has the following responsibilities, all of which can be delegated to deputy editors: | ||
|
|
||
| <ul> | ||
| <li>Ensure any applied changes fulfill the relevant criteria for changes. | ||
|
|
||
| <li>Resolve conflicts between contributors. | ||
|
|
||
| <li>Reduce open issues. | ||
|
|
||
| <li>Help manage the corresponding tests. | ||
|
|
||
| <li>Ensure implementations follow the standard and vice versa. (The “don’t write fiction” rule.) | ||
| </ul> | ||
|
|
||
| <h3 id="issues">Issues<a class="self-link" href="#issues"></a></h3> | ||
|
|
||
| <h4 id="normative-issues">Normative issues<a class="self-link" href="#normative-issues"></a></h4> | ||
|
|
||
| <p>Problems with the standard are generally recorded as issues. Resolving an issue typically | ||
| involves answering these questions: | ||
|
|
||
| <ul> | ||
| <li>What do implementations do? | ||
|
|
||
| <li>What is the ideal behavior? | ||
|
|
||
| <li>What is the lowest cost towards convergence? (Counting lowest number of implementations that | ||
| would have to change as the cheapest solution.) | ||
|
|
||
| <li>What do implementations want to do? | ||
| </ul> | ||
|
|
||
| <p>It’s not always possible to get the answers to all these questions in a timely manner. | ||
| Therefore, it might be the case that a decision is made even without input from all parties. This | ||
| makes it very important to file bugs for any spec changes (as discussed below), as a final check | ||
| to make sure all implementers are on board with, or at least aware of, the change. | ||
|
|
||
| <p>Additions to the standard can also be proposed as issues. However, the process for turning such | ||
| an issue into an accepted change to the standard is generally more involved, as the criteria for | ||
| additions is stricter (see <a href="#additions">Additions</a>). A typical path for turning such | ||
| issues into accepted changes is detailed in the <a href="#new-proposals">New Proposals</a> | ||
| section. | ||
|
|
||
| <h4 id="non-normative-issues">Non-normative | ||
| issues<a class="self-link" href="#non-normative-issues"></a></h4> | ||
|
|
||
| <p>Changes of editorial nature can be made, accepted, or rejected by the editor without | ||
| discussion. | ||
|
|
||
| <h3 id="changes">Changes</h3> | ||
|
|
||
| <p>Each normative change made to the standard needs to meet the following criteria: | ||
|
|
||
| <ul> | ||
| <li>It must have support from implementers. | ||
|
|
||
| <li>It should have corresponding test changes, either in the form of new tests or modifications | ||
| to existing tests. | ||
|
|
||
| <li>Implementations bugs must be filed for each user agent that fails tests. (This is each user | ||
| agent that doesn’t match the proposed changes. If the test changes are not adequate to reveal | ||
| that, but it’s known through other means, the tests should be improved first.) | ||
|
|
||
| <li>It should have been reviewed by one or more members of the community. | ||
|
|
||
| <li>Optional or implementation-defined behavior must be very well motivated. | ||
| </ul> | ||
|
|
||
| <p>Additionally, the following more mechanical criteria are used to hone a change before accepting | ||
| it: | ||
|
|
||
| <ul> | ||
| <li>It should match the standard’s source formatting and style conventions. (Consistent | ||
| formatting helps new contributors know what to do.) | ||
|
|
||
| <li>It must have a good commit message, with at the minimum a title, but typically with a body | ||
| that includes pointers to relevant discussion, tests changes, and a more elaborate description of | ||
| the change. (A detailed commit message helps folks in the future figure out why a decision was | ||
| made. This happens a lot more than you might imagine.) | ||
| </ul> | ||
|
|
||
| <p class="note">If the change is proposed by a new contributor, the editor can ensure the commit | ||
| message is good, and help with formatting and style. There’s no need to make new contributors jump | ||
| through too many hoops. | ||
|
|
||
| <h4 id="additions">Additions<a class="self-link" href="#additions"></a></h4> | ||
|
|
||
| <p>Any change that represents an addition needs to meet these additional criteria: | ||
|
|
||
| <ul> | ||
| <li>The addition must have the support of at least two implementers. (Such support is not binding | ||
| in any way on the implementers, however.) | ||
| </ul> | ||
|
|
||
| <p>Additionally, the following are strongly recommended: | ||
|
|
||
| <ul> | ||
| <li>The support from implementers should be of the form “we would like to implement this soon” | ||
| and not just “this seems like a reasonable idea”. | ||
|
|
||
| <li>There should be no strong implementer objections to the new feature. | ||
|
|
||
| <li>There should already be a prototype implementation or one being worked on side-by-side with | ||
| the change to the standard. | ||
|
|
||
| <li>New features should be something that cannot be done today or are such a common trend in | ||
| libraries that standardizing them helps lots of people. Alternatively, the “new” feature could | ||
| actually be a legacy feature that was not yet standardized, which is now being standardized. | ||
| (Legacy features are often hard to remove due to web compatibility; standardizing and testing | ||
| them helps improve interoperability and enables competition and refactoring.) | ||
| </ul> | ||
|
|
||
| <h4 id="removals">Removals<a class="self-link" href="#removals"></a></h4> | ||
|
|
||
| <p>Any change that represents a removal needs to meet these additional criteria: | ||
|
|
||
| <ul> | ||
| <li><p>The feature being removed must either be not widely implemented, or must in the process of | ||
| being removed from implementations. | ||
|
|
||
| <li> | ||
| <p>A test ensuring the feature is not supported must be added and existing tests for the feature | ||
| should be adjusted or removed as appropriate. | ||
|
|
||
| <p class="example"><a href="https://github.com/w3c/web-platform-tests/pull/5001">w3c/web-platform-tests#5001</a> | ||
| added new tests that appcache was not supported in shared workers, per the removal in | ||
| <a href="https://github.com/whatwg/html/pull/2384">whatwg/html#2384</a>. | ||
|
|
||
| <p class="example">Adjusting existing tests can be difficult. If necessary, an issue can be | ||
| filed instead to track updating those tests. This was done in | ||
| <a href="https://github.com/w3c/web-platform-tests/issues/5053">w3c/web-platform-tests#5053</a> | ||
| which accompanied the removal in | ||
| <a href="https://github.com/whatwg/html/pull/2402">whatwg/html#2402</a>. | ||
| </ul> | ||
|
|
||
| <h3 id="new-proposals">New Proposals<a class="self-link" href="#new-proposals"></a></h3> | ||
|
|
||
| <p>As described above, the criteria for inclusion in a WHATWG standard is rather strict. In the | ||
| initial stages of feature development for the web platform, such widespread implementer support is | ||
| often not available, or the shape of a feature is not yet clear enough for implementers to feel | ||
| comfortable pledging their support. | ||
|
|
||
| <p>In such scenarios we anticipate features will be “incubated” outside of WHATWG standards. This | ||
| could be in a variety of venues, such as: | ||
|
|
||
| <ul> | ||
| <li><p>Another standards organization | ||
|
|
||
| <li><p>A personal document or GitHub repository | ||
|
|
||
| <li><p>A pull request to a WHATWG standard, with the understanding it will not be merged until | ||
| the criteria above are met | ||
|
|
||
| <li> | ||
| <p>A document hosted by the WHATWG, but not under the spec.whatwg.org subdomain and not titled | ||
| “Living Standard” | ||
|
|
||
| <p class="example">The | ||
| <a href="https://wiki.whatwg.org/wiki/CanvasColorSpace">CanvasColorSpace</a> proposal is being | ||
| incubated on the <a href="https://wiki.whatwg.org/">WHATWG Wiki</a>. | ||
| </ul> | ||
|
|
||
| <p>In all cases, features that hope to graduate to a WHATWG standard should strive to follow the | ||
| above guidelines, gather appropriate implementer commitments, and have corresponding tests. | ||
|
|
||
| <p>Additionally, those maintaining such proposals should try to involve the WHATWG community, for | ||
| example by filing an issue on the standard they anticipate eventually becoming a part of. | ||
|
|
||
| <p class="note">Overall, this process of incubation can be very lightweight, such as filing a pull | ||
| request on the appropriate WHATWG standard with a proposal, and gathering appropriate implementer | ||
| support there. Or it could be more involved, such as creating a separate repository at another | ||
| venue and iterating for a long time there. | ||
|
|
||
| <p class="example">The addition of <code>URL.prototype.toJSON()</code> was rather straightforward | ||
| once a plan was agreed upon and upstream IDL issues were resolved: | ||
| <a href="https://github.com/whatwg/url/issues/137">whatwg/url#137</a>. | ||
|
|
||
| <p class="example"><code>innerText</code> was initially drafted in a | ||
| <a href="https://github.com/rocallahan/innerText-spec">repository outside</a> the HTML Standard. | ||
| Integration into HTML then went rather smoothly: | ||
| <a href="https://github.com/whatwg/html/pull/1678">whatwg/html#1678</a>. | ||
|
|
||
| <h3 id="tests">Tests<a class="self-link" href="#tests"></a></h3> | ||
|
|
||
| <p>As discussed in <a href="#changes">Changes</a>, normative changes to a WHATWG standard requires | ||
| tests, usually submitted to | ||
| <a href="https://github.com/w3c/web-platform-tests">web-platform-tests</a>. At a high level, these | ||
| tests should strive to: | ||
|
|
||
| <ul> | ||
| <li>Be automated | ||
|
|
||
| <li>Test error handling | ||
|
|
||
| <li>Test limits and edge cases, such as overflow outside the expected value set | ||
| </ul> | ||
|
|
||
| <h3 id="conflicts">Conflicts<a class="self-link" href="#conflicts"></a></h3> | ||
|
|
||
| <p>In case of a conflict among the community of contributors, the editor decides. However, the | ||
| editor is expected to go to significant length to resolve disagreements. | ||
|
|
||
| <p>Implementations can always override the editor by implementing something else. Whenever that | ||
| happens a breakdown in communication has taken place that the community should seek to overcome | ||
| and find ways to prevent it from happening again. | ||
|
|
||
| <p>Implementations that disagree can be rather tricky to sort out. Generally, we try to approach | ||
| these situations as follows: | ||
|
|
||
| <ul> | ||
| <li>Find a solution that is mutually acceptable. | ||
|
|
||
| <li>Research expectations of existing web content and specify the most web-compatible approach. | ||
|
|
||
| <li>Align with the majority. | ||
| </ul> | ||
|
|
||
| <p class="note">A standard is a tool towards convergence, and changing a standard can often be a | ||
| pragmatic solution in case of conflict. | ||
|
|
||
| <p>Implementation disagreement should not result in implementation-defined behavior or optional | ||
| features. | ||
| </body> | ||
| </html> |