First off, thank you for considering contributing to DebugRouter! We welcome you to join and become a member of Lynx Authors. It's people like you who make this project great.
If you find a bug, please open an issue with the following details:
- A clear and descriptive title for the issue.
- A description of the steps to reproduce the issue.
- Any additional information or screenshots that might help us understand the issue better.
We’re always open to new ideas! If you have a suggestion, please:
- Use the “Feature Request” issue template or create a new issue.
- Describe the enhancement you’d like and explain why it would be useful.
Unsure where to start? You can find beginner-friendly issues by looking for the “good first issue” label. Working on these issues helps you get familiar with the codebase before tackling more complex problems.
When you’re ready to make a code change, please create a pull request:
- Fork the repository and clone it to your local machine.
- Create a new branch:
git checkout -b name-of-your-branch. - Make your changes.
- Once you have finished the necessary tests and verifications locally, commit the changes with a commit message.
- Push the changes to your remote branch and start a pull request.
We encourage the submission of small patches and only accept PRs that contain a single commit. Therefore, please split your PR into separate ones if it contains multiple commits, or squash them into a single commit if there are not too many changes. The CI will reject any PR that contains more than one commit.
- Make sure that your pull request adheres to the style guide and is properly documented.
A pull request needs to be verified by the CI jobs and reviewed by the Lynx authors before being merged.
Once you submit a pull request, you can invite the contributors of the repository to review your changes. If you have no idea whom to invite to review your changes, the Github branch protection rules and git blame are the right places to start.
While any contributor can review your changes, at least one of the authors from default reviewers should be on the reviewer list. Default reviewers can help trigger the CI workflow run to verify the changes (if this is your first PR for DebugRouter, you'll see a pending approval on the PR discussion area after you submit the PR) and then start the landing process. (The reason why the workflow run needs to be triggered by default reviewers is that they need to make sure the new changes will not introduce any risks)
Typically, a pull request will be reviewed within one week. The landing process will be triggered manually if the changes pass all CI checks and are ready to be merged.
Our project adheres to the coding style guidelines provided by Google. You can find the detailed guidelines here: Google's Style Guides.
Following these style guides helps ensure that our code is consistent, clear, and of high quality. Please make sure to familiarize yourself with these guidelines of C++, TypeScript, Java, Objective-C and Python before contributing to the project.
Special thanks to Google for making these comprehensive style guides available for developers!
Please note that all participants in this project are expected to uphold our Code of Conduct. By participating, you agree to abide by its terms.
If you have any questions or need further assistance, feel free to contact us:
- Email: popoaichuiniu@hotmail.com
- GitHub Issues: Open an issue
We’re excited to see your contributions! Thank you!