Add Guidance document

[tayloramurphy]

We should detail:

• Expectations to get a connector added to the hub in terms of quality / testing / etc.
• Expectations of a maintainer
• How we manage permissions and teams

Proposals from @aaronsteers:

1. Whenever we receive a PR for a tap/target that has no maintainers, we announce this to the contributor.
2. If no maintainers, perhaps we post the MR into a Slack channel somewhere to request community review. Known past contributors get flagged by name.
3. If no one from the community responds in a timely manner, we can offer that person to become a contributor if they have a history of contributing to Meltano and/or other open source projects. (We can use their GitHub history to help in this evaluation process.)
4. Any successfully-merged MR automatically promotes that person to "contributor", perhaps also to maintainer if they've consented in step 3 and no other maintainers exist.

As I've worked recently in tap-athena and target-athena, and other repos, I think we need to be more direct in our asks of community contributors. Everyone seems reluctant to take on responsibility so I think it is work considering pairing that responsibility with the review process itself - when they are most incentivized to agree (and get their manager's buy-in).

[pnadolny13]

In addition to expectations to get an existing connector added we should have some sort of review process for connectors built new from within MeltanoLabs, related to #2. After expectations are met we can remove the beta/experimental/under development flag from that repo.

[pnadolny13]

#4 addresses the majority of this issue. I'm going to close it and create a new issue specifically for permissions which wasn't explicitly addressed yet.