Policy for adding new modules

[rnorth]

We often receive proposals (or fully formed PRs) for new modules, but don't have a clear policy on whether to accept them or not.

In the past we have accepted a small number of modules that have caused us significant maintenance headaches long after the contributor has gone away, and I'd like to avoid this in future. Equally, we'd like to encourage useful modules to be contributed!

We should have a policy in our documentation that:

• Describes our criteria for 'what kinds of module we would accept', so that people can work out whether to expend effort on a contribution.

• Provides a checklist for things we look for in a module PR (e.g. mainstream appeal, reliability and licensing for required docker images, docs, etc)

• Sets out a process for gently onboarding a new module into the official modules 'ecosystem' - e.g. ensuring stability of tests in our CI, scope for user feedback that may change the public API, etc. My initial thought is some kind of beta/incubator label for new modules.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this.

[rnorth]

This was actually resolved in #1576