typelevel / general

Repository for general Typelevel information, activity and issues
19 stars 8 forks source link

Approving FCOP for Typelevel projects #74

Closed jdegoes closed 6 years ago

jdegoes commented 7 years ago

I'd like to submit the Fantasyland Code of Professionalism (FCOP) for review, with the goal of obtaining approval for its use in new and existing Typelevel projects.

As with the Scala Code of Conduct, FCOP explicitly lists encouraged behavior (including showing empathy and treating everyone with professional courtesy), and contains both a strong anti-harassment clause and explicit protections for members of socially marginalized groups.

The goal of this ticket is an official indication that projects using FCOP are welcome to join or to continue to participate in the Typelevel ecosystem.

larsrh commented 7 years ago

I am wary of this. Frankly, I'm also a little surprised about this request, given our firm stance from 2016 and that FCOP as it stands still considers no-platforming to be unacceptable.

I also don't think that the FCOP is technically compatible to the Typelevel CoC (nor the Scala one), because as far as I can tell, e.g. displaying sexist or racist imagery during a talk (in slides, or symbols worn), or in a project repository, is not prohibited and not a punishable offense. Even if it would be, the requirement that only aggrieved members as opposed to everyone can report it (in case of active participation, as FCOP defines it), rules it out in my book. If I understand it correctly, as a white male attending a talk, I wouldn't be allowed to criticize outright sexist material being presented, nor would I be allowed to send an email to the employer, even if it's a work-related project.

jdegoes commented 7 years ago

Two of your points are factually incorrect, since FCOP includes images, sounds, and gestures in the definition of communication, and allows third-party reports at the discretion of the community leaders.

So are you saying that a COC has to encourage or at least allow no-platformers to participate in order to be approved for use in Typelevel projects?

Please state with clarity and precision the exact requirement you have around no-platforming.

fommil commented 7 years ago

@larsrh are you saying that FCOP is in direct conflict with http://typelevel.org/conduct.html ? I don't see how that can be the case - indeed the lack of clarity in the current CoC is why I'd prefer to use FCOP for ensime. I'd appreciate it if TL and FL could agree on how to make the CoCs compatible or at least agree on what exactly is not compatible by referring to specific pieces of text.

FYI when ensime signed up to TL's CoC it was not for any of the reasons you've just presented (no platforming and sending emails to somebody's boss because of conference behaviour): it was because we want our public spaces to be safe places for contributors from any kind of background, explicitly banning discrimination on the basis of gender / sexuality / disability / age. Discrimination on the basis of text editors, such as Vim, is obviously allowed.

On a personal note, I thought it was right for TL to cancel the LC spin-off last year, but I don't see how no-platforming has suddenly become a core part of the TL agenda. I stayed out of the whole debate about LC boycotting because it had nothing to do with me and I don't feel there was any right answer: just a lot of different shades of gray. In hindsight, I don't think any of the fears came true (the person at the centre of the controversy did not gain a following as a result, and was largely ignored by everybody except the no-platformers). I'm going to LC this year because there has been too much division this last year (every country has had to deal with the rise of Nationalism) and I feel we have more that unites us than divides us. If no-platforming and the ability to email work bosses / customers over TL activities is now core to TL, the committee should draft a new CoC that makes it clear exactly what it means to be signed up to TL. I think that's only fair, otherwise I basically have no idea who is deciding what, or what "what" is.

richardhodges commented 7 years ago

So are you saying that a COC has to encourage or at least allow no-platformers to participate in order to be approved for use in Typelevel projects?

That sounds like a pretty significant overreach to me. The Typelevel ecosystem is large and diverse; we should appreciate that different projects have different personalities and needs involved. The FCOP is an outstanding choice for projects that are more strongly focused on technical matters than political drama, so it would be a shame if it was arbitrarily banned.

jdegoes commented 7 years ago

A typical COC does not formally specify all possible circumstances in which an individual may be prevented from participating in a project.

For example, if some person were to contribute a pull request to the Typelevel website, itself bound by the Typelevel Code of Conduct, and it became known the person had pseudonymously contributed offensive content to a blog, the person might very well be prevented from further participation.

This consequence would not itself be seen as a violation of the Typelevel Code of Conduct, because the Code of Conduct does not attempt to address all the reasons someone might be removed, but merely provide some expectations around behavior.

FCOP is much more precise.

FCOP comprehensively specifies which classes of behaviors might result in removal. In fact, no-platforming a fellow member of the community — in addition to stealing or taking credit for their work, or trying to get them fired — fall within such a class.

This provision, which prohibits so-called professional sabotage, is not a guarantee that anyone who engages in such behavior will definitely be prevented from participation, only an explicit statement that the community has the ability to take action on such behavior. The details of the situation factor critically into whether or not the ability leads to a definite action.

Now, the Typelevel COC does not limit reasons for removal in such a fashion, so by itself, the Typelevel COC does not prevent a community from taking action against a member who engages in professional sabotage—including a member who engages in no-platforming.

In fact, there may exist numerous, unspecified reasons why a member might be prevented from participation in a Typelevel COC community, almost none of which are specified in the COC.

In the matter of "no-platforming", the only difference is that, it is implicit in a Typelevel COC community that one can be removed for no-platforming (and lots of other unspecified reasons), whereas it is explicit in an FCOP community—because everything is explicit in an FCOP community.

It does not make any sense, in my opinion, to penalize FCOP merely because it chooses to be precise.

Some people prefer vague COCs. Some people prefer precise ones. Some people prefer political ones. Others prefer non-political ones. There is plenty of room for projects with all of these COCs.

The most important thing in my book is whether or not a COC takes harassment and other destructive behaviors seriously, or whether it encourages a no-holds barred, everyone-fend-for-themselves environment. Both the Typelevel COC, the Scala COC, and of course, FCOP (which contains one of the strongest anti-harassment clauses possible), all clearly fall in the former camp, not the latter.

As stated in the issue description, I am not asking for an endorsement, merely for the possibility of FCOP-adopted projects participating in the Typelevel family of projects.

If no-platforming has become a core part of the Typelevel agenda, I suggest before rejecting FCOP, the Typelevel COC should first be modified to prevent anyone from being removed on the basis of no-platforming behavior. Because without this protection, FCOP remains strictly less powerful than the Typelevel COC, which itself contains no prohibition for removal based on any grounds, including removal based on no-platforming.

I'd also suggest at the same time making the Typelevel agenda much more clear than it already is, because the subject of no-platforming is not discussed anywhere (as far as I can see), nor is it assumed that people contributing to Typelevel projects must necessarily share the same views around no-platforming (or other related issues).

alexandru commented 7 years ago

Professional Sabotage. We define professional sabotage to be any behavior that does have or is intended to have the effect of harming a member's career, including but not limited to attempting to no-platform, blackball, or fire a member, or stealing or taking credit for the work of a member; or encouraging others to engage in such behavior. Explicitly excluded from professional sabotage is all harmful behavior that is exclusively motivated by and communicated in terms of the member's failure to fulfill their professional duties.

I'm actually uncomfortable with this clause for the same reason that some Scalaz members are uncomfortable with CoCs in general. It feels overreaching.

Also at this point Lars only offered his opinion, yet @jdegoes jumps to conclusions: https://twitter.com/jdegoes/status/863863732564140032

So @Typelevel won't approve FCOP because it's not friendly to no-platforming(!). What do you say, Scala developers?

And from https://github.com/typelevel/general/issues/74#issuecomment-301365500:

If no-platforming has become a core part of the Typelevel agenda, I suggest before rejecting FCOP, the Typelevel COC should first be modified

I don't see why, as rejecting FCOP doesn't necessarily mean that no-platforming is a core part of the Typelevel agenda.

I'm afraid of jumping to conclusions too early, but was this submission meant to create dissent?

tpolecat commented 7 years ago

I am reluctant to engage in CoC discussions, but I don't like the direction this is going.

I think "compatibility" should be interpreted generously. Different projects will naturally want to express their expectations in different ways, and nobody has hit on the perfect formula yet. Even among projects that have accepted the TL CoC there are differences in inclusiveness and expectations of civility. This is an area like anything else we do where ideas need to be explored and refined, and John has presented his take on it. You may not agree with it but it has been constructed with thought and care. I am confident that he is acting in good faith, and he deserves a kind and constructive dialog here.

As for the specifics I don't read the TL CoC as having anything to say about no-platforming.

larsrh commented 7 years ago

As @alexandru pointed out, I currently don't see an argument in good faith here, given that my initial response has been grossly misrepresented on Twitter. Locking this thread for now.

stew commented 7 years ago

I do not believe this thread should be locked

larsrh commented 7 years ago

@stew I like locking and continuing after a couple of days more than having to delete troll comments coming from inflammatory statements on Twitter. If you think that those are not likely to happen, happy for you to unlock.

stew commented 7 years ago

[Edited slightly]

[non specific disapproving grunting]

fommil commented 7 years ago

The TL CoC is ambiguous in many regards and I'm becoming increasingly uncomfortable with it: there is a clear mismatch in interpretations that has only been shown to me in this thread.

I don't see why being part of TL means rejecting FL or LC.

I'd like to use FCOP in ensime and I do not understand why you feel it is incompatible with TL CoC. It's a far superior document to the poorly written, sex obsessed (6 references vs scala's 1) , TL CoC.

I'd especially like to know what the process is from here. For example, is it going to be debated by the committee on a youtube stream like the SCIP meetings? I don't think a closed room decision is going to look very good here. If FCOP is going to be rejected, I think the community needs to be a part of that decision, not just the committee.

tpolecat commented 7 years ago

I'd really like to plead with everyone to slow down, take a breath, think, and be kind. There are a lot of us here, and some strong and differing opinions, but we're all trying to do our best. Typelevel talks about compatibility and it is completely reasonable for someone to ask whether a given X is compatible or not. However I think we don't really have a good way to answer that question yet. So this may require some patience.

Would someone like to reiterate the objections to FCOP that have not been addressed, if any? Lars has indicated that he doesn't want to continue so maybe someone else who understands the nuances of this material could help out. I have never studied this stuff so I just don't have a sense for what's important and what isn't.

larsrh commented 7 years ago

I'd especially like to know what the process is from here. For example, is it going to be debated by the committee on a youtube stream like the scala centre advisory meetings? I don't think a closed room decision is going to look very good here. If FLCP is going to be rejected, I think the community needs to be a part of that decision, not just the committee.

To state this clearly, once and for all: I'm not aware of any private chat room meetings, and I'm not planning one. There have been discussions on the accompanying Gitter channel, which is public and archived.

alexandru commented 7 years ago

My objection is that FCOP would be strongly against last year's stance that I personally agreed with.

Of course the debate has nuance and since we are talking about personal attacks and no-platforming, I personally disagreed strongly when Larry Garfield of Drupal was attacked for his sexual orientations, just a very relevant example in context. And I'm a firm believer and protector of the freedoms of speech and association. Therefore there is some merit to the argument that personal preferences, opinions and beliefs should stay personal and that we shouldn't use this to discredit or exclude people from our communities.

But this isn't a black and white issue and it isn't possible to create a community without a common set of values. And I'm only a believer in freedom of speech because at the same time I'm a believer in capitalism, property and being able exercise my own freedom of speech and freedom of association. Such freedoms are a doubly edged sword.

@fommil

I'd like to use FCOP in ensime and I do not understand why you feel it is incompatible with TL CoC.

I am not a lawyer, but I won't apologize for supporting last year's event, I'm standing by my beliefs and if I could go back in time, I would do the same.

Where does that leave people like me that did engage in no-platforming? Are you going to exclude me from your community? What about the other members?

poorly written, sex obsessed, TL CoC.

The Scala CoC is very positive. Have you read it?

alexandru commented 7 years ago

One final thought, the GPLv2 has this clause:

You may not impose any further restrictions on the recipients' exercise of the rights granted herein.

This clause is there for very good reasons, even if it makes GPLv2 incompatible with the original BSD or Apache2.

tpolecat commented 7 years ago

My objection is that FCOP would be strongly against last year's stance that I personally agreed with.

The Typelevel CoC itself doesn't take a stance one way or another, as far as I can tell. If a compatible CoC does take a stand must it necessarily be in support of no-platforming? Would being opposed create an inconsistency elswhere?

I'm not trying to argue, I just want to understand what you're saying.

milessabin commented 7 years ago

I'm on holiday this week and will have comments to make on this thread when I get home. In the meantime there's no urgency to any of this, so I'd like to reiterate @tpolecat's suggestion that we slow down and reflect.

fommil commented 7 years ago

@alexandru to answer your question. If you were engaged in no-platforming a member of the ensime community (or there was reason to believe that you might do so based on previous behaviour), then yes you'd be banned from engaging with the ensime community on github and gitter. I may even extend that protection to members of TL and (at my discretion) the FSF. Personally, I don't think the no-platforming of CY is evidence to suggest that you may professionally sabotage an ensime contributor. If, however, you were to no-platform RMS (as some have started doing) you'd be banned for sure.

Under no circumstances is anybody banned from accepting ensime under the GPLv3 (this is rule 0 of Libre Software), nor from contributing code back under the GPLv3 (via a proxy, e.g. if I was to look at your fork and cherry pick commits back).

I don't see why last year's LC is in any way relevant to ensime. I don't need TL approval to implement the above, but it'd be nice if I could use the FCOP to clarify the kinds of questions along the lines that you have. Right now, I feel the TL-COC is very ambiguous in many gray areas and I know several people who are not contributing to TL because of its lack of clarity.

alexandru commented 7 years ago

@tpolecat

If a compatible CoC does take a stand must it necessarily be in support of no-platforming?

CoCs are about what people and behavior to exclude from a community, not what to include, although language encouraging certain behavior is nice. Not making a stand on no-platforming does not mean that the CoC is in support of no-platforming, it just means that the CoC does not exclude it.

Or in Scala terms, we could say that we've got a subtyping relationship:

FCOP <: Typelevel CoC

The Liskov substitution principle only holds in one direction, covariance is a bitch, therefore some Typelevel members will get excluded or will exclude themselves from FCOP-enabled projects, thus an upgrade to FCOP is by definition incompatible with Typelevel's CoC. This is the same situation with BSD vs GPL. BSD is compatible with GPL only if you can accept that the end result will be governed by GPL's restrictions.

This is actually a really good conversation to have, because I can now see the point of some Scalaz members arguing that not having a CoC in the first place is better. Not saying that I agree, but apparently coming up with a shared set of values is hard.

alexandru commented 7 years ago

@fommil I did read that document and here are the relevant quotes:

  1. We permit only civil individuals to participate in the community
  2. We define civil individuals as individuals who are not currently uncivil
  3. Uncivil: We believe the individual likely to engage in professional sabotage, and the individual has participated in previous professional sabotage or there is credible evidence suggesting the individual is planning to engage in future professional sabotage.
  4. Professional Sabotage. We define professional sabotage to be any behavior that does have or is intended to have the effect of harming a member's career, including but not limited to attempting to no-platform, blackball, or fire a member, or stealing or taking credit for the work of a member; or encouraging others to engage in such behavior. Explicitly excluded from professional sabotage is all harmful behavior that is exclusively motivated by and communicated in terms of the member's failure to fulfill their professional duties.

According to this definition, due to me signing that LambdaConf Statement, I'm an uncivil individual.

@alexandru to answer your question. If you were engaged in no-platforming a member of the ensime community, then yes you'd be banned from engaging with the ensime community on github and gitter. I may even extend that to members of the TL and (at my discretion) the FSF.

Ah, there you go. You're right, you should clear this out in the project's README.

But then the next topic we should discuss is "What is Typelevel?".

fommil commented 7 years ago

@alexandru with regards to the Scala CoC I don't like it and I don't think it's a positive document. I hate to admit it, but the Apache one is more positive. Scala CoC has a lot of ill-defined, wishy-washy words that I don't understand (what does it mean to troll, or bait? Is Martin Odersky's Haskellator considered trolling? When's it not a joke anymore?) and the enforcement of it is very arbitrary. In particular, the shutting down of discussions around licensing of Scala was handled very poorly, and we lost a great contributor in Simon Ochsenreither because of the focus on escalation and scolding, not deescalation understanding and discussion. Anything that tries to police "tone" will exclude passionate individuals and those with sub-optimal communication skills (which includes those who do not speak English fluently). A CoC is for the serious stuff, not the technical disagreements.

I also updated my response, two comments above, to clarify my thoughts on Professional Sabotage. I'm sure others would make a different interpretation.

travisbrown commented 7 years ago

I wouldn't personally adopt the FCoP for my projects, primarily because I think that professional communities can (and should) work for social goals.

That's not relevant to this issue, though. In my view the biggest mismatch between the Typelevel CoC and the FCoP is that Typelevel encourages non-aggrieved members to report any harassment they notice, and doesn't differentiate between reports by aggrieved members and third-party reports. Earlier versions of the FCoP also put constraints on aggrieved members that were an even bigger problem for compatibility, but it seems to have been improved in this respect in the past few months.

(I also think that the FCoP's prohibition on taking harassment outside the community into account in community decisions is in tension with the spirit of the Typelevel CoC, if not the letter. Incidentally, the fact that the Typelevel CoC is weak here is one of the reasons that I'm personally planning to use the Scala CoC for new projects.)

It's important to note that this conversation isn't happening in a vacuum. I'm not as confident as @tpolecat that @jdegoes is acting in good faith here, but I don't think it's my job to decide that, and I don't really care. I do know that he has repeatedly attacked individuals who have criticized the FCoP (e.g. Matthew Garrett, Christie Koehler, myself, etc.). He's called people liars (including many people who I do believe were acting in good faith), has threatened libel lawsuits, has (intentionally or not) made comments resulting in "anti-SJW" dogpiling by his followers, etc.

So I'm a -1. This isn't just about literal compatibility (although even on that basis I think there's a case for no)—it's also about Typelevel forming an association with an organization that doesn't share its goals or values while (further) alienating people who do.

travisbrown commented 7 years ago

Quick footnote: I'm commenting only as a maintainer of a couple of Typelevel projects and don't have any kind of leadership role in Typelevel—i.e. I may want to "play bullshit political games" but I'm not a "guy at the top", as John so collegially puts it.

fommil commented 7 years ago

Personal matters aside (I've not been following any of that), I don't see how compatibility of CoCs can be considered "forming an association". That's like saying we form an association with MIT, BSD, Apache Foundation and FSF by approving their licenses as compatible with Typelevel's goals. This is a matter of compatibility of codes... the equivalent of https://www.gnu.org/licenses/license-list.html

I'd like to have a wider list of options for ensime because I really don't feel that the current TL CoC has been relevant and its ambiguity is turning people away from contributing (also to cats, but that is not my project so I do not wish to push a different CoC upon them).

travisbrown commented 7 years ago

@fommil I quote:

The goal of this ticket is an official indication that projects using FCOP are welcome to join or to continue to participate in the Typelevel ecosystem.

Being legalistic about the details of CoC compatibility should absolutely be part of this conversation, but in the end we're not just formalistically checking off boxes—we're making decisions about what we want this community to look like and what participants we want it to attract or alienate.

jdegoes commented 7 years ago

@larsrh

If I am misunderstanding your rationale for rejecting FCOP, then please show me how. I genuinely want to understand why you will reject projects that use FCOP from participating in the Typelevel family of projects.

If your reasons do not bear scrutiny (for example, you are assuming that FCOP has more power to kick someone out for no-platforming than the Typelevel COC does—which is untrue) or if they are based on a misunderstanding of FCOP (for example, you are assuming that images are not covered by FCOP, which is again untrue), then I assume you would want to know this, as well.

If the decision is going to be that FCOP projects are not welcome in the Typelevel family, then I hope both of us will be able to state exactly why this is the case when all is said and done.

Locking the thread and refusing to explain the rational sends the wrong message to the community.

@alexandru

Please keep a few things in mind:

  1. FCOP has nothing to say on the withdrawal of the Typelevel Summit from LC. As far as I can see, there is no remotely plausible interpretation of FCOP that permits any retaliatory actions from an FCOP project based on such a withdrawal.
  2. You signing the statement does not make you uncivil. First, as stated in the definition, a designation of uncivil requires a belief from the FCOP community that you will engage in professional sabotage against members of the community (i.e. it's about future actions). Second, a designation of uncivil requires evidence of sabotage, and I personally don't see how expressing your views around talk selection could be considered professional sabotage.
  3. You seem to be operating from the assumption that a Typelevel COC-governed project couldn't remove you for no-platforming. This assumption is false. A Typelevel COC-governed project can remove you for strictly more reasons than an FCOP one. The difference is that FCOP voluntarily chooses to limit the reasons you can be removed, in an effort to hold leadership accountable and make them less likely to engage in favoritism, inconsistent interpretation, or other malicious behavior.
  4. If Typelevel approved FCOP tomorrow, it wouldn't mean that Typelevel endorses FCOP. It would just mean FCOP projects could join the Typelevel ecosystem. If you didn't want to participate in these FCOP projects, you wouldn't have to do so, just like people who feel the Typelevel COC is to "squishy" don't have to participate in Typelevel projects that use the Typelevel COC.

Your core objection to FCOP seems to be, "They could eject me for some reason." But again, FCOP is explicit about the circumstances in which you can be ejected. Other COCs do not have this precision, and projects adopting these COCs can eject you for innumerable reasons, including the very few reasons that FCOP projects are allowed to eject you for.

@stew

I will not remove the request. This issue can be considered closed when there is a clear indication as to whether or not FCOP projects may participate in the Typelevel family of projects.

Your reason for not wanting to allow FCOP projects to join Typelevel seems to be, "Well, Tony is allowed in an FCOP community, so it must be bad." I suggest we keep specific individuals out of these discussions and focus on issues of substance—like the actual contents of FCOP.

As you well know, Scalaz has rejected any code of conduct, including FCOP. FCOP is very clear that harassment and shaming (including personal insults) will not be tolerated, and all participants in an FCOP community are required to abide by these restrictions.

@travisbrown

The entirety of your argument seems to be, "FCOP isn't compatible with the spirit of the Typelevel COC. Oh and @jdegoes calls people out for making false statements about FCOP."

Since the "spirit" isn't something that's written down anywhere, I'd argue that no one can know whether or not some COC is compatible with the "spirit".

If compatibility with the "spirit" of Typelevel COC is required, then I suggest this "spirit" should be written down somewhere so we can all know the precise reasons why projects with certain COCs are rejected from participating in the Typelevel family of projects.

As for me countering libel and contradicting false statements made about FCOP, expect that to continue for as long as people insist on libel and making false statements about FCOP.

travisbrown commented 7 years ago

@jdegoes I don't speak for Typelevel but I don't believe a rigid formalism is the best way to approach this specific issue.

(Also that definitely wasn't "the entirety of my argument".)

alexandru commented 7 years ago

@jdegoes yes, my primary concern is that the withdrawal of the Typelevel Summit from LC and signing of that statement would make one uncivil according to FCOP. I can't see how you're right about this, unless I'm seriously misinterpreting the words I'm reading.

However I admit that I am not a lawyer and English isn't even my first language, so for the moment I'll admit there's a possibility that I might be wrong about this particular concern, so I'll shut up about it, hoping that people knowing more than me would either prove me right or wrong.

My other concern is your mishandling of this proposal. I'm sure we can find middleground in the interest of collaboration, but you can't start the conversation by assuming the worst about Typelevel members.

jdegoes commented 7 years ago

My other concern is your mishandling of this proposal. I'm sure we can find middleground in the interest of collaboration, but you can't start the conversation by assuming the worst about Typelevel members.

To quote Lars on the issue:

FCOP as it stands still considers no-platforming to be unacceptable.

Which I summarized as:

So @typelevel won't approve FCOP because it's not friendly to no-platforming.

In what way is this "assuming the worst" about Typelevel members? I'm here because I think the vast majority of the community don't have an issue with FCOP projects participating in Typelevel.

I think a few high-level Typelevel members may be allowing personal issues to cloud their judgement. But discussion is the only way to clear this up.

non commented 7 years ago

Hi folks, I agree with @tpolecat and @milessabin that there is no rush here -- let's take our time and be sure to get it right.

I haven't read FCOP in enough detail to have a clear position on this yet, so I'll otherwise refrain from comment until I have more information.

johnynek commented 7 years ago

@jdegoes can you elaborate on the interaction between "don't stereotype" and "don't harass" with "The standing of members is unaffected by behavior that does not comply with these requirements if this behavior occurs in other communities."?

Am I correct in understanding that if, for instance I became well known for harassing and stereotyping on, for instance, Twitter, that the FCOP explicitly protects me from being excluded from any project that adopts it?

Also if I harass and stereotype members of community A using FCOP, say project foo, is that a whole new community B if I another set of individuals is running project bar?

jdegoes commented 7 years ago

Am I correct in understanding that if, for instance I became well known for harassing and stereotyping on, for instance, Twitter, that the FCOP explicitly protects me from being excluded from any project that adopts it?

There is a difference between preemptive exclusion and reactive exclusion.

FCOP would not allow you to be preemptively excluded on the basis of some argument you had on Twitter, for example. Of course, you could be reactively excluded on the basis of your actual behavior in the FCOP community.

This is similar to Contributor Covenant, which states that the COC " applies within project spaces and in public spaces when an individual is representing the project or its community", as well as a number of other codes of conduct. Even Typelevel COC is implicitly limited to community activities (unless it intends to prohibit you from watching porn, for example).

The limitation serves three primary roles:

  1. It allows strong protections during active participation. FCOP's definition of harassment is so strict that merely mentioning someone on Twitter could be considered harassment.
  2. It removes the motivation for people to dig around in your personal life (including private accounts on members-only websites) to get you excluded from an open source project. This just happened to someone in the Drupal community.
  3. It limits the scope of work for what are likely unpaid volunteers to an open source project. People generate a huge amount of interactions through liking, sharing, and creating content, making investigations of external content prohibitively expensive.

The only COCs I'm aware of that don't take this approach are Citizen and (defunct) Open.

Of course, there are other reasons you can be excluded. In particular, if you threatened someone or seriously harassed them, you might be excluded on grounds of being uncivil.

Also if I harass and stereotype members of community A using FCOP, say project foo, is that a whole new community B if I another set of individuals is running project bar?

It's a separate community. Just because an FCOP community bans someone for some behavior, doesn't mean a Typelevel COC would make the same call.

fommil commented 7 years ago

preemptive exclusion and reactive exclusion is a good codification of what I've been doing in ensime. That gives me confidence that there are a lot of precedents in the doc that I'll tend to align with. I've seen some people who cause trouble on Twitter, and I've not done anything about it when they show up in ensime gitter rooms (and nothing has come of it). But if somebody then goes onto reddit and starts badmouthing contributors, that's when they get banned and all their poor quality - unreproducible - tickets get closed. The kind of person who does that has already left the building by that point.

johnynek commented 7 years ago

I think it is important to ask two questions:

1) why do we have CoC at all? 2) why does a project need to be a typelevel project?

Scala has, especially in the past, had the reputation of being a hostile programming community. I understand that one of the main motivation of typelevel was to provide a community of scala users where that is unacceptable. Not everyone cares about this issue. They are free to not participate in a community that places a higher value on kind, non-hostile and respectful communication than they would prefer. My understanding is that our motivation for having a CoC is to foster better behavior in the communities and to welcome more participants that care about being treated without hostility.

Not everyone wants to have a CoC. They shouldn't be forced to, in my opinion, but they would not be part of the typelevel community without one.

My main concern with the FCOP is that it seems to put protection of the right to participate higher than the community's right to choose members.

I think people who disagree with typelevel's approach should feel free to continue to build their communities as they see fit. I hope typelevel continues likewise to focus on building a welcoming scala community.

johnynek commented 7 years ago

To put it another way:

Try a little tenderness: https://www.youtube.com/watch?v=IQ9n2_5mbig

larsrh commented 7 years ago

Temporarily locked because of the second troll comment in a short period of time.

larsrh commented 7 years ago

Trolling user (not @jdegoes; the comments have been deleted) has been blocked altogether, so that this can be reopened.

alexandru commented 7 years ago

Reading the arguments here, I'm was more and more inclined to do a thumbs up for FCOP, except that ...

@jdegoes in your comment (https://github.com/typelevel/general/issues/74#issuecomment-301910112) you're doing an ad-hominem to disprove the idea that Typelevel's community has been very welcoming. And even with the blurry face, everybody knows whom you're talking about.

In my experience, the Typelevel projects and their communication channels (Gitter, GitHub issues, etc) have been very welcoming, much more so than all other Scala channels, like Reddit, #Scala and #Scalaz on Freenode, etc. The Typelevel community is in my mind without a doubt the most welcoming Scala community and one of the friendliest programming communities around.

CoCs are social contracts governing the social interactions of a community. They are not software licenses. They are not statements of facts. Typelevel is also not the FSF or OSI. Typelevel doesn't have lawyers as employees.

Therefore it is entirely reasonable for a CoC to question the motivation of its author. So here's my concern - FCOP is not versioned and it received a fair amount of modifications, mostly from you: https://github.com/fantasylandinst/fcop/commits/master/COC.md

I am not seeing versioning on FCOP (like GPL has version 2, version 3). And worrying is that FCOP included some statements that highlight your own philosophy, but that would have been unacceptable for Typelevel: https://github.com/fantasylandinst/fcop/commit/f7d2bbddc075db5fb11187f96151d49c46952afd#diff-0fad7019f8f890808078fb36b3675577

I'm sure this was in response to feedback, incorporating feedback is good, but what happens if FCOP is going to be updated with other wild ideas that will be unacceptable for Typelevel? Going through another painful discussion like this one is not acceptable. It's also not acceptable for a CoC to be set in stone, since society is in constant change and a CoC has to be up to date.

So my question is this: should FCOP be accepted as a Typelevel-compatible contract, how can we prevent it changing in directions that aren't compatible with Typelevel's goals?

fommil commented 7 years ago

That's not an ad hominem: it's factual and completely relevant to the discussion. I really had no idea that the agenda here was Exclusion by politics (and USA politics at that... this is a global community so the concept is ridiculous). I really hope this is not the agenda of others.

I also admit to having concerns about the document being CC-ND and unversioned. I don't think FantasyLand has the same level of trust as FSF and therefore it may be best if there were an unbranded CC-BY or CC-BY-SA variant, with released versions CC-ND carrying the FantasyLand brand (attribution in all cases, of course)

ShaneDelmore commented 7 years ago

I support having FCOP as an option once it is versioned, and any conflicts if found addressed. It does seem like as FCOP evolves each new version may need re-approval but that doesn't feel like a showstopper to me.

alexandru commented 7 years ago

I also admit to having concerns about the document being CC-ND and unversioned

Right and that was me asking the author what are the plans for the future, in the interest of moving this forward and not in the interest of rejecting it.

If say FCOP is versioned, all concerns are being addressed and maybe @jdegoes finds other maintainers of that document such that the responsibility doesn't fall on just one person, then I see no problem in it being accepted.

EDIT: this comment was edited to remove the aggressiveness on my part, after @fommil clarified the meaning of his message on Gitter.

travisbrown commented 7 years ago

@fommil @alexandru @jdegoes

I had decided I was done with this thread, but since something I said in some tweets is apparently relevant here I want to clarify my position.

First, those comments had nothing to do with the enforcement of a CoC (or any formal process at all). I'm not banning Republicans or UKIP voters from my projects, and I'm not advocating for Typelevel to do anything remotely like that.

On the other hand, if you're the kind of person who's deeply invested in the idea that slavery in the US wasn't that bad (to take one of the examples of a fairly common belief on the right in the US), you may not feel comfortable in a project I maintain, and I'm 100% fine with that. This again has nothing to do with a CoC (until you start advocating for your position in community channels), and it's very unlikely to come up at all in community interactions that are entirely limited to Gitter and GitHub.

I do support "political exclusion" in the sense that if you show up in a project I maintain as a prominent or outspoken gamergater, for example, you'll be banned, regardless of how well you behave in the community's channels. Of course I'm not going to sort through your posting history, dig around for alternate identities, etc.—this is about purple-and-green-Pepe-avatar-level shit. I don't believe the gamergater "deserves a chance" to be a productive, non-harassing member of the community, because their presence means that other people will stay away.

I don't have an algorithm to offer that explains how I'd draw the line between gamergaters and Republicans, and I don't have to have one, because I don't believe formalism is the answer here—the idea that this entire process has to be systematized from first principles is being brought into this thread from outside. There are plenty of issues in this domain that I believe have to be made on an individual basis by humans in conversation about complex causes and effects (and the question in this thread is one of them).

techsoldaten commented 7 years ago

@travisbrown

With all respect, that would totally be a reasonable position if it described the actual mechanics of social interaction in online communities. In most communities where I have seen bans, they don't happen because someone is a prominent gamergater. Prominent gamergaters tend not to be code contributors, they tend to be selfish monsters.

The origin of most bans happens because a person actually does something awful (i.e. Applebaum), two people have trouble settling a dispute, or because a person was doxxed and someone decides they have trouble with what they found. There are shades of gray in each which have the potential to disrupt communities.

I don't want to tell you what to believe here, but it strikes me that the line drawn between political exclusion and formalism could be considered arbitrary. One deals with attitudes from a personal, subjective perspective, the other deals with actions from a community perspective. I'm one of those developers who actually reads COCs before contributing, the presence of either policy as a means of conflict resolution has the potential to drive people away.

What attracts me to FCOP is the structure it provides and the focus on actions as the source of a ban. Politics are strange right now, and I have been involved in situations where members are being tossed because someone decided they have a problem with who another member voted for, or because of their private sexual habits. The appeal of a set of rules is that can be followed removes this concern, but even more it's the idea that there is an actual process for how they are defined.

In the same vein, I share the desire of @alexandru about versioning. I don't want to see a COC change dramatically at some point without my knowledge.

travisbrown commented 7 years ago

@techsoldaten I agree with your assessment of the kinds of problems that realistically come up in projects like this (my comment picked an extreme case in an attempt to correct a derail focused on a misrepresentation of something I'd said). I think we probably disagree on how much codification is desirable, but I respect your position and am happy to see it represented here.

techsoldaten commented 7 years ago

@travisbrown Thank you. I understand we sometimes pick extreme examples and doubt anyone would believe you were purposefully trying to suggest there was a problem with gamergaters in scala.

Please understand I am not trying to suggest Typelevel become some highly regulated community, just that Typelevel projects should be able to adopt their own COC rules and FCOC does have it's appeal. FCOC might not be something you like, but in no way am I suggesting you should be forced to adopt it in any project you don't maintain.

fommil commented 7 years ago

@travisbrown thanks for clarifying that: I had indeed misunderstood your tweets to mean that you wanted to exclude people based on their democratic right to vote. Incidentally, your USA concepts do not translate well: your Liberals are more closely aligned with our right-leaning Conservatives (we call it Thatcherism) and we have no equivalent of your Libertarians or Republicans (which you also confusingly call Conservatives?). If I was to exclude anybody "right of centre", you'd be out along with everybody else from New York to San Francisco bay.

I'm pretty sure I'd be willing to block somebody who used a Nazi symbol as an avatar, but I'm not sure I'd be able to recognise anything more subtle than that (I had to google what Pepe was... I still don't really understand it): I'd certainly respond if somebody flagged it up to me as insulting them, but I've honestly never had anybody with that kind of inclination ever come anywhere near ensime.

I think it's good that each Typelevel sub-community has the ability to interpret where the boundaries are for things like Community Sabotage and that we can consult with each other as a sounding board for anything trickier. I like that FCoP gives a common language we can use to discuss it. I like formal definitions - even if it is just an imaginary construct - and I don't feel I can participate in CoC discussions without them. I also don't have an algorithm for what I'd be willing to tolerate... what if somebody wrote a blog post ranting about the evils of the GPL or an opinion on Stallman the individual? Am I going to allow that, will it depend on the content, am I being too emotional by letting my admiration of the FSF get in the way of professional discourse? I don't know, it'd have to happen for me to find where my limits are. Maybe I'd not block them, and instead just ignore them, even let them know that I'm not interested in talking to or helping them, but they are free to use the channel. Who knows, but without a code in place, maybe I'd just tell them what I thought of them... and isn't the code about keeping us accountable as community leaders as much as it about listing what isn't acceptable?

To re-iterate, the only problems we've had are with people insulting myself and other contributors for not fixing their bug reports or implementing all the features they want, and it is extremely draining. I've also had to deal with the anti-CoC crowd who call me an SJW, the SJW crowd who say I'm not pressing for enough support for minorities, and the people who call me a "user blamer" for wanting to focus on improving things for our contributors instead of being on support 24/7 for people who don't RTFM ... frankly it's all a bit too much at times because I'd much rather be hacking, learning something or writing my book. Or playing golf, sipping whisky or hiking in the highlands. So this is why I don't think the TL-CoC is relevant to ensime and why I'd like to have alternatives.

jdegoes commented 7 years ago

@alexandru

@jdegoes in your comment (#74 (comment)) you're doing an ad-hominem to disprove the idea that Typelevel's community has been very welcoming. And even with the blurry face, everybody knows whom you're talking about.

This is not an ad hominem—it is a direct quote and a demonstration that people have very different ideas of what "welcoming" entails in a professional community.

Not shown in the quote is what set it off, and that was a pro-FCOP statement that argues for a separation between professional and personal lives; and consequently, a separation between extreme social and political activism and open source development.

Some people do not wish for such a separation. My point was never that Typelevel is unwelcoming, only that accusing FCOP of being "unwelcoming" is factually incorrect, unless we substitute an alternate definition of "welcoming", one that I and many others would not find welcoming at all.

I'm sure this was in response to feedback, incorporating feedback is good, but what happens if FCOP is going to be updated with other wild ideas that will be unacceptable for Typelevel?

The current version of FCOP is fairly stable, itself the result of much debate, discussion, and revision. That said, I think this is an excellent concern — one that I'd share for other COCs, such as Scala and Typelevel. I would strongly encourage Typelevel to only allow specific versions of COCs that have been vetted beforehand.

FCOP has been versioned since the early days, but it uses tagged versioning rather than in-document versioning, and has an append-only repository. It lacks only a polishing before 1.0 is released.

Do you think tagged versioning is an acceptable way to version a COC?

So my question is this: should FCOP be accepted as a Typelevel-compatible contract, how can we prevent it changing in directions that aren't compatible with Typelevel's goals?

I think allowing only specific versions is the most sensible thing to do, but it's also worth pointing out that FCOP development occurs in the open and everyone is welcome to participate. If there are holes or edge cases or unanticipated scenarios, or if more exotic uses of FCOP reveal any "bugs", then I hope people submit issues and pull requests accordingly.

jdegoes commented 7 years ago

@travisbrown

No one desires to stop you from governing your open source projects in a manner of your own choosing—whether that's excluding people because of their membership in groups, or making people uncomfortable for their religious or political beliefs.

However, there exist many who do not wish to contribute to open source projects that may exclude them or make them uncomfortable for their positions on religious or political issues—especially when there's no process for such repercussions other than "It feels good to me."

Similarly, there exist many open source projects that do not wish to become political battlegrounds for social activism. They wish to build great software in an environment that's free of all hostility.

I think the vast majority of people in the Typelevel community are fine with different projects adopting different governance so long as there is a demonstrated commitment to creating a non-hostile environment. All the COCs under discussion here, including FCOP, have, I believe, demonstrated a commitment to creating a non-hostile environment.

The differences beyond this are a matter of personal choice.

alexandru commented 7 years ago

@jdegoes

FCOP has been versioned since the early days, but it uses tagged versioning rather than in-document versioning, and has an append-only repository. It lacks only a polishing before 1.0 is released.

Do you think tagged versioning is an acceptable way to version a COC?

I haven't seen the tags. Once v1.0 is released I'd be more comfortable seeing that version in the document, maybe as a subtitle, see for example GPLv3.

The reason is that if you'll ever have a 2.0 release (major version which would mean breakage from 1.0), then both versions should be allowed to coexist. And if that ever happens people should be able to refer to FCOP v1, FCOP v2, etc.

As an example GPLv2 coexists with GPLv3 and in general people know that GPLv3 == GPLv2 + "anti-tivoization and explicit patents grant", which is not acceptable for some projects (e.g. the Linux kernel), but OK for others (e.g. Emacs).