Moya Community Continuity Guidelines v2.0.0
Because of this, we created the v1 Moya Community document - over time the ideas have spread to more projects. This eventually lead to the creation of a more easily applicable template.
This repo contains a document Contributing.md which is a template for others to help foster their own communities. Think of it as a code of conduct for the continuity of your community.
I want to apply these guidelines
Great! So, this is not quite another file to copy & paste into your project. It's slightly more involved.
It's not too many steps though, and the majority of them are common sense things you would do anyway.
Copy the file
Contributing.mdinto your repo.
Change the bottom paragraph to show how people can contact organizers privately
Ensure that it makes sense when the guidelines talk about the project not being continuously deployed. If it doesn't make sense, remove it.
- For example, in a library, you have to deploy to a package manager. This means there is always a chance for cleanup and final reviews before a release.
Lock the master branch, to ensure code review as the way to get code in. Even for admins. Everyone plays by the rules.
Ensure there is a label for people to find easy issues with. We strongly recommend you use a label name from one of this set in order to be involved with the larger ecosystem.
And you're good.
In our opinion, you're also welcome to add some flourish at the top about why you want to work this way. This is not a legal document, and doesn't aim to be, offering insight into why you choose to work this way can make the document a nicer read.
Useful Bits of information for project owners
- Danger is a project that can be used during CI that can check to see if someone is inside an organization, making it possible to ask if they would like to be invited.
- We believe so firmly in these community guidelines that we have automated them.
- The Jekyll Project has some great documentation around being a maintainer, and avoiding burnout.
- The Jekyll's maintainer documentation is based on Homebrew's.
- CocoaPods has a Communication & Design Rules which provides advice for project maintainers.
I want to improve the Community Continuity Guidelines
Great, so do we. Feedback in issues is a great way to work, as is pull requests improving our wording. This is an evolving document, so we'll be trying to apply Semantic Versioning to it.
We consider extra guidelines as being major releases, tweaks to existing rules as minors, and depending on other wording changes - patches. We'll be using our best judgement as we can.