When contributing to Ladybird, make sure that the changes you wish to make are in line with the project direction. If you are not sure about this, open an issue first, so we can discuss it.
**For your first couple of PRs, start with something small to get familiar with the project and its development processes. Please do not start by adding a large component.**
Read [the Ladybird documentation](https://github.com/LadybirdBrowser/ladybird/blob/master/CONTRIBUTING.md), including the documents in the **Development** section of the `Documentation/README.md` file.
* No build issues (or other support requests). If the GitHub Actions CI build succeeds, the build problem is most likely on your side. Work it out locally, or ask in the `#build-problems` channel on Discord.
If changes you’re making have relevant [Web Platform Tests (WPT)](https://wpt.fyi/) tests— especially if the changes cause Ladybird to pass any WPT tests it hadn’t yet been passing— you should consider [importing those tests into your Ladybird clone](https://github.com/LadybirdBrowser/ladybird/blob/master/Documentation/Testing.md#importing-web-platform-tests), and then commit the imported tests along with your code changes.
* Conform to the project coding style found in [CodingStyle.md](https://github.com/LadybirdBrowser/ladybird/blob/master/Documentation/CodingStyle.md). Use `clang-format` (version 18) to automatically format C++ files. See [AdvancedBuildInstructions.md](https://github.com/LadybirdBrowser/ladybird/blob/master/Documentation/AdvancedBuildInstructions.md#clang-format-updates) for instructions on how to get an up-to-date version if your OS distribution does not ship clang-format-18.
* The first line of the commit message is the subject line, and must have the format "Category: Brief description of what's being changed". The category should be the name of a library, application, service, utility, etc.
* Don't use specific component names, e.g. C++ class names, as the category either - mention them in the summary instead. E.g. `LibGUI: Brief description of what's being changed in FooWidget` rather than `FooWidget: Brief description of what's being changed`
* Several categories may be combined with `+`, e.g. `LibJS+LibWeb+Browser: ...`
* If you have images that go along with your code, run `optipng -strip all` on them to optimize and strip away useless metadata - this can reduce file size from multiple kilobytes to a couple hundred bytes.
In theory, the best person to speak with is whoever wrote most code adjacent to what you're working on. In practice, asking in one of the development channels on Discord is usually easier/better, since that allows many people to join the discussion.
It's definitely better to ask on Discord. Due to the volume of GitHub notifications, many of us turn them off and rely on Discord for learning about review requests.
The repository contains a file called `.pre-commit-config.yaml` that defines several 'commit hooks' that can be run automatically just before and after creating a new commit. These hooks lint your commit message, and the changes it contains to ensure they will pass the automated CI for pull requests.
To enable these hooks firstly follow the installation instructions available at https://pre-commit.com/#install and then enable one or both of the following hooks:
- pre-commit hook - Runs Meta/lint-ci.sh and Meta/lint-ports.py to ensure changes to the code will pass linting:
```console
pre-commit install
```
- post-commit hook - Lints the commit message to ensure it will pass the commit linting:
Sometimes good PRs get abandoned by the author for one reason or another. If the PR is fundamentally good, but the author is not responding to requests, the PR may be manually integrated with minor changes to code and commit messages.
Our goal is to build a browser for everyone, irrespective of their specific opinions and worldviews.
To achieve this, we strive to set our differences aside and focus on the shared goal of building the browser.
This means:
- We welcome contributions from anyone who is committed to the project's goals and respects the collaborative environment.
- Our discussions and work will remain strictly related to browser development and web standards. We do not take positions on issues outside this scope.
- The project will not be used as a platform to advertise or promote causes unrelated to browser development or web standards.
- To maintain a focused and productive environment, discussions on societal politics and other divisive topics are discouraged in project spaces.
We encourage everyone to share their personal views and opinions outside project spaces. However, please keep project spaces focused on project goals.
## On bad-faith contributions and brigading
We reserve the right to reject issues and pull requests that appear to be motivated by bad faith.
