First thank you for considering contributing to the operating system 馃 鉂わ笍.
This project and everyone participating in it is governed by the skiftOS Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to [email protected].
This section guides you through submitting a bug report for skiftOS. Following these guidelines helps maintainers and the community understand your report, reproduce the behavior, and find related reports.
Before creating bug reports, please check this list as you might find out that you don't need to create one. When you are creating a bug report, please include as many details as possible.
Note: If you find a Closed issue that seems like it is the same thing that you're experiencing, open a new issue and include a link to the original issue in the body of your new one.
- Perform a cursory search to see if the problem has already been reported. If it has and the issue is still open, add a comment to the existing issue instead of opening a new one.
Bugs are tracked as GitHub issues.
Explain the problem and include additional details to help maintainers reproduce the problem:
- Use a clear and descriptive title for the issue to identify the problem.
- Describe the exact steps which reproduce the problem in as many details as possible.
- Describe the behavior you observed after following the steps and point out what exactly is the problem with that behavior.
- Explain which behavior you expected to see instead and why.
- Include screenshots which clearly demonstrate the problem if needed.
- Include a stack trace/panic report
- If the problem wasn't triggered by a specific action, describe what you were doing before the problem happened and share more information using the guidelines below.
Provide more context by answering these questions:
- Can you reliably reproduce the issue? If not, provide details about how often the problem happens and under which conditions it normally happens.
Include details about your configuration and environment:
- Which version of skift are you using?
- Are you running skift in a virtual machine? If so, which VM software are you using ?
- Are you running skift on real hardware? If so, provide information about it.
Unsure where to begin contributing to skift? You can start by looking through these beginner and help-wanted issues:
Beginner issues - issues which should only require a few lines of code, and a test or two. Help wanted issues - issues which should be a bit more involved than beginner issues. Both issue lists are sorted by total number of comments. While not perfect, number of comments is a reasonable proxy for impact a given change will have.
In order to get your PR through the review process as fast as possible, here are some do's and don'ts to try to stick to:
- Conform to the project coding style. Please use
clang-formatwith the.clang-formatfile included with the project. - When committing, the first line of your commit message should be "category: Brief description of what's being changed.". The "category" can be a subdirectory, but also something like "POSIX compliance" or "module-name". Whatever seems logical.
- Don't touch anything outside the stated scope of the PR.
- Don't iterate excessively on your design across multiple commits.
- "Cleanup" PR are accepted but only if they improve the code objectively by reducing complexity or help the code follow more closely the KISS principles.
- Avoid using function and types from the libc and the std, prefer native skift libraries like libsystem and libutils.
This text is based on the Atom's CONTRIBUTING.md and Fukur艒's CONTRIBUTING.md