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

Remove abuse enabling language pt. 3 #2696

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

@hmdne
Copy link
Contributor

@hmdne hmdne commented Oct 1, 2021

I joined the Ruby-Talk mailing list a few months ago. It is a very
slowly moving medium, mostly focused on a show-and-tell and newbie
questions. This list is used by two groups of people, hobbyists and
professionals. I am rather a member of a second group and in my
messages I tried to be as civil as possible. But hobbyists may not
share that trait with us, not due to a malice, but rather due to
a fact, that... many of them are young.

I am generalizing somewhat, I know. I am a hobbyist too and Ruby is
one of the most fun environments I have gotten to know. I just tried
to describe my observation. And if I'm right in my observation,
removing the young people may ultimately result in Ruby community
slowly withering out and dying.

In my life experience I have gotten to know two methods of governance.
One is to "encourage" everyone to act civil, other is to "enforce"
everyone to do so. While I understand that it's not binary and
sometimes you need to "enforce", I am a strong proponent of the
"encouragement" stance whenever possible for a single reason that it
produces less tensions.

Politics are heated. That's a fact. Everyone has their own opinion
and each opinion is the best. You can't encourage the other side that
their opinion is wrong, but you will still attempt to. Why is that so?
We all live in different worlds, we all have different observations.
We read different media, we care about different things. It doesn't
matter - it will probably never end up in an agreement but will
devolve into lengthy and lengthy conversations, most of which will be
ultimately fruitless.

The conversation in question we had was exactly an example of that,
about 50 posts of a heated debate (which is a lot of traffic for this
ML). Do we want such debates to take place on Ruby-Talk or other core
Ruby communities?

In this PR I suggest reverting both #2690 and #2691 and introducing
a clause:

 * Participants will do their best to not start or advance political or otherwise divisive conversations.

It is intentionally worded in a non-enforcing way. Sometimes a really
pushing problem happens. But this point will make sure that members of
the community will consider to back off from absolutely trying to show
their opinion.

Here I would also want to take an opportunity to appologize to
@jacobherrington if he felt that he was personally attacked by my
actions - that was not my intention. I happen to disagree with some of
your opinions, agree with some. But let's leave it at that. If everyone
agreed with everyone else, the world would be extremely boring. At
least we can all agree that Ruby is cool.

References: #2693, #2695.

@hmdne hmdne requested a review from as a code owner Oct 1, 2021
@@ -9,7 +9,9 @@ You should follow these guidelines when posting to the ruby-talk mailing list.


1. **Always** be friendly, considerate, tactful, and tasteful. We want to
keep this list hospitable and safe for everyone.
keep this list hospitable to the growing ranks of newbies, very
young people, and their teachers, as well as cater to fire breathing

s/their/the/, at least. :)

Copy link
Contributor Author

@hmdne hmdne Oct 1, 2021

Thanks, but this part is just a revert :D. Do you think I should amend it? I think it may go to a separate PR...

"s/their/the" usage makes reading more difficult for non natives english readers and for reading software (used by people with vision problems)

@martindemello
Copy link

@martindemello martindemello commented Oct 1, 2021

To tie this back to the current, concrete issue, which of these would you consider "political and divisive":

  1. making a sexist joke or remark
  2. asking whoever made the remark to not do it again and explaining why it makes the list less welcoming for women
  3. assuming whoever made the remark had good intentions and doing nothing
  4. assuming whoever made the remark had good intentions and telling people who object to the remark that they are being divisive

@hmdne
Copy link
Contributor Author

@hmdne hmdne commented Oct 1, 2021

@martindemello Tying this up to this current concrete issue, if this rule was in play, I assume that someone who made a joke would be reminded and this would be the end of the conversation. But if someone nevertheless decided to bring up politics and/or division, despite being asked by this rule to not do so, that can be interpreted as a bad intention, overriding the implicit good intention assumption. This is not an enforcement rule, it is a polite plea for a community member to think twice before posting and if just a part of the community accepts that plea, then flamewars will happen less frequently and even if they happen, they may die sooner due to a lack of oxygen.

@hmdne
Copy link
Contributor Author

@hmdne hmdne commented Oct 1, 2021

By the way, if a person takes this point at a heart value, said person could weight an option if sometimes messaging a person in private may be less likely to cause a flamewar. I'm analyzing now some messages in this thread and if they were actually sent in private, a large tree of the flamewar would be cut.

