Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial document for contributors #1

Merged
merged 3 commits into from
Nov 6, 2015
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 50 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
@@ -1 +1,51 @@
### Moya Contributors

##### Background

Moya started out as a project in Artsy under the ownership of [Ash Furrow](https://github.com/ashfurrow) and [Orta Therox](https://github.com/orta). Over time, developers from the community began using Moya and it is now a community-driven project.

After watching [The Social Coding Contract](http://blog.testdouble.com/posts/2014-12-02-the-social-coding-contract.html) we opted to find ways to make [the project](https://github.com/Moya/Moya/issues/135) more welcoming to external contributors.

This document tries to clarify how we can include as many people as possible within the project.

#### How to get push access?

If you get a merged PR, regardless of content (typos, code, doc fixes) then you're eligible for push access to the Moya organization. We check for this on PR merges and extend an invite via GitHub.

Offhand, it's easy to imagine that this would make code quality suffer, but in reality it offers fresh perspectives to the codebase and encourages ownership from people who are depending on the project.

Everyone comes in with their own perspective on what a project could/should look like, and encouraging discussion can help expose good ideas sooner.

#### When should you use push access?

It can be overwhelming to suddenly be offered the chance to wipe the source code for a project. Don't worry, we don't let you push to master.

All code is peer-reviewed, and we have the convention that someone other than the submitter should merge the pull request.

As an org contributor you can merge other people's pull requests, or other contributors can merge yours. You won't be assigned a pull request, but you're welcome to just jump in and take a code review on things that interest you.

If it feels right, merge. Moya is not continuously deployed, there is space for debate after too. Offering the chance to revert, or make an amending pull request.

It's convention to provide a call to action [via](https://github.com/Moya/Moya/pull/273) `/cc @Moya/contributors` to invite discussion.

#### How can we help you get comfortable contributing?

It's normal for a first PR to be a potential fix for a problem, moving on from there to helping the project's direction can be difficult. We try to help contributors cross that barrier by offering [good first step](https://github.com/Moya/Moya/labels/good%20first%20step) issues. These issues can be done without feeling like you're stepping on toes. Ideally, these are non-critical issues that are well defined.

We keep all project discussion inside GitHub issues. If you have questions about how to use the library, or how the project is running GitHub issues are the [goto tool](https://github.com/Moya/Moya/issues/new).

We have our own [Code of Conduct](https://github.com/Moya/code-of-conduct), which is adapted from the [Contributor Covenant](http://contributor-covenant.org), version 1.2.0, available at [http://contributor-covenant.org/version/1/2/0/](http://contributor-covenant.org/version/1/2/0/). The CoC is taken seriously by the project owners.

#### Our expectations on you as a contributor

To quote [@alloy](https://github.com/alloy) from [this issue](https://github.com/Moya/Moya/issues/135):

> Don't ever feel bad for not contributing to open source.

We want contributors to both provide ideas, keep the ship shipping and to take some of the load from others. It is non-obligatory; we're here to have fun. :trophy:

If someone submits a pull request that's not perfect, it's better to think about the PR's motivation rather than the specific implementation. Having braces on the wrong line should not be a blocker for example. Though we do want to keep test coverage high, we will work with you to [figure that out together](https://github.com/ashfurrow/Nimble-Snapshots/pull/37).

#### What about if you have problems that cannot be put into a public issue?

Both [Ash Furrow](https://github.com/ashfurrow) and [Orta Therox](https://github.com/orta) have contactable emails on their GitHub profiles, and are happy to talk about any problems.