Thanks for your help improving the project! We are so happy to have you! 🎉
We adhere to Rust Code of Conduct. Please maintain a respectful and professional communication style. We are committed to providing a friendly and inclusive environment for all contributors.
If you encounter problems while contributing:
- Check existing issues and discussions
- Ask questions in Discussions
- Create an issue to seek help
If you find a bug or have a feature suggestion, please:
- Check if there's already a related issue
- If not, create a new issue
- Use the issue template to provide detailed information
We welcome any code contributions. It's always welcome and recommended to open an issue to discuss on major changes before opening a PR.
Here are the recommended workflow and guidelines for contributing code:
# Fork the repository to your GitHub account, then clone
git clone https://github.com/YOUR_USERNAME/StarryOS.git
cd StarryOS
git submodule update --init --recursive# Create your feature branch from the latest main branch
git checkout main
git pull upstream main # if you have upstream set up
git checkout -b feat/your-feature-name
# or
git checkout -b fix/your-bug-fix- Write code
- Add tests (if applicable)
- Update documentation (if needed)
Before committing, make sure:
cargo clippy --all-targets --all-features -- -D warningsImportant: All code must pass clippy checks, which is also verified in CI.
cargo fmtThe project uses a custom rustfmt.toml configuration.
- Add documentation comments for public APIs
- Add explanatory comments for complex logic
- Use English for all comments and documentation
We follow the Conventional Commits specification. The commit message format is:
<type>(<scope>): <subject>
<body>
<footer>
Types:
feat: A new featurefix: A bug fixdocs: Documentation only changesstyle: Code style changes (formatting, etc., that don't affect code execution)refactor: Code refactoringperf: Performance improvementstest: Adding or updating testschore: Changes to build process or auxiliary tools
Example:
feat(syscall): add epoll system call support
Implement epoll_create, epoll_ctl, and epoll_wait system calls,
supporting both edge-triggered and level-triggered modes.
Closes #123
- Rebasing guidance: When you need to sync your feature branch with the main branch's progress, use
rebaseinstead ofmerge(see below). However, avoid repeatedly rebasing your PR branch during active development, as excessive rebasing can make history harder to follow. We will eventually use squash merge.
git fetch upstream # or origin
git rebase upstream/mainPlease keep PRs as small as possible to make them easier to review and maintain. A PR should focus on one specific feature or fix.
When creating a PR, please:
- Fill in detailed information using the PR template
- Link related Issues (if applicable)
- Describe the motivation and implementation approach
- Explain how to test these changes
By contributing code, you agree that your contributions will be licensed under the Apache License 2.0.
Thank you again for contributing to StarryOS!