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

New code of conduct #14053

Closed
vitorgalvao opened this issue Sep 28, 2015 · 13 comments
Closed

New code of conduct #14053

vitorgalvao opened this issue Sep 28, 2015 · 13 comments

Comments

@vitorgalvao
Copy link
Member

From #8378 (comment):

I haven’t been following the evolution of the contributor covenant, but I’d say it’s probably best to not update it here, and come up with our own version. My concerns about it are roughly the same, except now @ndr-qef’s thoughts and proposals have been ignored for even longer.

@ndr-qef I’d love to see our code of conduct updated by you without worrying about ties to other CoCs; just carte blanche (no pressure intended) on all your concerns and opinions of what a good one should be (we could work on wording and length later).

I’d like for us to have a better code of conduct than what we currently do. Ideally, @ndr-qef could write us one that addressed all of his concerns, but if someone can write one that fixes all the problems he identified, that’d be fine too.

@maxnordlund
Copy link
Contributor

Some other resources to use as inspiration/foundation include:

@vitorgalvao
Copy link
Member Author

Thank you @maxnordlund, big thumbs up to that. Will have a read.

@fanquake fanquake added the documentation Issue regarding documentation. label Oct 1, 2015
@dardo82
Copy link
Contributor

dardo82 commented Oct 3, 2015

Are those resources mixable? I think and hope not!

@vitorgalvao
Copy link
Member Author

@dardo82 What do you mean? The idea is to write a new code of conduct, and do so by not forgetting good ideas from existing ones, not just jumble existing ones together.

@dardo82
Copy link
Contributor

dardo82 commented Oct 3, 2015

Some choices are needed then...

@vitorgalvao
Copy link
Member Author

@ndr-qef Are you interested in pursuing this? If not, we’ll default to the contributor covenant again (updated to the latest version). Apple’s adoption of it for Swift development should bring with it some needed attention, and if there are holes that manifest, they should show up more readily.

@tapeinosyne
Copy link
Contributor

My suggestions are unfortunately immaterial without validation from competent community figures. I agree that the best solution is adopting a standard CoC, which has the immediate benefit of being established and familiar.

@phinze
Copy link
Contributor

phinze commented Feb 22, 2016

Hi folks!

I ended up swinging around to our CoC just now due to some activity in another thread, realized it was a bit old, and found my way here.

Some great clarifying work has been done in the latest version (1.4) of the Contributor Covenant - work that has drawn praise from critics of certain details in prior versions.

There has also been a bunch of work done compiling reasons enforcement language is important to a CoC, which was one of the issues in question over in EthicalSource/contributor_covenant#17.

Might we be able to build consensus amongst @caskroom/maintainers for an update to Contributor Covenant v1.4?

@adidalal
Copy link
Contributor

Pretty impartial to a code of conduct. I get why it's there, but... - my gut feeling is "be excellent to others" and "give people the benefit of the doubt". Generally I'll just lock unproductive discussions, and I'm not (personally) willing to do any further enforcement - it just doesn't seem to be a fruitful use of my time.

That being said, I try to be fairly polite in comments and PRs, and if this is just a codification of that, sure, why not.

@phinze
Copy link
Contributor

phinze commented Feb 22, 2016

(FWIW - though I'm off the day-to-day project work nowadays, I'd happily volunteer to help run the CoC reporting pipeline.)

@vitorgalvao
Copy link
Member Author

@phinze I had been thinking about this for a while and think its an acceptable idea.

The reason I haven’t done so yet is due to their paragraph regarding where to report CoC violations. We’re all volunteers and don’t have an HR department. My initial reaction has always been to put my email there, but what if the reporter has an issue with me? This will always an issue to a degree, but the person reviewing the cases can’t be someone that can be a trigger for a complaint. On the other hand, the person reviewing needs to be someone that actually interacts with the community, to be an effective judge.

A possible solution would be to include multiple email addresses. If you have an issue with one maintainer, contact another. I didn’t yet have the opportunity to discuss that with the rest of the team, however.

Another issue, and I want to be clear I’m not in the “CoCs are useless” camp, is that I don’t actually think the CoC would be a good tool to solve the kinds of issues we face where it would actually be applicable.

