To contribute code to the muse-player project, you need to follow the standard fork and pull request workflow. That is:
- Clone the museplayer repo onto your machine and create a new branch to develop your feature on.
- Create a remote fork of the muse-player repo to push your changes to once they are ready.
- Remember to rebase your fork on the master branch of the muse-player repo before you submit your pull request. This will help to avoid messy merging scenarios.
- Submit a detailed pull request against the master branch of the muse-player repo.
Pull requests will be reviewed with the following guidelines in mind:
- Follow the style conventions already present in the code.
- Test your changes. If this means writing new tests, then do that. Pull requests with untested/untestable/failing changes will not be approved.
- Write detailed commit messages. If your changes are associated with a specific issue, include the issue id. The conventional approach to good commit messages is to write a short one-line summary of the changes on the first line of the commit message file and then include a more detailed description on the lines below.
Use the Issue Tracker to report bugs and request new features.
When reporting a bug or requesting a feature:
-
Make sure the issue has not already been identified by searching the Issue Tracker and the Muse developer forums
-
Make sure you are working on the latest version of the muse-player master branch. Your issue may have been addressed since you last pulled.
-
Describe your issue clearly, carefully, and in detail.
-
If it's a bug, that means:
- State your problem
- The context of the problem (muse-player version, OS, the model of your machine, and any other relevant basic details)
- What you were attempting to achieve
- How exactly you triggered the problem
- ...and what you tried to solve it.
-
If it's a feature request, that means:
- Carefully describe why the feature should be added.
- Explain how it would benefit the majority of users.
-