Thank you for your interest in Dapr Sidekick!
This project welcomes contributions and suggestions. Contributions come in many forms such as submitting issues, writing code or participating in discussions.
This document provides the guidelines for how to contribute to the Dapr Sidekick project.
This section describes the guidelines for submitting issues.
There are 5 types of issues:
- Issue/Bug: You've found a bug with the code, and want to report it, or create an issue to track the bug.
- Issue/Discussion: You have something on your mind, which requires input form others in a discussion, before it eventually manifests as a proposal.
- Issue/Feature Request: You would like to request a new feature to be implemented by the community. This would normally be smaller in scope than a Proposal.
- Issue/Proposal: Used for items that propose a new idea or functionality, including features you would like to implement yourself. This allows feedback from others before code is written.
- Issue/Question: Use this issue type, if you need help or have a question.
Before you file an issue, make sure you've checked the following:
- Check for existing issues
- Before you create a new issue, please do a search in open issues to see if the issue or feature request has already been filed.
- If you find your issue already exists, make relevant comments and add your reaction. Use a reaction:
- 👍 up-vote
- 👎 down-vote
- For bugs
- Check it's not an environment issue. For example, make sure Dapr prerequisites are in place. (state stores, bindings, etc.)
- You have as much data as possible. This usually comes in the form of logs and/or stacktrace.
This section describes the guidelines for contributing code / docs to Dapr Sidekick.
All contributions come through pull requests. To submit a proposed change, we recommend following this workflow:
- Make sure there's an issue (bug or proposal) raised, which sets the expectations for the contribution you are about to make.
- Fork the repo and create a new branch
- Create your change
- Code changes require tests
- Update relevant documentation for the change
- Commit and open a PR
- Wait for the CI process to finish and make sure all checks are green
- A maintainer of the project will be assigned, and you can expect a review within a few days
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.
Thank You! - Your contributions to open source, large or small, make projects like this possible. Thank you for taking the time to contribute.