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

add code of conduct when scaffolding a gem #3305

Merged
merged 1 commit into from Dec 13, 2014

Conversation

Projects
None yet
@doodzik
Contributor

doodzik commented Dec 13, 2014

Adding a code of conduct to every newly created gem in order build an even better ruby community :)

http://contributor-covenant.org/version/1/0/0/code_of_conduct.md

@simi

This comment has been minimized.

Contributor

simi commented Dec 13, 2014

👎

If anyone wants to merge this, it will be nice to make it optional or at least make it configurable, so I can't set this config once and don't care about it anymore.

@doodzik

This comment has been minimized.

Contributor

doodzik commented Dec 13, 2014

What should the option be called?
Why should it be opt-in/opt-out?

@simi

This comment has been minimized.

Contributor

simi commented Dec 13, 2014

Just IMHO code of conduct is not building better community. Actually it works in opposite way for me.

@doodzik

This comment has been minimized.

Contributor

doodzik commented Dec 13, 2014

can you elaborate your thought further?

@simi

This comment has been minimized.

Contributor

simi commented Dec 13, 2014

Nope. All I need is to make this configurable so I can skip this.

If you want to know my opinion about COCs, ping me via email or twitter direct message.

@doodzik

This comment has been minimized.

Contributor

doodzik commented Dec 13, 2014

ok 👍
Would COC/coc/--no-coc be an appropriate name for this option?

@simi

This comment has been minimized.

Contributor

simi commented Dec 13, 2014

Yup. It will be nice to make ti configurable via global bundle config.

@indirect

This comment has been minimized.

Member

indirect commented Dec 13, 2014

@simi Bundler itself has a code of conduct. If that's a problem for you, this is probably the wrong project to be contributing to. :)

@databus23 This pull sets a good example by adding a code of conduct to new gems, and I'm strongly in support of that. 👍 It's also made me realize that the Bundler code of conduct isn't clearly linked from the files in the repo itself, so I'm going to be adding one of these to the Bundler repo as well. Thanks!

indirect added a commit that referenced this pull request Dec 13, 2014

Merge pull request #3305 from doodzik/master
add code of conduct when scaffolding a gem

@indirect indirect merged commit 8677640 into bundler:master Dec 13, 2014

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details
@TimMoore

This comment has been minimized.

Member

TimMoore commented Dec 13, 2014

Thank you, @doodzik!

@simi

This comment has been minimized.

Contributor

simi commented Dec 14, 2014