@haydendyle
Copy link

@haydendyle haydendyle commented Oct 2, 2021

People not even accepted that the "joke" was sexist, following messages stated that jokes like that were harmless... and they even tried to use the MINASWAN argument to force people to be nice to them... ignoring the fact that they not being nice to others is what started everything.

If the proposed rule was in place at the time it was probably going to be used against those that were saying that it is not ok to make sexist jokes...

Many tried to reason and to show what was wrong, all were disregarded. which is why the new rules were made because they proved that the enforcement was necessary, no encouragement would stop the offenses (or as they said... the fun.).

@rklemme
Copy link

@rklemme rklemme commented Oct 2, 2021

I am not a fan of basing changes of community guidelines on a single case. Is the situation really that bad that we have to change them?

@Zhuinden
Copy link

@Zhuinden Zhuinden commented Oct 2, 2021

Interesting to see that there was enough pushback against representing "Californian core company principles" over the values of a global but not necessarily Californian developer community.

It can make sense not to discuss politics on a platform such as Ruby-Talk, but not because "it's divisive", but because it's not the right platform for the subject.

@rklemme they have already been changed, this is mostly a revert.

@hmdne
Copy link
Contributor Author

@hmdne hmdne commented Oct 2, 2021

@haydendyle There is no silver bullet here. This proposal isn't perfect, no proposal will be perfect, because people are never perfect. Nothing will make everyone have the same assessment, as I noted in the first post. This proposal tries to go around that in a peaceful way: "you disagree - that's ok, but we can stop here, your disagreement won't bring anything new to the table, please consider that your post may spur a 1000-post conversation".

@rubyFeedback
Copy link

@rubyFeedback rubyFeedback commented Oct 2, 2021

Let's go back to the good old days and focus on ruby as a programming language.

Trying to censor other opinion on a mailing (!!!) list leads ultimately to a growing mass of dissenting opinions be censored out. You already have a similar problem on the bug tracker e. g. if you force 2FA or "mandatory adherence of a meta-codex". At which point did it stop being about programming and a programming language, please?

I don't live in the USA. I could not care any less about the US terminology the hmdne account keeps on using. Can we stop these folks trying to take over ruby? We keep on having this issue again and again. This didn't exist in the oldschool days.

@rubyFeedback
Copy link

@rubyFeedback rubyFeedback commented Oct 2, 2021

Zhuinden: not everyone lives in California. So please don't try to push down US law onto the rest of the world, yet alone the language barrier many japanese devs have to begin with.

@hmdne
Copy link
Contributor Author

@hmdne hmdne commented Oct 2, 2021

@rubyFeedback This PR is about reverting it to an original state and adding a point to discourage talks about politics in a programming language space. Not forbid, only discourage.

@Zhuinden
Copy link

@Zhuinden Zhuinden commented Oct 2, 2021

Zhuinden: not everyone lives in California. So please don't try to push down US law onto the rest of the world, yet alone the language barrier many japanese devs have to begin with.

I am well aware and that's precisely what I said. The original "pt1 and pt2" were focused on turning the CoC to comply fully only with Californian interpretation of social standards and how human interactions should be governed, as it is expected by major Californian companies. Never said that's how it should be, just that that was the general intent behind those changes (that have already been previously merged, I hear this PR intends to revert said changes).

@martindemello
Copy link

@martindemello martindemello commented Oct 2, 2021

@rklemme i would say in this case that someone made a sexist joke, was asked not to do it, and specifically called out the "assume good intent" clause to try to argue that "hey, i meant no harm, and based on the COC you should all just leave me alone". i think it's worth applying a bugfix to avoid this situation in the future, rather than argue endlessly over what "assume good intent" means and who it's meant to protect versus who it's meant to make sit down and shut up.

to everyone else, please consider why you think "consider the impact of your words on marginalised people, regardless of whether you meant them well" is "poitical" or "california law" rather than just basic human consideration. note also that in the original thread some men chimed in to say "hey, in europe we would make such a joke and everyone would just laugh rather than get offended", and then some european women responded with "actually we're sick of it but thanks to the prevailing culture we can't say anything".

@hsbt hsbt assigned hsbt and matz Oct 3, 2021
@hmdne
Copy link
Contributor Author

@hmdne hmdne commented Oct 3, 2021

