Source code
Revision control
Copy as Markdown
Other Tools
<!-- go/cmark -->
<!--* freshness: {owner: 'hta' reviewed: '2025-02-27'} *-->
# Organizational contributors to WebRTC
This document outlines procedures for the relationship with longer-term
organizational contributors to WebRTC.
Note that this is not covering the case of individual, one-off contributions;
those are adequately covered in other documents.
## Background: Individuals making multiple contributions
The contribution guidelines can be summarized as:
* First, contribute something to show understanding of the codebase
* Then, get bot start rights, so that one can test the contributions before
asking for review (this right applies only to bots that operate on the open
source repo)
* After a number of commits, and demonstrating adequate knowledge of the
project’s style and structure, one can ask for committer rights, which will
give the ability to submit code after adequate review (current policy:
review by two WebRTC project members).
## Organizations making multiple contributions
At the moment, primary management of the WebRTC code repository and CI infrastructure is being provided by Google. This means that certain actions require cooperation with the responsible team at Google - here we refer to the people working on this at Google as “the WebRTC project”.
Sometimes, organizations take on a commitment to contribute to WebRTC on a
longer term basis. In these cases, it is good for all parties to have some
guidelines on how the relationship between the WebRTC project and the
organization is managed.
We should have the following roles in place:
* A contact person at the contributing organization \
This person will be responsible for knowing where the organization is making
contributions, and why. All contributors from that organization need to be
known by that contact person; the WebRTC project may redirect queries from
other people in the org to that person if not already CCed.
* At least one person with committer rights (or working towards such rights).
\
This person will also be a primary reviewer for incoming CLs from the
organization, ensuring a review is done before the WebRTC project members
are asked for review. \
This can be the same as the contact person, or someone different.
The WebRTC project will offer to host a contact mailing list, if desirable, and name a point of contact for the relationship.
When making small contributions like bug fixes, normal review is sufficient.
When asking to add significant functionality (new CC, new codecs, other new
features), the process should include:
* Specifying why the feature is needed (requirements, conditions for saying
“it works”, value to the larger community). This should normally be done
asking for the feature.
* A design document showing how the feature will be implemented and how it
will interact with the rest of the WebRTC implementation
* A plan for who will do the work, and when it’s expected to happen
* A “match list” of the areas affected by the project and the WebRTC project
members available to review contributions in those areas. (This can be
created collaboratively).
* If the work involves field trials and rollouts on Google properties like
Meet and Chrome, there
must be a plan for managing these aspects.
Normally, an ongoing relationship will require some regular cadence of meetings;
a minimum of one hour per quarter should be aimed for, with other meetings as
needed.