4.7 KiB
Contributing to MsQuic
We'd love your help with MsQuic! Here are our contribution guidelines.
Important - We are still bringing up important regression tests for the core code. Until they are onboarded, any external contributions to the core or kernel mode files in the platform will not be accepted. This is only a temporary restriction and we are working to complete it by the end of 2020.
Code of Conduct
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Microsoft Code of Conduct FAQ or contact opencode@microsoft.com with additional questions or comments.
Bugs
One of the easiest ways to contribute is to participate in discussion on GitHub issues.
If you find a non-security related bug, you can help us by submitting a GitHub Issue. The best bug reports provide a detailed description of the issue and step-by-step instructions for reliably reproducing the issue. Even better, you can submit a Pull Request with a fix.
If you find a security issue, please do not open a GitHub Issue, and instead follow these instructions.
New Features
You can request a new feature by submitting a GitHub Issue.
If you would like to implement a new feature, please first submit a GitHub Issue and communicate your proposal so that the community can review and provide feedback. Getting early feedback will help ensure your implementation work is accepted by the community. This will also allow us to better coordinate our efforts and minimize duplicated effort.
Contributor License Agreement
You will need to complete a Contributor License Agreement (CLA) for any code submissions. Briefly, this agreement testifies that you are granting us permission to use the submitted change according to the terms of the project's license, and that the work being submitted is under appropriate copyright. You only need to do this once. For more information see https://cla.opensource.microsoft.com/.
Contributing Code
We accept fixes and features! Here are some resources to help you get started on how to contribute code or new content.
- Look at the documentation to get started on building the source code on your own.
- "Help wanted" issues - these issues are up for grabs. Comment on an issue if you want to create a fix.
- "Good first issue" issues - we think these are a good for newcomers.
Process
For all but the absolute simplest changes, first submit a GitHub Issue so that the community can review and provide feedback. Getting early feedback will help ensure your work is accepted by the community. This will also allow us to better coordinate our efforts and minimize duplicated effort.
If you would like to contribute, first identify the scale of what you would like to contribute. If it is small (grammar/spelling or a bug fix) feel free to start working on a fix. If you are submitting a feature or substantial code contribution, please discuss it with the team and ensure it follows the product roadmap. You might also read these two blogs posts on contributing code: Open Source Contribution Etiquette by Miguel de Icaza and Don't "Push" Your Pull Requests by Ilya Grigorik. All code submissions will be rigorously reviewed and tested by the team, and only those that meet the bar for both quality and design/roadmap appropriateness will be merged into the source.
Tests
We have tests to prevent regressions and validate functionality. For all new Pull Requests the following rules apply:
- Existing tests should continue to pass.
- Tests need to be provided for every bug/feature that is completed.
- Tests only need to be present for issues that need to be verified by QA (for example, not tasks)
- If there is a scenario that is far too hard to test there does not need to be a test for it.
- "Too hard" is determined by the team as a whole, and should be considered extremely rare.