We have very few situations where a user is disrespectful, and so far those have come always from users that present an entitled attitude towards the homebrew-cask team and/or our contributors, have never before contributed to or even interacted in issues in homebrew-cask, and generally have a short github contributions graph. What this means is the type of users with a bad attitude we find are the ones making demands from people working for free, while likely not having much of an idea of what that means firsthand. I argue those users won’t know or care about CoCs, because it won’t affect them either way.

On to us (and myself specifically). As you know, though I always write with good intentions, my tone could (and I say that proudly, instead of “can”1) be disproportionately harsh. That, I believe, stopped being the case a long while ago, even before I took the reins of the project. Like @adidalal2, I believe in always assuming what others wrote was done so with the best of intentions (doing so helps clear ambiguous situations for the best) and in never being disrespectful in replies. That doesn’t mean we can’t be stern and assertive, though, and I find it best to do so in cases where the aforementioned entitled users are concerned.

This is where CoCs might be a false crutch to lean on. I’ve seen Apple’s Swift team closing an issue with something like “this doesn’t adhere to our CoC”, and that is, to an extent, a cop-out that doesn’t address the issue (I’m saying this in general, and not necessarily leaning on that particular case). To me, telling the user exactly why their attitude is unacceptable is much more honest. Many of them act like (and sometimes even outright say) they’ll “go somewhere else” as a threat, like if that were significant or even made sense (remember, these are users that never contributed, even in discussions), and I have no issue with them leaving. On the contrary, I appreciate it! Burnout is a real issue and I don’t want it happening to me or the rest of the team. Again, though, I still try to never be disrespectful to them, and if an occasional more abrasive line is to slip through in the heat of the moment (perhaps because I’m replying on a phone and can’t easily reread everything in context), I’m quickly to fix that. I’m fortunate to know other members of the team read most issues, and they’ll give needed feedback if required3.

Other maintainers have the same attitude and try to be as welcoming as possible. When a user comes in from nowhere (i.e. an unknown to the project) guns blazing making demands and one-sided arguments (usually very wrong because they didn’t bother to ask or look for context or reasonings), though, then all bets are off and they will be asked to leave.

Basically, in a huge wall of text and some context regarding our usual problematic cases, I agree with @adidalal completely.


1 No one is flawless, so eventually a “can” might be the case, but those are few and further apart as time passes.

2 Which is one of the nicest, most polite maintainers I’ve ever seen, in any project. I say “maintainer” but not even that is needed. Even before he was a maintainer with us he was already incredibly helpful and courteous to other users. Definitely one of the reasons that compelled me to invite him to the project.

3 I recall a specific incident when after my reply to a user that had directly insulted a member of the team and a contributor, even though I tried to be as calm as possible in my reply, I wasn’t sure if I had accomplished that, but got positive feedback on it even without requesting it, which was reassuring.

@maxnordlund
Copy link
Contributor

@vitorgalvao lovely wall of text, very informative, and I agree/recognize myself on pretty much everything. I too have come across as harsh not to long ago, but that got resolved quickly.

One thing that may elude people, is that the CoC also acts as a way for those that don't conform to the norm to feel accepted. Even though you don't treat contributors differently, for those on the outside, so to speak, might not be willing to take the risk if there aren't a clear stance of what is acceptable or not.

This is especially hard to comprehend for those within the norm, as it isn't something you think about in general, hence the term norm. Hell, I make so many assumptions every day, and hope that they aren't wrong. Most of the time they aren't, but the times they are, it really stings.

@vitorgalvao
Copy link
Member Author

Closed by #19152.

@maxnordlund Thank you for the feedback, it’s always good to know when a wall of text was enjoyable and not a waste. Also, I completely see your point:

the CoC also acts as a way for those that don't conform to the norm to feel accepted.

And agree that is a worthwhile goal/reason to have it. Like you said, we don’t treat contributors differently (as long as everyone is amicable), but there’s really no way for a newcomer to know that.

This is especially hard to comprehend for those within the norm

Very much agreed, as well.

@miccal miccal removed documentation Issue regarding documentation. meta labels Dec 23, 2016
@Homebrew Homebrew locked and limited conversation to collaborators May 8, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants