You see a problem with the game. Or maybe something you think should be added? Time to create an issue.
This is done in the issues tab by hitting new issue. Several templates will appear to help you construct a well formatted issue. If you have a bug, fill out the bug template. If you don't have a specific idea but want to discuss something or brainstorm ideas, fill out the discussion thread template (don't forget to label this issue as discussion).
After you fill out the issue form, label it with the correct issues, add it to related projects, milestones, etc. Well categorized issues are important if someone is trying to find issues related to a specific problem.
We use Markdown for all our issue formatting. For a very succinct lesson in Markdown formatting visit this site.
Generally leave closing an issue to the person who opened it or the code reviewer who pulled the solution to the issue. If an issue has had no attention and seems it will not be dealt with, submit a comment mentioning the issue creator (@USERNAME using their username) asking if it can be closed.
If an issue is tagged bug and you follow the reproduce steps but can't reproduce the bugs do not close it. Instead label it with could not reproduce and wait for another user to confirm it.
If you're searching for an issue and can't find it, don't forget to search the closed issues as well.
See the labels page for a list of labels.
A pull request is how code is added from your branch to the main (or master branch). You request that the code be reviewed, and once it is approved, you can merge it into the master's branch. It is important you read and follow the steps listed below as they help protect the master branch from bugs and glitches, as well as give order to the whole process.
So how do you submit a pull request? Well, once you have completed an issue:
Branch>New Branch on the GitHub Desktop)pull request submitted label so others know you have completed that issue and are just waiting on a reviewmaster branch. In the meantime others will want to know that your code has not yet been addedTo automatically close issues with a pull request, include the issue number following a keyword such as closes or fixes. Learn More
Your pull request will be reviewed and the reviewer will almost always find something that needs to be changed, whether it be a small bug or something larger. Once you receive change requests and make the changes, they will be automatically added to your pull request as you commit them to your branch.
Be sure to update the Changes Requested category if a change alters the content of your pull request. If you feel a reviewer has requested a change that is unnecessary or incorrect, politely point this out in a comment on the pull request. If the the reviewer still denies your change and you still believe it to be a good one, you can request an additional review. If your reviewer(s) do not approve of the change, don’t lose heart! Not every change suggested will get into the main game. Move on to another change.
Note: If you do have to remove part of a pull request, don't delete it! You can just make the change on your branch and make another commit to override the previous one.
Reviewing submitted pull requests is a necessary step to building a successful project. It's not always fun, but its necessary. If you want to review code, there are some requirements you should meet:
Reviews can take 3 forms:
The comment is just a note for the reviewee, and may be submitted by anyone as it does not give or reject approval.
Reviews should be clear and concise to save time for both the reviewer and the reviewee. When writing a review you can type suggestions directly attached to lines of code by going to the files changed and clicking on the blue comment below the line. You can also suggest a correction here using ctrl-g that the reviewee can use to automatically change the code without submitting another commit. In-line comments should be used when possible for smaller errors, one-time mistakes, and typos. If a larger issue is present such as:
A general comment can be submitted at the end of the review. Reviews should always be kind and respectful. Suggest rather than demand changes and be open to different ways of doing things, even if they aren't how you pictured the solution to an issue.
Reviews must be thorough, even if just to educate the reviewee. Every pull request is a learning experience. Here's what to point out to reviewees (based on guidelines written by ryanmcdermott here)
scr_deal_damage, make sure the function only deals damage, and doesn't also check if the player is dead. That should use a different function, even if the scr_check_if_dead function is called during scr_deal_damagestring where you expeceted an int? What if the user inputs an unexpected control or escape key?TODO comments, ensure those comments are documented either in new issues or somewhere else, don't allow the code to be too cluttered with TODO comments.enhancement issue.