Hello, and thank you for your interest into our small project ! We will detail here how to make good issues and pull requests, as well as our code of conduct. Please, make sure to read this document before try to contribute the project. It's not long, you'll see :)
If you are searching about documentation on the project, please check the wiki tab ! => https://github.com/OpenWeek/app-for-a-KAP/wiki
Writing issues can be about a few different things. A bug report, a feature request, a discussion about a feature or a more general discussion about the game. However, we ask you to check beforehand, whenever you want to post an issue, if the issue hasn't been issued before. In order to be organized in the development, we need to centralize the discussions. For this reason, avoiding redundancy is a necessity.
If it's the case and your problem/topic has already been issued, you can however participate in the corresponding discussion. If the corresponding issue has already been closed, you may reopen it if you find it necessary, but this case depends if it's a bug report or not. For instance if you ask for a feature request that has already been asked in the past and rejected, the answer will most probably be again no.
There's the check-list to read before post your bug report. Please follow it. If you want to report multiple bugs, please make a different issue for each one of them, it will be easier for us.
- Check if your bug hasn't been reported already. If that's the case, you can add a new message in the discussion. More people reports a bug, more easily it will be for us to locate and fix it ! If the bug has been reported in the past and the issue closed, you may reopen the issue if you still have the problem.
- Give a small resume of your bug. What were you doing when it happened, what were you expecting to do ?
- Define precisely the steps to reproduce the bug. If we can't reproduce it, it may be something entirely out of our scope that produce the problem.
- Give specifications about your system. For example, which version of Android do you use ? What's your phone brand and it's reference ? If it's something graphic related, what's the size of your screen ? More information we get, more easily we will be able to locate the bug.
When the bug report has been done, stay in check with the issue ! We may get back to you to get more information or to ask you if the bug has been fixed (after patched the game).
You have a wonderful idea that would fit right into the game ? Or did you thought about a new minigame on the topic ? Let us know ! We are interested of hearing new ideas. However, keep in mind we may not be able to implement them for our deadline. But they may be added in the future (don't hesitate to do a pull request !).
To make a good feature request, please read the following check-list :
- Check if the feature or a similar one hasn't be requested yet. If that's the case, join the conversation !
- Explain your feature, give some details. Saying things like "Another minigame would be good" doesnt help us much. Go deeper.
- Tell us why this feature would be a good idea. Sell your idea ! (in the figurative meaning).
Keep in mind we reserve ourself the right to have the final word if we add or modify something. But we are sensible to argumentation but don't be angry if we still refuse your request. Also, small features requests have more chance to be accepted than bigger ones. Adding a sound is easier than add an entire new minigame !
Thank you for taking some of your time to contribute directly to the project !
Before making a pull request, we ask you to do a few different things first :
- Check first if your changes hasn't been already done by someone else if your fork isn't up-to-date.
- Check if your code compile. A code which is isn't compiling will be automatically rejected.
- Check for any bugs in the code you are requesting. Try to make it clean as possible.
- Respect coding conventions. We are using Java as main programming language, thus respect Java coding styleguide. For example, use camelCase.
- When you will submit your request, some of our team will review your code. We may ask you to change certain pieces of code. You may apply them or if you estimate that the requested changes aren't relevant, you can discuss about it.
We appreciate any sort of collaboration. However, keep in mind we reserve ourself the right to have the final work if we accept or not your PR. Don't go mad if we refuse to accept it.
Important note
If you start to contribute to the project, we will assume you have read this file and the code of conduct and accepted the terms.