Develop Github Issue Management Process

[mattcaswell]

Develop a Github Issue management process for "wrangling" of newly raised github issues.

We should consider how new issues are triaged; how they are prioritised; how we determine which issues we work on and which we leave to the community; and when and under what conditions we close an issue.

[baentsch]

and when and under what conditions we close an issue.

May I suggest the following logic, particularly for "old-ish" (TBD what concrete age that means) issues:

• Create a message (ideally, after manual content check, possibly via automated comment) whether the issue author is still interested in moving this forward announcing future closing if no response is forth coming.
• If no response is received after some time (TBD), auto-close the issue for good.
• If a response is received, decide whether to move this "re-activated" issue to some concrete task/epic actively worked on by the core team or whether the issue shall be labelled a "community effort" (with a clear statement what that means, e.g., that the core team cannot work on it but will review PRs as and when provided).

The above could work for issues and PRs (which actually are GH issues). It also assumes that issues/suggestions that are absolutely against OpenSSL architecture or goals will be closed "as Wont' Happen" when triaged as such (or re-activated as per the above) by a core team member.

fwiw, there's a script codifying part of this already to some degree. Feedback and joint code improvements very welcome.