Moya started out as a project in Artsy under the ownership of Ash Furrow and Orta Therox. Over time, developers from the community began using Moya and it became a community-driven project.
After watching The Social Coding Contract we looked to find ways to make the project more welcoming to external contributors.
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.
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.
- 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.
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.
We use a Code of Conduct, which is adapted from the Contributor Covenant, version 1.3.0, available at http://contributor-covenant.org/version/1/3/0/. The CoC is taken seriously by the project owners.
Both Ash Furrow and Orta Therox have contactable emails on their GitHub profiles, and are happy to talk about any problems.