@martindemello
In my opinion the "assume good intentions" clause is like: if you are not sure if a person had a bad intent or not, you assume he didn't. If he used an argument worded the way you worded it, it's reasonable to interpret that he had a bad intent.

The reason of this point is that in the Ruby community there are at least a few isolated cultures that have their own sets of faux pas situations. Not to mention, that not everyone is fluent in English. Also not to mention the corporate culture vs the casual culture - what's suitable in a circle of friends may be understood badly if it happened in a corporation. Also, we are in a digital setting, without the body language. It's so that we don't escalate the issue, but try to attempt to understand or ignore it.

For the record, it was me who used the "assume good intentions" argument very late in the discussion, because things started to heat up and people started to attack the person who made that joke.

"consider the impact of your words on marginalised people, regardless of whether you meant them well"

If this is an enforcement clause, then we are dealing with discrimination of "non-marginalized people". And who exactly defines who is marginalized and who is not? But if it's not an enforcement clause, but a guideline like the politics clause I proposed in this PR, then I would have nothing against it. And it would probably work better this way, because most people actually have good intentions, but they despise a demanding tone like we currently see in politics.

note also that in the original thread some men chimed in to say "hey, in europe we would make such a joke and everyone would just laugh rather than get offended", and then some european women responded with "actually we're sick of it but thanks to the prevailing culture we can't say anything".

It wasn't in the original thread, but for the interest of transparency and getting the best outcome, said conversation is here: https://news.ycombinator.com/item?id=28715050

@tejasvi
Copy link

@tejasvi tejasvi commented Oct 3, 2021

@Zhuinden
Copy link

@Zhuinden Zhuinden commented Oct 3, 2021

to everyone else, please consider why you think "consider the impact of your words on marginalised people, regardless of whether you meant them well" is "poitical" or "california law" rather than just basic human consideration.

As someone from SF California, it is no wonder that you would consider this statement to be "one-to-one" and represent Californian social standards to be "just basic human consideration", but if it were truly about "basic human consideration", you would not limit consideration to only "protected classes as defined by Californian law" (which is what the Pt1 change did).

I have seen this sort of CoC wording used, by Californians, as the preface for abusing non-Californians on the basis of political differences, citing that "political views are not a protected characteristic therefore you deserve to be called out (read: publicly humiliated) for having the wrong opinion" (in a setting where political views were not even relevant).

And no, the political views in question also had nothing to do with "marginalized people as defined by Californian law". So it can be applied even out of context at any time to anyone, as long as you aren't on board with Californian demands.

So if the intent is to protect people from abusive behavior, then it should consider the global developer community, and not exclusively favor Californian social standards as demanded by Californian company core politicies - as not everyone is Californian.

who it's meant to protect versus who it's meant to make sit down and shut up.

Actually, this is an interesting tidbit, as here, the social standard is to explain to them why they are wrong, and not just force them to remain silent because they opposed the one and only generally accepted paradigm.

They will generally shut up once they understand how they are wrong.

@rklemme
Copy link

@rklemme rklemme commented Oct 3, 2021

I find the restriction "against protected classes" wrong. It should just be removed because harassment should be banned regardless of who or which group is targeted. Otherwise we would be saying "harassment is OK towards these groups and individuals" and that cannot be our intention. (At least I hope so.)

@matz
Copy link

@matz matz commented Oct 4, 2021

I am sorry but I am confusing. As a non-native English speaker (and non-USA citizen), I have a hard time grasping the issue.
Of course, I am against any kind of harassment but I am not sure how those changes improve the situation. Probably we don't share common sense, background, and culture.

So I propose the following:

  • Revert everything back before the issue for now
  • Protect related PRs (including #2690, #2693, #2695, #2696) for a while (say 1 month) to cool down
  • Then open a new issue to discuss the CoC for the Ruby community

Note that the Ruby community has no membership, no initiation, no admission. It's just a group of Ruby users who like the language. So the community guideline shall be abstract and vague (with encouragement but without enforcement) like the current one. CoC for individual teams (e.g. the core team) or aggregations (like conferences) might have more concrete CoC.

@ruby ruby locked as too heated and limited conversation to collaborators Oct 4, 2021
@hmdne hmdne force-pushed the hmdne/remove-abusing-enabling-language-pt3 branch from 2275d04 to 1c0ad73 Oct 4, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet