Update GOVERNANCE.md to better allow non-code maintainers

[youngnick]

Updates #20.

Also includes some other wording updates to modernize this document.

Signed-off-by: Nick Young ynick@vmware.com

[youngnick]

Thanks for the comments @stevesloka. I think we should discuss this one at the maintainer's meeting tomorrow. I'd ask that you have a think about what sort of governance you would like - how many levels should there be? What is the process to change levels? And so on.

The idea is not to make Contour maintainership hard, it's to make it easier to become a maintainer, so we can get more people interested in it.

[stevesloka]

Thanks for the comments @stevesloka. I think we should discuss this one at the maintainer's meeting tomorrow. I'd ask that you have a think about what sort of governance you would like - how many levels should there be? What is the process to change levels? And so on.

https://github.com/projectcontour/community/pull/23#discussion_r748542731

The idea is not to make Contour maintainership hard, it's to make it easier to become a maintainer, so we can get more people interested in it.

Yup I agree, but you need a way to get people interested first which has been the struggle. We need to be consistent with folks who do contribute regularly and to get them moved up into the proper roles. Here's a good thread on this recently: https://twitter.com/rakyll/status/1459623476201881602

[skriss]

I agree with the sentiment of defining some additional roles with specific responsibilities, rather than trying to shoehorn everything into a single "Maintainer" role. I think this would make expectations more clear, both for those looking to join the team, as well as for the existing team to make decisions about prospective new members. As a starting point I'd definitely be in favor of defining a "Community Manager" role and a "Docs Reviewer" or "Docs Maintainer" role.

[youngnick]

Thanks for the feedback everyone, I'll write up something a bit more comprehensive.

[tsaarni]

I think fine grained roles would typically be defined also to facilitate security, that is, to make it possible to give every role only the minimum required access to the systems that the project has. I guess that can be one viewpoint here too.

[jonasrosland]

After discussion with @caniszczyk the recommendation is to create something like "Doc Maintainers" or "SIG Docs" or "SIG Community Management" within our MAINTAINERS.md, that way the maintainers description can keep as is and we have more flexibility when we want to add more responsibility to awesome contributors.

[jonasrosland]

Example PR from Harbor: https://github.com/goharbor/community/pull/180

[xaleeks]

I like 'SIG Community Management'

[youngnick]

Yes, if we're planning for growth, establishing SIGs seems like a good idea.

[youngnick]

This has been superseded by #25. Closing.