Servo welcomes contribution from everyone. Here are the guidelines if you are thinking of helping us:
Contributions to Servo or its dependencies should be made in the form of GitHub pull requests. Each pull request will be reviewed by a core contributor (someone with permission to land patches) and either landed in the main tree or given feedback for changes that would be required. All contributions should follow this format, even those from core contributors.
Should you wish to work on an issue, please claim it first by commenting on the GitHub issue that you want to work on it. This is to prevent duplicated efforts from contributors on the same issue.
Head over to Servo Starters to find
good tasks to start with. If you come across words or jargon that do not make
sense, please check the glossary first. If there's no
matching entry, please make a pull request to add one with the content TODO
so we can correct that!
See HACKING_QUICKSTART.md for more information
on how to start working on Servo.
-
Branch from the main branch and, if needed, rebase to the current main branch before submitting your pull request. If it doesn't merge cleanly with main you may be asked to rebase your changes.
-
Commits should be as small as possible, while ensuring that each commit is correct independently (i.e., each commit should compile and pass tests).
-
Commits should be accompanied by a Developer Certificate of Origin (http://developercertificate.org) sign-off, which indicates that you (and your employer if applicable) agree to be bound by the terms of the project license. In git, this is the
-soption togit commit. -
If your patch is not getting reviewed or you need a specific person to review it, you can @-reply a reviewer asking for a review in the pull request or a comment, or you can ask for a review in the Servo chat.
-
Add tests relevant to the fixed bug or new feature. For a DOM change this will usually be a web platform test; for layout, a reftest. See our testing guide for more information.
For specific git instructions, see GitHub workflow 101.
When you push to a pull request, GitHub automatically checks that your changes have no compilation, lint, or tidy errors.
To run unit tests or Web Platform Tests against a pull request, add one or more of the labels below to your pull request. If you do not have permission to add labels to your pull request, add a comment on your bug requesting that they be added.
| Label | Effect |
|---|---|
T-full |
Unit tests: Linux, macOS, Windows Layout tests: Linux, macOS Legacy layout tests: Linux, macOS |
T-linux-wpt-2013 |
Unit tests: Linux Legacy layout tests: Linux |
T-linux-wpt-2020 |
Unit tests: Linux Layout tests: Linux |
T-macos |
Unit tests: macOS |
T-windows |
Unit tests: Windows |
Contributions must not include content generated by large language models or other probabilistic tools, including but not limited to Copilot or ChatGPT. This policy covers code, documentation, pull requests, issues, comments, and any other contributions to the Servo project.
For now, we’re taking a cautious approach to these tools due to their effects — both unknown and observed — on project health and maintenance burden. This field is evolving quickly, so we are open to revising this policy at a later date, given proposals for particular tools that mitigate these effects. Our rationale is as follows:
Maintainer burden: Reviewers depend on contributors to write and test their code before submitting it. We have found that these tools make it easy to generate large amounts of plausible-looking code that the contributor does not understand, is often untested, and does not function properly. This is a drain on the (already limited) time and energy of our reviewers.
Correctness and security: Even when code generated by AI tools does seem to function, there is no guarantee that it is correct, and no indication of what security implications it may have. A web browser engine is built to run in hostile execution environments, so all code must take into account potential security issues. Contributors play a large role in considering these issues when creating contributions, something that we cannot trust an AI tool to do.
Copyright issues: Publicly available models are trained on copyrighted content, both accidentally and intentionally, and their output often includes that content verbatim. Since the legality of this is uncertain, these contributions may violate the licenses of copyrighted works.
Ethical issues: AI tools require an unreasonable amount of energy and water to build and operate, their models are built with heavily exploited workers in unacceptable working conditions, and they are being used to undermine labor and justify layoffs. These are harms that we do not want to perpetuate, even if only indirectly.
Servo Code of Conduct is published at https://servo.org/coc/.
Servo contributors frequent the Servo Zulip chat.
Technical oversight of the Servo Project is provided by the Technical Steering Committee.