add contribution, governance guidelines

[ctb]

a few notes for things to document, not necessarily comprehensively...

• what is sourmash for (research platform as well as functional piece of software)
• who are the current maintainers
• who decides what gets merged and how (or, at least, the relatively informal arrangement we have now)
• guidelines on semantic versioning
• how to help steer the project towards your own priorities (by contributing code and documentation and use cases, by brainstorming on issues, by supporting contributions by consultants)
• how our current team works/our current set of regular contributors (broaden past current language, dib-lab)
• also, move to sourmash bio!

[luizirber]

Some more comments:

who are the current maintainers

And create a "maintainers" team to easily tag them (example from conda-forge: https://github.com/orgs/conda-forge/teams/core)

who decides what gets merged and how (or, at least, the relatively informal arrangement we have now)

We've been inconsistently tagging people, but a combination of requiring a review from the "maintainers" team + CODEOWNERS can help? Github tries to suggest possible reviewers from people that committed changes to the files being updated, but that doesn't necessarily reflect active or current contributors

guidelines on semantic versioning

655 has some of this

also, move to sourmash bio!

as a test, move luizirber/sourmash_cpp to sourmash bio and see how it goes (the repo is being used for tests in #661

Other candidates:

• sourmash_databases
• sourmash_resources

[ctb]

https://github.com/BurntSushi/ripgrep/blob/master/FAQ.md#release- For particularly common ones, like “when is the next release?", I declare that my free time is unscheduled. It helps to put it in a FAQ-like document.

[ctb]

note to self: for semantic versioning, I'd like to specify that people should use the CSV headers to read sourmash output files, b/c we may change the order of columns.

[ctb]

https://github.blog/2021-07-22-minimum-viable-governance-lightweight-community-structure-foss-projects/

[ctb]

should/could link to this: https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution

[ctb]

https://twitter.com/HowToOpenSource/status/1585355619900743680

via Research Computing Teams / jonathan dursi -

Almost all of diversity, equity, inclusion, and belonging work is hard, time-consuming people work. But, Riggins says, that doesn’t mean we can’t use some tooling to make that important work easier for open source maintainers:

Measure things, so you can use tools to track them over time - event diversity, who’s contributing, etc Use tools like GitHub Achievement Badges to incentivize the inclusive behaviour you want to see Use bots to promote inclusive language (several are listed) Have a strong code of conduct, and use some tools to help make it easier to nudge the behaviour you want to see (Drupal has been using this to good effect) Have a strong onboarding plan for new contributors, and use existing onboarding automation tools to support that

[ctb]

https://thenewstack.io/hacks-to-help-open-source-leadership-support-inclusion/