Actually COC is not problem for me. I just don't want it in my gems. Will be PR with config flag disabled by default merged @indirect ?

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by opening an issue or contacting one or more of the project maintainers.
This Code of Conduct is adapted from the [Contributor Covenant](http:contributor-covenant.org), version 1.0.0, available at [http://contributor-covenant.org/version/1/0/0/](http://contributor-covenant.org/version/1/0/0/)

This comment has been minimized.

@schneems

schneems Dec 14, 2014

Contributor

Missing // in the link after http:

This comment has been minimized.

@zzak

zzak Dec 14, 2014

Member

Thank you! Fixed in b5f41d5

@TimMoore

This comment has been minimized.

Member

TimMoore commented Dec 14, 2014

If it were disabled by default that would defeat the whole purpose IMHO.

@simi

This comment has been minimized.

Contributor

simi commented Dec 15, 2014

It can be enabled by default. I just want to be able to disable it via bundle config --global.

@ashedryden

This comment has been minimized.

ashedryden commented Dec 15, 2014

Hate to be the bearer of bad news once this is already merged in, but:

Including a CoC that a projector maintainer may not honor or enforce is dangerous :( If someone does something violating the CoC, I should be able to go to the maintainers to report and have something done about it. If they aren't all on board for enforcing (and in agreement on how to enforce), the CoC means nothing :(

@binarycleric

This comment has been minimized.

binarycleric commented Dec 15, 2014

👍 To @ashedryden's comment.

I worry that developers won't understand or enforce what is included in their CoC. While I agree that projects having them is a good thing, having a CoC that is unenforced and ignored by the maintainer is dangerous.

@olivvv

This comment has been minimized.

olivvv commented Dec 15, 2014

Are culture and origin missing from the list ?

@eaton

This comment has been minimized.

eaton commented Dec 15, 2014

Thirding @ashedryden's comment. In the Drupal community, we put together a CoC but commitment to enforce (rather than hedging and simply diffusing uncomfortable situations) took time.

The danger of a fuzzily-enforced CoC is nontrivial: without any malicious intent, things drift towards leniency for members of any in crowd and strict consequences for lesser-known newcomers.

@CoralineAda

This comment has been minimized.

Contributor

CoralineAda commented Dec 15, 2014

I see it this way: behaving according to community standards is the value that is promoted by default. Varying from that standard is a deliberate act signaled by the deletion of the CoC.

@indirect

This comment has been minimized.

Member

indirect commented Dec 15, 2014

@ashedryden that's a really good point. We had a similar discussion around the LICENSE file, and eventually concluded that we wanted to use the default to establish the norm while letting people easily opt out by removing the file. I was hoping that including a CoC would similarly help establish a norm, but it's a very good point that a CoC that isn't actively backed by the project owner is dangerously misleading.

We already have opt-in testing files, so I think the solution is probably to add a --coc option to the gem command. I don't want to water down the value of seeing that a project has a CoC in the repo.

In the interests of establishing norms, how do you all feel about a first-run prompt that asks if you will enforce the code of conduct in your projects?

@CoralineAda

This comment has been minimized.

Contributor

CoralineAda commented Dec 15, 2014

@indirect I think that the first-run prompt is a good way forward.

@ashedryden

This comment has been minimized.

ashedryden commented Dec 15, 2014

@indirect I definitely agree that it brings a lot of value and removes that first hurdle for people which is great and not to be discounted <3

I do think it should be opt in only, for the reason I stated before. I think it'd be great if it also gave info (links even are fine) to enforcement information. The GFW has some great resources on that: http://geekfeminism.wikia.com/wiki/Conference_anti-harassment/Responding_to_reports

I think bundler is doing a great thing by putting this in there and encouraging its use; I just don't wanna see that effort marred by included-by-default-I-didnt-know-it-was-there kind of shenanigans.

@CoralineAda

This comment has been minimized.

Contributor

CoralineAda commented Dec 15, 2014

@ashedryden, is the enforcement section on Contributor Covenant not sufficient? If not, we should revise that. https://github.com/CoralineAda/contributor_covenant/blob/gh-pages/version/1/0/0/code_of_conduct.txt

@ashedryden

This comment has been minimized.

ashedryden commented Dec 15, 2014

@CoralineAda The section lists possible ramifications of unacceptable behavior, but not how to take reports and determine such ramifications, which the link I shared details.

@indirect

This comment has been minimized.

Member

indirect commented Dec 15, 2014

@CoralineAda I'll take a look at the difference between Bundler's CoC and the CC 1.0, and send a pull request if it seems like the teeth branch could use expansion.

@ashedryden I haven't written it yet, but the first-run prompt will include an explanation of what opting in means, and link to (at a minimum) the GF wiki page about enforcement.

This thread has been really helpful at calling out the difference between "cultural norm" and "default thing that was generated without my knowledge or consent". On reflection, I think it's a bad idea to default people into anything without their agreement. I plan to change the way the gem command works for the next release in these ways:

  • remove all silently generated CoC, license, and other files that affect rights or relationships
  • add config settings and runtime flags to allow enabling them once or for all generated gems
  • add first-run questions around CoC, license, and any other files that explicitly state what will be added, how that will change the rights or responsibilities of the gem author, and what the desired community norms are, but that requires explicit opt-in at the time to enable each thing

Right now, I feel like the best option is to let people know that adding a CoC means they need to know what it says, know what violates it, and be ready to enforce the CoC on any contributors including themselves. But I also want to let them know that it will lower barriers to entry, and encourage them to knowingly add it, as long as they are willing to commit to it.

Overall, I think this will definitely improve the experience of generating a gem. Thanks for the feedback, everyone.

@doodzik

This comment has been minimized.

Contributor

doodzik commented Dec 15, 2014

👍

@ashedryden

This comment has been minimized.

ashedryden commented Dec 15, 2014

💯 Good job, team :)

@indirect

This comment has been minimized.

Member

indirect commented Dec 15, 2014

For those playing along at home (or looking for ways to contribute to Bundler! 😁) there's a Trello card with a checklist for these changes located at https://trello.com/c/1349U0gF. I'm happy to merge a pull request implementing the changes listed, or make the changes myself as soon as I have time.

No matter who implements it, the CoC template won't ship until these changes are complete.

@TimMoore

This comment has been minimized.

Member

TimMoore commented Dec 15, 2014

This has been a really great discussion... thanks to everyone that has contributed to help get this right and particularly @ashedryden for pointing out the non-obvious danger if we do this naively.

@indirect should we revert the merge in the meantime?

@indirect

This comment has been minimized.

Member

indirect commented Dec 15, 2014

@TimMoore yeah, let's revert this merge commit, pending implementation of the opt-in semantics.

TimMoore added a commit that referenced this pull request Dec 15, 2014

Revert "Merge pull request #3305 from doodzik/master"
This reverts commit 8677640, reversing
changes made to edcfb57.

Conflicts:
	lib/bundler/templates/newgem/CODE_OF_CONDUCT.md.tt

This follows further discussion in
#3305 where it was pointed out
that adding this to gems without the maintainers' explicit consent and
committment to enforcement is dangerous and counter-productive.

A more thorough approach is planned in https://trello.com/c/1349U0gF
@simi

This comment has been minimized.

Contributor

simi commented Dec 16, 2014

Thanks all for great discussion. I'll prepare changes in code.

kirs added a commit to kirs/bundler that referenced this pull request Dec 17, 2014

Extended gem generation and generation settings
As discussed in bundler#3305 (comment), the gem generator should not generate default files that change the rights or responsibilities of gem authors without their explicit consent. Let's change the gem generator to ask gem authors what they want, and allow them to change it via config or --flags.

* Remove LICENSE from default gem
* Remove CODE_OF_CONDUCT from default gem
* Add --coc flag to generate CODE_OF_CONDUCT
* Add --mit flag to generate LICENSE
* On gem generation, if not set to true/false, ask user if they are willing to license their code permissively under the MIT license
* On gem generation, if not set to true/false, ask user if they are willing to add a Code of Conduct to their gem
* On gem generation, if not set to false/rspec/minitest, ask if the user would like to generate tests along with their gems. Save the answer as bundle config gem.tests.
* Ensure that --coc, --mit, --test flags overrule any config settings that may be set.

kirs added a commit to kirs/bundler that referenced this pull request Dec 17, 2014

Extended gem generation and generation settings
As discussed in bundler#3305 (comment), the gem generator should not generate default files that change the rights or responsibilities of gem authors without their explicit consent. Let's change the gem generator to ask gem authors what they want, and allow them to change it via config or --flags.

* Remove LICENSE from default gem
* Remove CODE_OF_CONDUCT from default gem
* Add --coc flag to generate CODE_OF_CONDUCT
* Add --mit flag to generate LICENSE
* On gem generation, if not set to true/false, ask user if they are willing to license their code permissively under the MIT license
* On gem generation, if not set to true/false, ask user if they are willing to add a Code of Conduct to their gem
* On gem generation, if not set to false/rspec/minitest, ask if the user would like to generate tests along with their gems. Save the answer as bundle config gem.tests.
* Ensure that --coc, --mit, --test flags overrule any config settings that may be set.

indirect added a commit that referenced this pull request Jan 26, 2015

Extended gem generation and generation settings
As discussed in #3305 (comment), the gem generator should not generate default files that change the rights or responsibilities of gem authors without their explicit consent. Let's change the gem generator to ask gem authors what they want, and allow them to change it via config or --flags.

* Remove LICENSE from default gem
* Remove CODE_OF_CONDUCT from default gem
* Add --coc flag to generate CODE_OF_CONDUCT
* Add --mit flag to generate LICENSE
* On gem generation, if not set to true/false, ask user if they are willing to license their code permissively under the MIT license
* On gem generation, if not set to true/false, ask user if they are willing to add a Code of Conduct to their gem
* On gem generation, if not set to false/rspec/minitest, ask if the user would like to generate tests along with their gems. Save the answer as bundle config gem.tests.
* Ensure that --coc, --mit, --test flags overrule any config settings that may be set.

indirect added a commit that referenced this pull request Jan 26, 2015

Extended gem generation and generation settings
As discussed in #3305 (comment), the gem generator should not generate default files that change the rights or responsibilities of gem authors without their explicit consent. Let's change the gem generator to ask gem authors what they want, and allow them to change it via config or --flags.

* Remove LICENSE from default gem
* Remove CODE_OF_CONDUCT from default gem
* Add --coc flag to generate CODE_OF_CONDUCT
* Add --mit flag to generate LICENSE
* On gem generation, if not set to true/false, ask user if they are willing to license their code permissively under the MIT license
* On gem generation, if not set to true/false, ask user if they are willing to add a Code of Conduct to their gem
* On gem generation, if not set to false/rspec/minitest, ask if the user would like to generate tests along with their gems. Save the answer as bundle config gem.tests.
* Ensure that --coc, --mit, --test flags overrule any config settings that may be set.

@lynncyrin lynncyrin modified the milestone: Release Archive Oct 9, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment