Issue management

[canstudios-louisem]

I would like to have a discussion about how best we can manage issues. Currently, labels are not used as well as they could and it's not always easy to see the state of all the issues on a milestone.

I'm looking at the 0.4.0 milestone issues and struggling to see what we have done and what is left to be done how would people feel about creating a pr-merged or awaiting-release label for issues that way you could filter issues that still need to be looked at it would also help us to close issues when the release is merged into develop.

I'm happy to have a discussion on this post 0.4.0

We currently do give people much guidance on what should be in an issue. This makes things hard when reviewing them and their associated PR's to that end I have created a PR containing an issue template. It would be good to get something into 0.4.0 as it will then be merged into master soonish and it can then be used.

[taylortom]

We generally try to keep documentation in the wiki rather than in the repo itself, as we thought it made sense to keep everything in a central location (we removed the install instructions for this reason).

We've also already got this page which details reporting bugs, so the information's already there for those that look. Feel free to add to this page -- it may be useful to link to your template here too.

I think we could also do with mentioning this page in the CONTRIBUTING.md file, as GitHub has nice UI integration for this file:

[canstudios-louisem]

I agree that docs should be in the wiki i dont see the issue template as docs but more a simple "form" giving people a bit more obvious guidance. Even just trimming it right down to "whats broken", "how do i replicate it" would be super usefull when It comes to both fixing it and testing the pr, if you feel what i put in the pr is too heavy handed.

The other issue with the contribution guidelines is that not everyone that raises an issue will read them, thoes people may not also fill out the short form but they are more likely to do so.

Im more than happy to edit the guidelines to include that link though.

[taylortom]

Turns out I completely misunderstood the use of the ISSUE_TEMPLATE PR (for anyone else who's uninitiated, see https://github.com/blog/2111-issue-and-pull-request-templates).

@canstudios-louisem also suggested that we opt for an approach with labelling similar to that used by the PM2 repo: https://github.com/Unitech/pm2/labels

As I see it, we at least need labels for:

• Priority (e.g. critical, high, low)
• Status (e.g. in-progress, done, merged)
• Type (e.g. bug, enhancement)

Other possible areas:

• Area/component (e.g. installer, API)
• Difficulty (e.g. epic, easy)

[canstudios-louisem]

I think rather than Priority an Impact (Critical system, Major system, Minor system) label can be easier to define. My issue with priority is its hard to define that is a priority and it's easy to misuse I'm sure we have all seen projects where every issue is flagged as a priority.

Critical would be areas like login and preview that stop the fundamental use of the tool. Major would be things like user creation which are critical areas but that can be worked around. Minor would be things like asset previews.

I think what ever labels we go with they need a definition somewhere in the docs.

[taylortom]

Adopted a while ago