If you want to contribute to Mopidy, here are some tips to get you started.
Please get in touch with us in one of these ways when requesting help with Mopidy and its extensions:
- Our Discourse forum: discourse.mopidy.com.
#mopidy-devstream on Zulip chat: mopidy.zulipchat.com.
Before asking for help, it might be worth your time to read the Troubleshooting page, both so you might find a solution to your problem but also to be able to provide useful details when asking for help.
If you want to contribute to Mopidy, a great place to start is by helping other
users in the discussion forum and the
#mopidy-users Zulip stream. This is a
contribution we value highly. As more people help with user support, new users
get faster and better help. For your own benefit, you’ll quickly learn what
users find confusing, difficult or lacking, giving you some ideas for where you
may contribute improvements, either to code or documentation. Lastly, this may
also free up time for other contributors to spend more time on fixing bugs or
implementing new features.
- If you need help, see Asking questions above. The GitHub issue tracker is not a support forum.
- If you are not sure if what you’re experiencing is a bug or not, post in the discussion forum first to verify that it’s a bug.
- If you are sure that you’ve found a bug or have a feature request, check if there’s already an issue in the issue tracker. If there is, see if there is anything you can add to help reproduce or fix the issue.
- If there is no exising issue matching your bug or feature request, create a new issue. Please include as much relevant information as possible. If it’s a bug, including how to reproduce the bug and any relevant logs or error messages.
Pull request guidelines¶
Before spending any time on making a pull request:
- If it’s a bug, file an issue.
- If it’s an enhancement, discuss it with other Mopidy developers first, either in a GitHub issue, on the discussion forum, or on Zulip chat. Making sure your ideas and solutions are aligned with other contributors greatly increases the odds of your pull request being quickly accepted.
Create a new branch, based on the
developbranch, for every feature or bug fix. Keep branches small and on topic, as that makes them far easier to review. We often use the following naming convention for branches:
- Features get the prefix
- Bug fixes get the prefix
- Improvements to the documentation get the prefix
- Features get the prefix
Include tests for any new feature or substantial bug fix. See Running tests.
Include documentation for any new feature. See Writing documentation.
Feel free to include a changelog entry in your pull request. The changelog is in
Write good commit messages.
- Follow the template “topic: description” for the first line of the commit message, e.g. “mpd: Switch list command to using list_distinct”. See the commit history for inspiration.
- Use the rest of the commit message to explain anything you feel isn’t obvious. It’s better to have the details here than in the pull request description, since the commit message will live forever.
- Write in the imperative, present tense: “add” not “added”.
For more inspiration, feel free to read these blog posts:
Send a pull request to the
developbranch. See the GitHub pull request docs for help.
If you are contributing a bug fix for a specific minor version of Mopidy
you should create the branch based on
release-x.y instead of
develop. When the release is done the changes will be merged back into
develop automatically as part of the normal release process. See