docs(maintainer): add maintainer governance docs

[d33bs]

Description

This PR adds documentation covering project roles and how to become a maintainer.

Closes #328

What is the nature of your change?

• Bug fix (fixes an issue).
• Enhancement (adds functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as expected).
• This change requires a documentation update.

Checklist

Please ensure that all boxes are checked before indicating that a pull request is ready for review.

• I have read the CONTRIBUTING.md guidelines.
• My code follows the style guidelines of this project.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• New and existing unit tests pass locally with my changes.
• I have added tests that prove my fix is effective or that my feature works.
• I have deleted all non-relevant text in this pull request template.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.39%. Comparing base (b558b39) to head (a16da19).
Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #487      +/-   ##
==========================================
- Coverage   94.74%   94.39%   -0.35%     
==========================================
  Files          57       57              
  Lines        3156     3159       +3     
==========================================
- Hits         2990     2982       -8     
- Misses        166      177      +11     

Flag	Coverage Δ
unittests	94.39% <ø> (-0.35%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[gwaybio]

I like the language additions here. I wonder if we should include a maintainer offboarding process as well.

I imagine this would be a voluntary decision, but are there any other scenarios that we should delineate for offboarding?

[d33bs]

Thanks @gwaybio ! Good thoughts on adding an offboarding process. I imagine you're correct - that this would usually be a voluntary process. While a bit dark, another scenario might be if we know someone has passed away (we might want to demote the account to help avoid unwanted activity should their account be hijacked).

We could get more thorough here and think through if we want to remove maintainers based on inactivity, but I don't know how to make that process fair and useful at this time. PEP 13 highlights an ejection process that might be helpful; maybe we could adopt something like this to be on the safe side (two-thirds vote to eject from other existing maintainers means involuntary offboarding of maintainer status within Pycytominer). We could peel this off into another issue for further discussion. Thoughts?

[d33bs]

Thanks Greg! Going to merge this in for now, added an issue to explore further cases where we might want to offboard a maintainer.