Change default code of conduct

[duncan-bayne]

Hi, firstly: thanks for Bundler. It's made Ruby development much easier and more enjoyable over the years, and I have the utmost respect and appreciation for everyone involved.

Secondly: thanks for including the option to include a code of conduct when generating a Gem. It's important to spell out exactly what behaviour is and isn't acceptable when dealing with other project members, and when representing the project itself. Tech in general has an inclusion problem, and a good CoC is one way of improving that.

However, the default CoC (contributor_covenant) you've picked has a significant issue; it can be used to censure project members for speech that is entirely outside the context of the project.

Some background: I opened a pull request to clarify the wording around project context. My motivation in opening that pull request was OpalGate. I wanted to make it clear that participation in a project that has adopted the contributor_covenant does not require contributors to self-censor their opinions outside of the context of the project. The maintainers of contributor_covenant have made it pretty clear that property of the covenant is by design.

I suggest that we either:

a) Replace the default contributor_covenant with a more clearly-scoped version (perhaps just a fork based off my pull request?).

b) Provide alternative codes of conduct during the generation of a Gem.

c) Break out the code of conduct generation into a separate library, which can itself contain a wide range of codes of conduct from which users can choose (my preferred option).

If people are interested in option (c) I'm happy to do the leg-work involved in setting things up.

[segiddins]

I don't think are likely to change this part of the bundle gem scaffolding, sorry.

[duncan-bayne]

Yeah, I can see how that'd be quite a bit of work, which is I'm offering to do most of the work myself, either by b) baking alternative CoC into the code, or c) writing an external CLI tool to allow the choice of a CoC and wiring that in.

[segiddins]

No, it's not the amount of work. We ourselves use the contributor covenant, so that's not going to change as the option for the generator. We also want to keep bundle gem simple, so we won't be adding additional options. As for c, the same thing applies -- bundle gem is a simple opinionated generator. You're more than welcome to use a tool like ore if you want more customization.

[duncan-bayne]

Okay, thanks for the clarification @segiddins.

It seems that the only option then would be a), and that would require either contributor_covenant to accept a PR clarifying the scope of project representation, or for someone to convince you (that is, the bundler project) to change covenant.

Unfortunately, contributor_covenant rejected my PR, which leads to the only remaining alternative being to convince you to switch to a different CoC, or perhaps a modded version of the contributor_covenant.

The reason I raised this was that I think that, as it stands, contributor_covenant is designed to enable behaviour such as @CoralineAda's request to have @elia dropped as a contributor to OpalRb. I don't agree with that behaviour (in fact, I think it constitutes abuse, albeit perhaps of a milder form than @CoralineAda herself received in response), and I don't think a CoC that enables abuse should accepted by the Ruby community.

But then I'm opinionated, too 😉

[segiddins]

No. Really the only option for us is to keep things as they are, since we've made a very conscience decision to use the contributor covenant and have zero plans of changing that. The attitude of "the only option bundler has" is really not friendly, and it seems that you're trying to kick up trouble here.

[duncan-bayne]

@segiddins I'm sorry to hear that. It's not my intent to start a fight. I was using bundler to create a Gem this morning, and noticed the contributor_covenant option. Given my already poor opinion of said covenant, I thought I'd raise an issue on bundler to discuss the possibility of replacing it.

Clearly that's not an option, so you may as well close the issue. Thanks for taking the time to explain your (that is, bundler's) position on the matter.