Handling github issues

[rborn]

Right now there is no common or "standard" way of handling the github issues in the community modules. Each module does it differently but maybe we should be try to unify this in a consistent behaviour.

Some modules are more complicated than other and attract many issues that are just questions or "not working" which waste the maintainers time.

For an initial triage few steps could be implemented:

• determine what kind of issue a user can open (github seems to do this easily with the template files, like here: https://github.com/react-native-community/react-native-netinfo/issues/new/choose)
• create/reuse a bot that would parse the issue and force them respect the templates we put in place (fastlane for example has a nice one)
• implement some rules for stale issues (close them after a while)
• extend the bot to filter "+1", "me too", "same here" type of comments

Please add any comments/ideas you might have 🤗

[kelset]

👋 there!

Thanks for opening this issue! I really agree with you, we should have common rules and guidelines about those - this is one of the things that I'd like to cover in the guidelines, in particular in this file -> https://github.com/react-native-community/meta/blob/master/Guidelines/Repository%20Maintenance.md

Let's start by talking about it here.

I think that when it comes to issue triaging, there should be a few things that should be done:

• setup proper labels (a few are good first issue, stale, need repro, need info, feature request, bug report)
• ideally every time an issue is open the maintainer should be able to reply to that issue and label it properly, not necessarily fix the issue but at least acknowledge the person that opened said issue. We used a few "copy-pasta replies" when we did the London triage session that can be reworked to work on these repos I feel -> https://github.com/facebook/react-native/issues/24032
• the templates can be shared at org level so we just need to create once I think

Also, some "concepts":

• the maintainer is not per se bound to fix all the issues nor solve all the problems
• it's ok to close an issue if there is no way to "transform" the report into something actionable
• when someone submits a bug report he/she should be asked to try and work on it, help, submit a PR

(these are but a few things I had in mind, let's start discussing these)

---

Btw, on this:

extend the bot to filter "+1", "me too", "same here" type of comments

Actually github already does soem auto "hiding" of this kind of comment, so I wouldn't be too worried.

[matt-oakes]

One big first step would be to have the issue and pull request templates at the organisation level. Those help a lot with making sure that you don't get the "it doesn't work" issues.

The ones for the CLI project seem to be the most complete, and I've already used them for the NetInfo module:

https://github.com/react-native-community/react-native-netinfo/commit/eb78ade2eb8f1201b0ca6609a066ca48cbb5b600

Later on, we could have a bot which automatically closes issues which don't follow the template, but for the majority of the repos they shouldn't get enough traffic for this to be needed right from the start.

[matt-oakes]

I forgot to add the link to the documentation for the org level health files:

https://help.github.com/en/articles/creating-a-default-community-health-file-for-your-organization

If someone can create the .github repo then I'd be happy to add the required files 👍

[kelset]

I'd prefer to get some more feedback before doing the steps of the org level docs because I'm still waiting for a portion of the maintainers to reach out to me and get access to Discord. But yeah that's the plan for common files 🤗

[kelset]

Also, as a general rule that potentially would be great to have a bot for: locking issues that have been closed & had no interaction for 15+ days.

[mikehardy]

FWIW I would love anything that goes towards a standard enforcement of templates etc. The quality of issue reporting in general is...shocking - and it burns so much time + mental energy trying to be courteous and responsive while handling

I'm going to look at the cli / netinfo scripts and see if I can set up some templates for the packages I work with