Contributor Help page
This wiki page is directed at all direct contributors to this project which have access to mark and order issues and pull requests.
It holds informational value in how to handle those.
There are currently 14 labels, that can be grouped in two categories. Some can be used in both categories.
-
This means the issue is meantioning a bug, or something that doesn't work like expected.
-
A suggestion that enhances or improves the tool
-
That's when an issue is added by devs that is neither a real enhancement nor a bugfix. It's simply something that needs to be done. Todo.
-
When an issue is or contains a question
-
When an issue has to be checked more detailed by a dev. To inspect if something is really a bug, etc. Remove this label and leave a small comment if the check is completed.
-
When more info is needed from the issue opener, add this label. After the info is given, remove it.
-
A duplicate issue that was added before. Leave a comment linking to the issue, add this label, then close it (directly, or later).
-
An issue or suggestion that we won't fix or add. Add this label and leave it open for some days so all can see. Then close.
-
That label is more made for PRs, but can be used for issues in seldom cases, if we want to show our users/issue openers that we are actively working on that issue.
This means the issue is meantioning a bug, or something that doesn't work like expected.
A suggestion that enhances or improves the tool
That's when an issue is added by devs that is neither a real enhancement nor a bugfix. It's simply something that needs to be done. Todo.
When an issue is or contains a question
When an issue has to be checked more detailed by a dev. To inspect if something is really a bug, etc. Remove this label and leave a small comment if the check is completed.
When more info is needed from the issue opener, add this label. After the info is given, remove it.
A duplicate issue that was added before. Leave a comment linking to the issue, add this label, then close it (directly, or later).
An issue or suggestion that we won't fix or add. Add this label and leave it open for some days so all can see. Then close.
That label is more made for PRs, but can be used for issues in seldom cases, if we want to show our users/issue openers that we are actively working on that issue.-
Each pull request should always be marked with one of those labels, showing what it does. We should also stick to seperating enhancements and fixes and not do them in one PR. That makes work a LOT easier.
-
-
That's the most important part here. I personally think that this is pretty important to save a lot of bugs before releases and that not only one person knows what some things does. So we can work better on that project. If a dev thinks his PR is done, "needs code review" is added, and one of the contributors will take that and review the code. And not just a short look on the changes, but he should understand what was done and why. If something is wrong, he writes a comment, removes the label and adds "waiting for more". If everything is fine, he removes the label, adds "ready to merge" and adds a small comment summarizing his review.
-
-
If the review was successfull and everything is done, remove the work labels and add this. Don't merge directly, there may be conflicts we want to prevent. Let's decide on Discord together when a PR gets merged.
-
If a dev has questions and wants help with his PR, he can add this label to show that there are more than one persons that should work on that PR.
Each pull request should always be marked with one of those labels, showing what it does. We should also stick to seperating enhancements and fixes and not do them in one PR. That makes work a LOT easier.
That's the most important part here. I personally think that this is pretty important to save a lot of bugs before releases and that not only one person knows what some things does. So we can work better on that project. If a dev thinks his PR is done, "needs code review" is added, and one of the contributors will take that and review the code. And not just a short look on the changes, but he should understand what was done and why. If something is wrong, he writes a comment, removes the label and adds "waiting for more". If everything is fine, he removes the label, adds "ready to merge" and adds a small comment summarizing his review.
If the review was successfull and everything is done, remove the work labels and add this. Don't merge directly, there may be conflicts we want to prevent. Let's decide on Discord together when a PR gets merged.
If a dev has questions and wants help with his PR, he can add this label to show that there are more than one persons that should work on that PR.I guess you know you can link issues with hashtag (#) and the correct number. PRs too. Make use of that feature to link issues that are connected and to close issues with PRs.
Just use Fixes #xx in the message of the PR. That will close the issue automatically when the PR gets merged.
More info: [Closing Issues via Pull Requests](Closing Issues via Pull Requests), Keywords for closing issues
Still make sure that issues are closed later.
Make issues overseeable. I know people tend to add lots of things together in one issue to don't bother developers that much, but it doesn't help. It makes everything more complicated.
Sure, you can make GitHub ToDo lists as a comment in that issue, but that's still not the best way.
I would suggest to open issues for every single bug/enhancement from that issue, link the main issue and add the reporting user via @mention so that he is informed. After that close the big grouped issue.
Whoa, that's a cool thing. If one issue should be fixed by dev XY, add him. He can take it over. If you want to do an issue? Add yourself as assignee, then others know they don't have to do that. Assignees can also be used for PR code reviews.
Milestones will be defined by @Wolfsblvt, the owner of this tool, or the team together. They are usually new releases. When the next release is set (we should not set dates, just release numbers), we have to order issues and PRs that should be included there and set the milestone.
A release can't be released if there are still open issues or PRs for it. If an issue or PR should be changed to a later milestone, talk with the other devs on Discord.