Adding maintainer responsibilities, off-boarding, and emeritus governance docs

[aburdenthehand]

1. Adding maintainer responsibilities, since we mention this as part of our selection criteria.
2. Also adding off-boarding/retiring expectations for maintainers, something we've been talking about throughout the year but never put into our docs. It is also a part of CNCF graduation criteria, so let's put it into our docs.
3. Also also adding an opening para that links to our membership policy, to make that more obvious for anyone looking for that info in our governance doc. This is mirrored by adding project maintainers to our contribution ladder in the membership policy, linking back to governance, and to our maintainers file.

Fixes #311

As per our governance, this requires a 2/3 vote of maintainers to update.
/cc @fabiand @davidvossel @rthallisey @rmohr @vasiliy-ul @vladikr @stu-gott

Release note:

Adding responsibilities and offboarding expectations for maintainers

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from aburdenthehand. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[vladikr]

Thanks @aburdenthehand
We discussed this offline as well.
/lgtm

[kubevirt-bot]

Pull requests that are marked with lgtm should receive a review
from an approver within 1 week.

After that period the bot marks them with the label needs-approver-review.

/label needs-approver-review

[iholder101]

Thanks @aburdenthehand!
Looks great to me. Left some nits.

/lgtm

[iholder101]

Can you please add links here?

[iholder101]

WDYT about:

• Heavily involved in the project's hottest topics, like Enhancement Proposals, important PRs and code-reviews, organizational changes, etc

My point is that a maintainer should be heavily involved, present and visible in the project. Does that make sense?

[iholder101]

Perhaps we could add something like: "Although requiring a vote by maintainer, it should be much easier for an emeritus maintainer to return becoming a maintainer"?