Contribution overview

Thank you for your interest in Dapr! This document provides the guidelines for how to contribute to the through issues and pull-requests. Contributions can also come in additional ways such as engaging with the community in community calls, commenting on issues or pull requests and more.

See the Dapr community repository for more information on community engagement and community membership.

In most Dapr repositories there are usually 4 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/Question: Use this issue type, if you need help or have a question.

Before submitting

  1. Is it the right repository?
    • The Dapr project is distributed across multiple repositories. Check the list of repositories if you aren’t sure which repo is the correct one.
  2. Check for existing issues
    • Before you create a new issue, please do a search in 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
  3. For bugs
    • Check it’s not an environment issue. For example, if running on Kubernetes, make sure 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. 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 .
  4. For proposals
    • Other examples could include bindings, state stores or entirely new components.

All contributions come through pull requests. To submit a proposed change, follow this workflow:

  1. Make sure there’s an issue (bug or proposal) raised, which sets the expectations for the contribution you are about to make.
  2. Fork the relevant repo and create a new branch
    • Some Dapr repos support to provide an instant environment for you to build and test your changes.
    • See the Developing Dapr docs for more information about setting up a Dapr development environment.
  3. Create your change
    • Code changes require tests
  4. Update relevant documentation for the change
  5. Commit with and open a PR
  6. Wait for the CI process to finish and make sure all checks are green
  7. A maintainer of the project will be assigned, and you can expect a review within a few days

Use work-in-progress PRs for early feedback

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.

  • Third-party code must include licenses.

Every commit needs to be signed

The Developer Certificate of Origin (DCO) is a lightweight way for contributors to certify that they wrote or otherwise have the right to submit the code they are contributing to the project. Here is the full text of the DCO, reformatted for readability:

Contributors sign-off that they adhere to these requirements by adding a line to commit messages.

Each Pull Request is checked whether or not commits in a Pull Request do contain a valid Signed-off-by line.

I didn’t sign my commit, now what?!

No worries - You can easily replay your changes, sign them and force push them!

Please see the .

Last modified September 28, 2022: Upmerge v1.8 —> v1.9 - 9/28 (#2839) (9286e093)