Issue and pull request management details

Issue and pull request management details

Incoming issues are labeled according to the existing and pretty complete label collection. Unfortunately, it's not possible to put labels on PRs, that's why it makes sense to have issues first. Labeling is used to categorize issues, and multiple labels can be used. IS the issue a bug or feature? In the core or an addon? Use OS- and IDE-specific labels, if an issue is restricted to a set of OSes or IDEs. Does the issue describe a small fix? etc. etc. Labels are also used to assign issues to certain sections via the section-xxx labels (except for iOS and documentation/examples, which already existed). A detailed description of the labels' meanings can be found here.

Where applicable, issues and PRs are also assigned to Milestones according to the Roadmap document and further considerations/common sense.

It is possible to refine the issue list on github by clicking on the labels on the left hand side to show only issues having a certain set of labels. This is also reflected in the URL, so it's easy to automate if you want. Also, you can restrict the view to certain Milestones, that's handy if you need to prioritize bug treatment and concentrate on the next release. Milestones also give us an automatic assessment about how far along we are on our way towards a release.

I don't think it's possible to tailor Github notification with regard to labels - all admins of the repo get all notifications. If you need to summon someone to look at something, use the @<githubusername> syntax, and they'll get a notification. It will autocomplete for people with push access to the repo you're in, but will work with any GH username.

Initial treatment/labeling/assignment of newly incoming issues and labels is mainly done by the issue tracker leader. It is most appreciated, though, if new section leaders go through the list of existing issues, make sure they are labeled correctly (probably have to add a section-x label), and give their new bugs some love - make sure they're still relevant, get necessary information from the reporter, and start working on resolving them. There's a list of canned responses which may prove useful when dealing with bug reports.