Thank you for your interest in contributing to Bop music player. I appreciate all help with finding and fixing bugs, making performance improvements, and other tasks. Every contribution is helpful and I thank you for your effort. To ensure the process of contributing is as smooth as possible, here are a few guidelines for you to follow.
- Remember to Create an Issue before submitting any major changes like new feature or UI changes etc. Changes like addition of new language or Spelling mistakes doesn't require issue creation.
Feature requests are a way for you to pitch your amazing ideas of enhancements or new features you want to see on the app. Your ideas would certainly help to improve the app. However, it is important to browse through the issue tracker to see if the feature you want to request for hasn't already been requested by another user. If you have gone through the issue tracker and the feature request hasn't been made, feel free to request the new feature. To do that, you need to open an issue
In order to help the developer understand the feature request;
- Title of the issue should be explicit, giving insight into the content of the issue.
- The area of the project where your feature would be applied or implemented should be properly stated. Add screenshots of mockup if possible.
- It would be great if a detailed use case is included in your request.
You can as well utilize the already laid down "feature request" template on the post editor.
When submitting a feature request, please make a single issue for each feature request (i.e. don't submit an issue that contains a list of features). Such issues are hard to keep track of and often get lost.
Firstly, I apologize for any inconvenience this issue may have caused you. I'm working to ensure that the app is bug-free. You can help speed up that process by a report to me when you encounter an error, or when the app crashes.
Filing a great bug report helps the developer pinpoint the cause of the bug and effectively work on a fix.
Before filing a bug report;
- Check the issue tracker if the bug hasn't been reported by other users. If it has been reported before it is likely to be in opened issues. Also, check closed issues too.
- Ensure you're running the latest version of the software
- Confirm if it's actually a bug and not an error caused by a plugin on your system. Test with other systems to verify
- If the same issue persists after testing on other devices then it is indeed a bug.
The developer encourages more small commits over one large commit. Small, focused commits make the review process easier and are more likely to be accepted. It is also important to summarise the changes made with brief commit messages. If the commit fixes a specific issue, it is also good to note that in the commit message.
The commit message should start with a single line that briefly describes the changes. That should be followed by a blank line and then a more detailed explanation. As a good practice, use commands when writing the message (instead of "I added ..." or "Adding ...", use "Add ...").
Before committing check for unnecessary whitespace with git diff --check.
For further recommendations, see Pro Git Commit Guidelines.
The following guidelines can increase the likelihood that your pull request will get accepted:
- Work on topic branches.
- Follow the commit guidelines.
- Keep the patches on topic, focused, and atomic.
- Try to avoid unnecessary formatting and clean-up where reasonable.
A pull request should contain the following:
- At least one commit (all of which should follow the Commit Guidelines)
- Title that summarises the issue
- Description that briefly summarises the changes
After submitting a pull request, you should get a response within the next 7 days. If you do not, don't hesitate to ping the thread.
If you don't know how to create a pull request, this section will help you to get started.
Here's a detailed content on how to Create a pull request
Simply put, the way to create a Pull request is first to;
- Fork the repository of the project which in this case is Bop Music Player
- Commit modifications and changes to your fork
- Send a pull request to the original repository you forked your repository from in step 1
Do you have ideas of some new cool functionalities, a bug fix or other code you wish to contribute? This is the perfect section to guide you on that path.
Make sure your project is building and running in your local machine and every change you made doesn't explicitly affect the another feature of the project. Also check for any gradle or runtime errors.
Bop music player code uses Travis Ci to check for build error. After submitting PR you wil find that Travis would run for some checks, If checks failed, please look at the log through clicking "Details". Perfect example for this scenerio would be [this]#35).
At the top of every patch, you should include a description of the problem you are trying to solve, how you solved it, and why you chose the solution you implemented. If you are submitting a bug fix, it is also incredibly helpful if you can describe/include a reproducer for the problem in the description as well as instructions on how to test for the bug and verify that it has been fixed.
For further inquiries, you can contact the developer via email. Send an email to [email protected]. The developer can also be contacted by opening an issue on the repository.
You can also check out the developer's profile here.
Thank you for your interest in contributing to Bop music player. I appreciate all help with finding and fixing bugs, making performance improvements, and other tasks. Every contribution is helpful and I thank you for your effort.