[v2] Initial stab a separating into a Community Continuity Guidelines

[orta]

Fixes #6

---

OK, so, long time coming - thanks @paulofaria for our conversations recently.

This splits out the README into the "moya/contributors README" and the Community.md file. The idea being that the README shows you how to get up and running, the Community.md is what you take into your own project and modify to your specifics.

I'll be running through this for Danger, and the CocoaPods app ( both of which have different approaches to how this can be tackled ) before I can start to expand it further

@ashfurrow I want you to run through this for Moya/Moya - it's an oddity, but I think it makes sense. Plus having someone else run through the process will be helpful.

I think I'd advocate for renaming this repo to community-continuity too once this is merged and we've settled on what v2 is.

---

/cc @dbgrandi @ashfurrow @paulofaria @krausefx @segiddins @AliSoftware - would love feedback

What I'd like is focus on the new Community.md which should feel reasonable in any project's repo.

[AliSoftware]

Side question, is there a way to automate the fact that a contributor is automatically given push access when the PR is merged?

It would also be cool to have a message to be automatically sent to thank them and explain that we granted them push access and what this means for them (e.g. no special expectation from them to give more time on the project — I've seen people refusing the push access because their thought I expected them to be the next co-maintainer or something) + a link to the Community.md. That would probably be better achieved with the new "Saved Reply" feature of GitHub (rather than making a bot post that message for us) because a bot is less personal and posting that ourselves is more welcoming and would feel less robotic, but would still be nice to have a template for this kind of canned response, right?

[orta]

Side question, is there a way to automate the fact that a contributor is automatically given push access when the PR is merged?

Danger as a web service could pull this off, for now the best option is to have checks like we have in Danger herself.

Agreed, we should provide advice on both using the Danger org check and a template for saved replies.

[orta]

Everyone, thanks, I've agreed with all feedback, and made changes accordingly.

@dbgrandi - for now, I'm ok with it being GitHub specific (much as it pains me) there's a lot of GH specific terminology in here ( issues/ PR/ orgs) that could be cleaned up in another version at some point.

For now it might make it more abstract and harder to grok overall.

@AliSoftware would linking to this section help now? https://github.com/Moya/contributors/blob/v2/Community.md#our-expectations-on-you-as-a-contributor

[ashfurrow]

The Contributor Covenant guidelines have an "attribution" note at the bottom linking back to them, making it easier for others to follow suit. Do you think having something similar pointing to this repo in Community.md makes sense?

[orta]

Do you think having something similar pointing to this repo in Community.md makes sense?

Yes

[AliSoftware]

@AliSoftware would linking to this section help now? > https://github.com/Moya/contributors/blob/v2/Community.md#our-expectations-on-you-as-a-contributor

Indeed :+1:

[AliSoftware]

Any reason why the file is not called Contributing.md?

I mean, I like that it's spelled lowercase instead of shouting-at-you-case 👍 but still as the common standard in OSS platforms like GitHub is to call the file serving exactly for this purpose (of explaining how it works for contributors) CONTRIBUTING.md, even if we prefer lowercase. At least keeping the name would help discoverability of that file/documentation, right?

[orta]

I think contributing.md has a different scope, as it's aimed at people writing issues and minutae for getting things working

https://github.com/CocoaPods/CocoaPods/blob/master/CONTRIBUTING.md https://github.com/realm/jazzy/blob/master/CONTRIBUTING.md https://github.com/rails/rails/blob/master/CONTRIBUTING.md#how-to-contribute-to-ruby-on-rails https://github.com/sinatra/sinatra/blob/master/CONTRIBUTING.md https://github.com/npm/npm/blob/master/CONTRIBUTING.md

whereas this is more about explaining how you're going to encourage people to stay

[orta]

Given this a third run through, think it's pretty good to go.

[ashfurrow]

Will run through this one last time, apply to Moya, and report back.

[ashfurrow]

Got some time this afternoon, gonna prioritize this.

[ashfurrow]

I feel like maybe the adoption steps should discuss how to reference the document from the readme and in conversations.

[orta]

Could get some ideas from https://github.com/jekyll/jekyll/pull/5011 too

[orta]

Alright, I'm calling this 👍

💇