When contributing to SerenityOS, 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 PR, start with something small to get familiar with the project and its development processes.
Unlike many other software projects, SerenityOS is not concerned with gaining the largest possible userbase. Its target audience is its own developers. As such, we have limited interest in feature requests from non-contributors.
That said, please do file any bugs you find, keeping the following in mind:
* One issue per bug. Putting multiple things in the same issue makes both discussion and completion unnecessarily complicated.
* 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.
* For bare metal issues, please include the complete debug log from the serial console and what you tried to do to solve the issue before opening the issue. Don't forget to add the hardware model of your machine and relevant details about it, to help us diagnose what is the problem.
* Write in idiomatic SerenityOS C++20, using the `AK` containers in all code.
* Conform to the project coding style found in [CodingStyle.md](https://github.com/SerenityOS/serenity/blob/master/Documentation/CodingStyle.md). Use `clang-format` (version 11 or later) to automatically format C++ files.
* The first line of the commit message is the subject line, and should have the format "Category: Brief description of what's being changed". The "category" can be a subdirectory, but also something like "POSIX compliance" or "ClassName". Whatever seems logical.
### I've submitted a PR and it passes CI. When can I expect to get first reviewer feedback?
While unadvertised PR's may get randomly merged by curious reviewers, you will have a much smoother time if you engage with the community on Discord.
### If my PR isn't getting attention, how long should I wait before pinging one of the project reviewers?
Ping them right away if it's something urgent! If it's less urgent, advertise your PR on Discord and ask if someone could review it.
### Who are the project reviewers?
The project reviewers at this time are @awesomekling, @linusg and @alimpfard.
### Is there a policy for branches/PRs that haven't been touched in X days? Should they be closed?
Yes, we have a "stalebot" that will mark untouched PR's as "stale" after 21 days, and close them after another 7 days if nothing happens.
### Are there specific people to reach out to for different subsystems (e.g. Kernel, Browser, GUI, etc)?
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.
### Is Discord the place to ask for review help, or is Github preferred?
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.