|
| 1 | +# Contribution Guidelines |
| 2 | + |
| 3 | +Thank you for your interest in Dapr! |
| 4 | + |
| 5 | +This project welcomes contributions and suggestions. Most contributions require you to |
| 6 | +agree to a Contributor License Agreement (CLA) declaring that you have the right to, |
| 7 | +and actually do, grant us the rights to use your contribution. |
| 8 | + |
| 9 | +For details, visit https://cla.microsoft.com. |
| 10 | + |
| 11 | +When you submit a pull request, a CLA-bot will automatically determine whether you need |
| 12 | +to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the |
| 13 | +instructions provided by the bot. You will only need to do this once across all repositories using our CLA. |
| 14 | + |
| 15 | +This project has adopted the Microsoft Open Source Code of Conduct. |
| 16 | +For more information see the Code of Conduct FAQ |
| 17 | +or contact [email protected] with any additional questions or comments. |
| 18 | + |
| 19 | +Contributions come in many forms: submitting issues, writing code, participating in discussions and community calls. |
| 20 | + |
| 21 | +This document provides the guidelines for how to contribute to the Dapr project. |
| 22 | + |
| 23 | +## Issues |
| 24 | + |
| 25 | +This section describes the guidelines for submitting issues |
| 26 | + |
| 27 | +### Issue Types |
| 28 | + |
| 29 | +There are 4 types of issues: |
| 30 | + |
| 31 | +- Issue/Bug: You've found a bug with the code, and want to report it, or create an issue to track the bug. |
| 32 | +- Issue/Discussion: You have something on your mind, which requires input form others in a discussion, before it eventually manifests as a proposal. |
| 33 | +- Issue/Proposal: Used for items that propose a new idea or functionality. This allows feedback from others before code is written. |
| 34 | +- Issue/Question: Use this issue type, if you need help or have a question. |
| 35 | + |
| 36 | +### Before You File |
| 37 | + |
| 38 | +Before you file an issue, make sure you've checked the following: |
| 39 | + |
| 40 | +1. Is it the right repository? |
| 41 | + - The Dapr project is distributed across multiple repositories. Check the list of [repositories](https://github.com/dapr) if you aren't sure which repo is the correct one. |
| 42 | +1. Check for existing issues |
| 43 | + - Before you create a new issue, please do a search in [open issues](https://github.com/dapr/quickstarts/issues) to see if the issue or feature request has already been filed. |
| 44 | + - If you find your issue already exists, make relevant comments and add your [reaction](https://github.com/blog/2119-add-reaction-to-pull-requests-issues-and-comments). Use a reaction: |
| 45 | + - 👍 up-vote |
| 46 | + - 👎 down-vote |
| 47 | +1. For bugs |
| 48 | + - Check it's not an environment issue. For example, if running on Kubernetes, make sure prerequisites are in place. (state stores, bindings, etc.) |
| 49 | + - You have as much data as possible. This usually comes in the form of logs and/or stacktrace. If running on Kubernetes or other environment, look at the logs of the Dapr services (runtime, operator, placement service). More details on how to get logs can be found [here](https://github.com/dapr/docs/tree/master/best-practices/troubleshooting/logs.md). |
| 50 | +1. For proposals |
| 51 | + - Many changes to the Dapr runtime may require changes to the API. In that case, the best place to discuss the potential feature is the main [Dapr repo](https://github.com/dapr/dapr). |
| 52 | + - Other examples could include bindings, state stores or entirely new components. |
| 53 | + |
| 54 | +## Contributing to Dapr |
| 55 | + |
| 56 | +This section describes the guidelines for contributing code / docs to Dapr. |
| 57 | + |
| 58 | +### Pull Requests |
| 59 | + |
| 60 | +All contributions come through pull requests. To submit a proposed change, we recommend following this workflow: |
| 61 | + |
| 62 | +1. Make sure there's an issue (bug or proposal) raised, which sets the expectations for the contribution you are about to make. |
| 63 | +1. Fork the relevant repo and create a new branch |
| 64 | +1. Create your change |
| 65 | + - Code changes require tests |
| 66 | +1. Update relevant documentation for the change |
| 67 | +1. Commit and open a PR |
| 68 | +1. Wait for the CI process to finish and make sure all checks are green |
| 69 | +1. A maintainer of the project will be assigned, and you can expect a review within a few days |
| 70 | + |
| 71 | +#### Use work-in-progress PRs for early feedback |
| 72 | + |
| 73 | +A good way to communicate before investing too much time is to create a "Work-in-progress" PR and share it with your reviewers. The standard way of doing this is to add a "[WIP]" prefix in your PR's title and assign the **do-not-merge** label. This will let people looking at your PR know that it is not well baked yet. |
| 74 | + |
| 75 | +### Use of Third-party code |
| 76 | + |
| 77 | +- All third-party code must be placed in the `vendor/` folder. |
| 78 | +- `vendor/` folder is managed by Go modules and stores the source code of third-party Go dependencies. - The `vendor/` folder should not be modified manually. |
| 79 | +- Third-party code must include licenses. |
| 80 | + |
| 81 | +A non-exclusive list of code that must be places in `vendor/`: |
| 82 | + |
| 83 | +- Open source, free software, or commercially-licensed code. |
| 84 | +- Tools or libraries or protocols that are open source, free software, or commercially licensed. |
| 85 | + |
| 86 | +**Thank You!** - Your contributions to open source, large or small, make projects like this possible. Thank you for taking the time to contribute. |
| 87 | + |
| 88 | +## Code of Conduct |
| 89 | + |
| 90 | +This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). |
0 commit comments