Skip to content

Latest commit

 

History

History
61 lines (39 loc) · 2.4 KB

merge-guide.md

File metadata and controls

61 lines (39 loc) · 2.4 KB
Raw

Procedure for adding new features to a REC-level WEBRTC specification

The WebRTC-PC spec is now a W3C Rec, and the Mediacapture-Main spec is aiming for that status.

This means that we should revise it no more often than every 6 months or so, and only incorporate new features that are appropriate for "recycle at REC".

This means that we have, at any given moment, 3 different versions of the document to consider:

  • SPECNAME (REC)
  • SPECNAME (Editors' draft)
  • SPECNAME-extensions

Note: webrtc-pc's extensions document is named webrtc-extensions, not webrtc-pc-extensions.

Adding new features

In order to have a new feature considered for inclusion, write it up as an extension spec or as a pull request against SPECNAME-extensions.

For features that are "large" in some sense (large spec, need their own explainer, may have different people interested), extension specs are preferred. For extensions that are "small" (add a few methods, extend an argument list or enum, the function description is explanation enough), pull requests against SPECNAME-extensions is preferred.

In order to explore whether such an extension is a viable idea, file an issue on the SPECNAME-extensions repo. (This needs to be done when issues are found with the proposed extensions already present, of course.)

Landing in SPECNAME-extensions

We will land extensions in SPECNAME-extensions on the following criteria:

  • There is rough consensus in the WG that this API makes sense to consider
  • There is commitment from at least one browser vendor that they intend to implement

Documenting implementations

The chief mechanism to verify implementations is the Web Platform Tests suite.

In order to be considered for integration, a new extension must have:

  • Reasonable test coverage
  • One passing implementation
  • Implementation commitment from another implementer

Merging to the editor's copy on the REC branch

Once a feature is cleared for integration, a pull request is made for moving the feature into the editors' copy of the specification and removing it from SPECNAME-extensions.

At the same time, its tests should be moved from where they live into the spec's WPT suite.

Changes that bypass the -extensions stage

Changes that are pure bug fixes, editorial changes, or patch significant security holes in the specification, can be merged directly to the editors' copy at any time. Such issues should be filed directly on the spec's repo.