BuildXL/CONTRIBUTING.md

Contributing to BuildXL

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

The Code of Conduct this project has adopted is described in: CODE_OF_CONDUCT.md.

Submitting Pull Requests

• DO ensure your contribution has associated unit tests.
• DO ensure submissions pass all Azure DevOps Pipelines phases and are merge conflict free.
• DO NOT submit build engine features as PRs to this repo first, or they will likely be declined.
• DO submit issues for features. This facilitates discussion of a feature separately from its implementation, and increases the acceptance rates for pull requests.
• DO NOT submit large code formatting changes without discussing with the team first.

These two blogs posts on contributing code to open source projects are good too: Open Source Contribution Etiquette by Miguel de Icaza and Don’t “Push” Your Pull Requests by Ilya Grigorik.

Developer Guide

When you are ready to proceed with making a change, get set up to build the code (see the Developer Guide) and familiarize yourself with our developer workflow.

Creating Issues

• DO use a descriptive title that identifies the issue to be addressed or the requested feature. For example, when describing an issue where the compiler is not behaving as expected, write your bug title in terms of what the compiler should do rather than what it is doing – “C# compiler should report CS1234 when Xyz is used in Abcd.”
• DO specify a detailed description of the issue or requested feature.
• DO provide the following for bug reports
  • Describe the expected behavior and the actual behavior. If it is not self-evident such as in the case of a crash, provide an explanation for why the expected behavior is expected.
  • Provide example code that reproduces the issue.
  • Specify any relevant exception messages and stack traces.
• DO subscribe to notifications for the created issue in case there are any follow up questions.