Approving FCOP for Typelevel projects #74
Comments
larsrh
added the
Policy/Governance
label
May 14, 2017
|
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
May 14, 2017
|
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
May 14, 2017
•
|
@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
May 14, 2017
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
May 15, 2017
•
|
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
May 15, 2017
•
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
And from #74 (comment):
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? |
|
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. |
|
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. |
larsrh
locked
and limited conversation to collaborators
May 15, 2017
|
I do not believe this thread should be locked |
|
@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. |
|
[Edited slightly] [non specific disapproving grunting] |
larsrh
unlocked this
conversation
May 15, 2017
fommil
commented
May 15, 2017
•
|
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. |
|
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. |
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
May 15, 2017
|
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.
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?
The Scala CoC is very positive. Have you read it? |
alexandru
commented
May 15, 2017
|
One final thought, the GPLv2 has this clause:
This clause is there for very good reasons, even if it makes GPLv2 incompatible with the original BSD or Apache2. |
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. |
|
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
May 15, 2017
•
|
@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
May 15, 2017
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 CoCThe 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
May 15, 2017
|
@fommil I did read that document and here are the relevant quotes:
According to this definition, due to me signing that LambdaConf Statement, I'm an uncivil individual.
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
May 15, 2017
•
|
@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
May 15, 2017
|
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
May 15, 2017
|
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
May 15, 2017
•
|
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
May 15, 2017
|
@fommil I quote:
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
May 15, 2017
|
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. Please keep a few things in mind:
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. 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. 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
May 15, 2017
|
@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
May 15, 2017
|
@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
May 15, 2017
To quote Lars on the issue:
Which I summarized as:
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. |
|
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
May 16, 2017
|
@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
May 16, 2017
•
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:
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.
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
May 16, 2017
|
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
May 16, 2017
|
I think it is important to ask two questions:
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
May 16, 2017
|
To put it another way: Try a little tenderness: |
larsrh
locked
and limited conversation to collaborators
May 16, 2017
|
Temporarily locked because of the second troll comment in a short period of time. |
|
Trolling user (not @jdegoes; the comments have been deleted) has been blocked altogether, so that this can be reopened. |
larsrh
unlocked this
conversation
May 17, 2017
alexandru
commented
May 17, 2017
|
Reading the arguments here, I'm was more and more inclined to do a thumbs up for FCOP, except that ... @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. 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: 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: fantasylandinst/fcop@f7d2bbd#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? 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
May 17, 2017
|
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
May 17, 2017
|
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
May 17, 2017
•
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
May 17, 2017
|
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
May 17, 2017
|
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
May 17, 2017
|
@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
May 17, 2017
|
@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
May 17, 2017
|
@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
May 17, 2017
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.
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?
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
May 17, 2017
|
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
May 17, 2017
•
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). |
jdegoes
commented
May 17, 2017
It is definitely versioned, albeit with tags, but the concern about CC-ND is legitimate. The ideal license would say "If you change this significantly, don't call it FCOP anymore," which can perhaps be achieved with your suggestion — by having a generic unbranded version, and a branded version.
I'm 100% on board with this. |
travisbrown
commented
May 17, 2017
fommil
commented
May 17, 2017
•
|
@jdegoes yeah that unbranded CC-BY variant sounds ideal. This is in fact what we did in the Siyavula textbooks: versions of the books that are authorised by the South African government are given "curriculum compliant" status and therefore CC-BY-ND, but there is a near identical version available in the repo which is CC-BY. I had a long argument with Stallman about this and several months later he apologised and admitted that on reflection he thought we actually did the right thing He also ranted at me because Siyavula means "open" in Zulu. Honestly, you gotta give him credit for consistency. |
alexandru
commented
May 17, 2017
|
The concern for modifications is legitimate, MIT (and probably BSD) licensed software is a minefield due to software authors introducing weird clauses, like the famous JSON license saying "don't be evil". |
|
Today, one can join a Typelevel room and know it's under one of two codes: Typelevel or Scala. This proposes a third, more dissimilar option. I doubt it stops at three. I participate in several Typelevel communities. I credit the CoC in part for attracting and protecting those communities. I don't enjoy reading or discussing the CoC. I am not enthused about adjusting to subtly different expectations every time I switch rooms or change directories. Multiple codes of conduct are not without cost. If an existing CoC is acceptable, I encourage adopting it. If it's unacceptable, I welcome a proposal for an amendment. But I prefer codes of conduct in Typelevel are standard and stable. |
fommil
commented
May 17, 2017
•
|
@rossabaker you're kidding yourself if you think the interpretation is the same for each project, or ever will be. Myself and Travis have shown how we each interpret something differently (and both perfectly valid interpretations). The TL CoC is so wishy washy as to basically allow any interpretation. There is a fear of a far reaching interpretation and some people are not contributing to TL projects because of that fear. I, for example, would never approach somebody's employer to complain about their actions in an ensime chat room... but it is clear from this discussion that some people think that's perfectly fine. I would think twice before engaging with a community that felt such behaviour was ok and I'd definitely want to know up front if that was a potential risk I'd take as a contributor. The rules for joining TL were always "a compatible CoC" so we need a list of approved "compatible" CoCs and John has proposed one in good faith that I would like to use in ensime. If anybody thinks it is incompatible with the current TL-CoC please ask him to update it, with specifics. |
jdegoes
commented
May 17, 2017
|
I've created an issue to track the request for unbranded licensing. This should address your concerns, as well as my and @alexandru's concerns around a subtly modified version being deceptively labeled "FCOP". It's targeted for 1.0. This is similar to saying that, because it's inconvenient, all Typelevel projects should utilize the same open source license (e.g. AGPL3). While I appreciate the desire to simplify life for developers, the reality is that maintainers do not have exactly the same sets of needs in choosing either an open source license or a code of conduct, and asking them to submit changes to Typelevel's Code of Conduct misses this critical point. As should be abundantly clear from this thread, the modifications that some would prefer to make to TCOC will alienate others, in the same way the current form of TCOC alienates some. There is no way to get everyone on the same page, because different maintainers have different needs. Rather than forcing everyone to use the same open source license, the same code of conduct, the same Scala code style, the same version of the Scala compiler, and so forth, I think it makes more sense to allow diversity in Typelevel projects, so long as they meet some minimum bar (which, for COCs, I'd suggest is making sure the environment is not hostile). |
fommil
commented
May 17, 2017
|
Just for the record, +1 on AGPL for all projects. |
mjg59
commented
May 17, 2017
|
I'll say upfront that I'm not involved in any of the communities under discussion here (and am unlikely to be in the near future), and it's entirely legitimate to discount my opinion as a result. However, I was mentioned upthread, and I've been following the development of the FCOP for some time. While many of the problems I've seen in it have been improved, here's a (somewhat, but not hugely, contrived) example of why I consider it to still have significant failings: Individual A is a developer whose participation in a community enhances their professional standing and makes it easier for them to obtain paid employment. They write under a pen name, B. B campaigns for laws to be changed such that homosexuals have no property rights due to them being morally inferior. A never refers to B, and does not engage in overtly homophobic or discriminatory behaviour within their professional community. If sincerely held, B's beliefs are a personal attribute, as defined in FCOP. This has the following consequences:
Effectively, the FCOP asserts that there is no level of (legal) behaviour outside a community that is too reprehensible to justify blocking someone from membership of that community. It goes further by forbidding multiple kinds of response to that reprehensible behaviour. Communities that adopt the FCOP are likely to be perceived as hostile to groups that face discrimination for who they are rather than what they believe. Having Typelevel adopt it as a "blessed" CoC for subcommunities is likely to cause some of that to be associated with the larger community. |
jdegoes
commented
May 17, 2017
|
I think the point being missed is that most COCs do not impose any restrictions on the ways in which people can be expelled. FCOP does impose such restrictions. Just because FCOP gives a community the ability to impose a consequence, does not mean a consequence will be imposed. The particulars of the case matter, which is why, in my opinion, you cannot eliminate the need for human judgement. FCOP does not eliminate the need for human judgement, it just limits the scope to reasonably well-defined areas, which guards against abuse by community leaders, provides consistency, and sets reasonably clear expectations for participants. Stated differently, most COCs would be able to expel for any of the above reasons. Typelevel COC and other COCs provide no guarantees you would not be expelled for these or any other types of behaviors or thoughts. It's unfair to pick on FCOP just for being explicit.
As you know, this is not true. Expectation of unlawful behavior (including threatening behavior, hate speech, and so forth), community sabotage, or professional sabotage are all sufficient to preemptively block someone from participation, and any unprofessional behavior of any kind is sufficient to reactively block someone from participation.
Let's consider that the initial version of FCOP was written by a woman (someone outside Fantasyland), and has been contributed to (indirectly and directly) by three other women, one person of color, one member of LGBT, and no more than 2 straight white males (depending on how you count contributions). In other words, FCOP is overwhelmingly a product of groups underrepresented in technology. I'm sure some of them would be offended at your denying them agency and attempting to speak for them. |
mjg59
commented
May 17, 2017
It's certainly the case that subcommunities could adopt their own interpretation of their CoC that normalised this behaviour - a CoC is not, in itself, a statement that a community is willing to adopt a particular stance, and potential members need to look at the people involved and their past behaviour to come to a conclusion on that point. But when a CoC expressly asserts that certain behaviours are acceptable and certain behaviours may result in consequences, it's reasonable to assume that communities following that CoC will act in accordance with that. (Let me put this differently: if a friend invites me over to dinner and tells me that they'll shoot me if I don't finish my food, that is not preferable to the situation where a friend invites me over to dinner and says nothing about whether or not they'll shoot me if I don't finish my food. I trust my friend not to shoot me, even in the absence of an affirmative claim that they will not - but in the presence of an affirmative claim that they will, I'll probably decline the invitation. Being explicit about certain options being on the table is not an improvement)
I'm sorry, yes, that was misleading of me. If member A runs a blog asserting white supremacy, and potential member B informs member A's employer of this, potential member B can be preemptively blocked from joining the community. However, member A's beliefs could not be used to justify blocking them from joining any other FCOP community.
I certainly wouldn't want to speak for those individuals (or assert that anything I've said represents the broad opinions of any given group), but that doesn't actually provide a strong argument against my assertion. |
|
(I apologize for the length of this comment. I wanted to try to be as explicit as possible and lay out my reasoning.) First, I think it's worth talking about why Typelevel projects are required to have a CoC. The reason (at least in my mind) is that when Typelevel lists a project, we are endorsing the project's quality (existing as well as potential) to be a useful tool for doing FP with a welcoming community. I think everyone on this thread agrees about this but I just wanted to be explicit about that. With that in mind, the Typelevel claim is that a CoC is important to give project participants (especially newcomers) a sense of what they can expect from the community (as well as behavior they should not have to deal with, such as harassment). Projects will have different ideas of how best to do this, which is why we don't mandate the Typelevel CoC in particular but allow projects to choose. We hope that certain norms (being welcoming, free of harassment, etc.) will be true across all projects. Are projects that use the Typelevel CoC guaranteed to be welcoming? No. Projects rely on the maintainers and veteran community members to serve as positive role models and to help set norms. Similarly, projects without CoCs (or with CoCs that I disagree with) might still function effectively in spite of this. I see two main problems with FCOP that lead me to believe that in its current form it is not compatible with Typelevel's goals for a CoC. Again, this is not to say that projects adopting FCOP are bad, just that I see structural problems with the document that I think make it unable to provide the same assurances that the Typelevel CoC (and others) aim to. The first specific problem I see is the language around the reporting of violations:
In my experience, newcomers who are harassed generally don't report that harassment, they just leave or quietly bear it. This is for several reasons:
Letting these sort of incidents just happen creates precedent, and makes it harder and more jarring to try to enforce future violations (since the same thing may have happened yesterday or a week ago and gone unreported). Violations may go unreported due to the aggrieved party walking away from the community, or from a lack of aggrieved party at that time (e.g. a racist statement in a channel where no one is of the targeted ethnicity). In many cases, other third-parties who witness the harassment (especially veteran community members) can and should productively intervene to try to stop the harassment, and if necessary to report a code of conduct violation. This kind of baseline experience (that you don't have to be a woman to report sexist harassment, a member of a particular ethnic group to report racial harassment, etc.) is part of what I consider to be an essential feature of a code of conduct. (FCOP does say that "We will investigate third-party reports at our sole discretion." I am not satisfied with this: I think Typelevel projects should commit to investigating third-party reports in all cases; discretion will still come into play in determining whether the investigation substantiated the report. This looseness in the FCOP language sets a very bad precedent in an otherwise explicit and precise document. All participants should feel that they can report harassment if they see it.) The second concern I have is around private harassment. It's not clear to me if someone sending threatening or harassing messages privately in connection with a channel would count as harassment during active participation or not. In particular, I worry that the FCOP's attempts to be very specific around this terminology leave holes that a harasser could use to exploit the FCOP. My reading of other CoCs (Typelevel, Scala, Contributor Covenant, etc.) is that this kind of private harassment linked to an in-channel communication or argument would be grounds for CoC enforcement, while it seems like FCOP is specifically written for this not to be the case. (One extreme interpretation would be that a member who receives private harassment from another community member can't share it without violating the FCOP provision on doxing -- although I don't think this is what the FCOP authors intend.) I am less certain of the points around my second concern: it may be that the FCOP language is just unclear, or that I am misunderstanding it. Because the question here is whether FCOP is compatible with Typelevel in the context of any project, I have to try to imagine how many different maintainers and community members will interpret it. My first concern (around aggrieved members and standing) seems more fundamental, but doesn't totally subsume this second concern, so I mention them both. Given how precise FCOP is, I am assuming that it's not an accident that the language around violations in active channels only being reported by aggrieved members exists. I want someone who joins a Typelevel project's channel to have the expectation that they won't be harassed, and to know that the community will have their back if they do get harassed (so they won't have to go it alone). On a more technical level I agree with @fommil and @alexandru that FCOP should have a different license. I think it's possible a project could choose to "patch" FCOP to address our concerns, even if the FCOP authors don't agree with the changes. A versioning/naming requirement, to make it clear that a modified FCOP is not endorsed by (or confused with) the official FCOP seems like a necessary first step to me. Most other CoCs use a similar license, allowing derivative works with attribution, and making it clear the CoC is different. In conclusion, I don't think FCOP as currently written fulfills the requirements of having a Typelevel-compatible code of conduct. Some may disagree with my interpretation (believing FCOP to be compatible with my concerns), and others may disagree with my claims on the seriousness of these concerns (believing that FCOP can lead to a welcoming community anyway). I don't claim that my approach is the only way to create a welcoming community. But I do claim that it has been the Typelevel way of creating welcoming communities so far. P.S. The previous comments about doxing and professional sabotage are troubling as well. I can't claim to understand the ins-and-outs of that part of FCOP very well, but it seems like it might be incompatible. For example, was cancelling the Boulder Typelevel Summit an instance of professional sabotage? Signing the open letter? |
fommil
commented
May 18, 2017
•
|
@non I already gave my interpretation of the Professional Sabotage above in response to Alexandru and I assume that is acceptable. FYI because TL-CoC is so hand wavey, I would likely choose to investigate a complaint from a third party at my discretion, but I'd do it at much lower priority than somebody who felt personally affected. You're welcome to do it on my behalf if such a thing ever happens. I don't see how FCOP changes this except to be more honest. Obviously I'd do my utmost under any complaint but there's also a possibility that I'd just pull the plug on the CoC (and therefore Typelevel membership) if a situation got too complicated to deal with, because life. I'm a human with limits. I also don't think any of these imaginary scenarios we're discussing are in any way relevant to my experiences of managing the ensime community (look for words like "extremely draining" above to see where I'm coming from) so I think we need to be realistic about what maintainers are prepared to commit to. If anything even remotely as complex as Matthew Garrett's example came up I'd probably just shut down all comm channels and tell people the only way they can talk to me is a PR with a signed AGPL CLA, on gitlab, because I've had enough and I'm basically giving up on humanity. I honestly think that's fair. |
jdegoes
commented
May 18, 2017
Most COCs are not locked down like FCOP. They are completely open-ended and do not impose any restrictions on consequences. If FCOP were to prevent any consequence for any kind of professional sabotage, for example, then leaders would not have the option of imposing any consequence, no matter the circumstances or the identities of the involved parties. I'm sure you can imagine the kinds of havoc that GamerGater-type folks could wreak on people's careers if given free reign to do so without any consequence. Instead, FCOP allows consequences in the case of professional sabotage, but it's up to the leaders of a community to exercise good judgement and take into consideration all the factors that we cannot know in advance—hence the need to accept subjective human judgment. Rules and regulations cannot replace humans, at best we can localize he need for human judgment. Penalizing FCOP for being explicit about what is allowed implicitly by other COCs makes no sense.
I don't have to disprove your assertion, because that's not the way assertions work. You have to prove it. |
jdegoes
commented
May 18, 2017
•
Please point to the exact line in the Typelevel COC which guarantees that every single report of any incident will be thoroughly investigated. You can't point to such a line because it doesn't exist. You're attempting to hold FCOP to a different standard than you hold the Typelevel COC—and penalize FCOP for being precise about what is not even discussed in the Typelevel COC. As someone who has organized dozens and dozens of events (meetups and conferences) and moderated dozens of open source communities, the idea that every project must "commit to investigating third-party reports in all cases" strikes me as overly simplistic. Some people will complain about public displays of affection (especially in same-gender relationships). Others will complain about good-natured ribbing between friends. Still others will complain about behavior that does not affect them but which makes them feel uncomfortable (such as body piercings, wearing of collars, etc). FCOP does not guarantee an investigation in all these third-party cases, because the cost of an investigation is very high—higher for FCOP than for most because of the strong guarantees it provides members. Investigation requires appointment of an arbiter, which ideally should have no vested interest in the outcome of an arbitration. It requires collecting statements from both parties to the incident. It requires collecting and documenting witness reports, in the event there is a dispute about what happened. All of these are real costs usually born by unpaid and unappreciated volunteers, and in most of the above cases of frivolous reports, they are completely unnecessary. The fact is that the Typelevel COC does not guarantee an investigation, and that even if an investigation is guaranteed, that is pure security theater since an investigation is not guaranteed to produce a good outcome. Adding a guarantee of investigation, in either the Typelevel COC or in FCOP, merely increases the cost of governing a community, while contributing in no way to the protection of its members from harmful behavior. A community acting in good faith will exercise its judgement carefully and ignore only truly frivolous third-party complaints, while a "guaranteed investigation" clause is pure theater because a corrupt community will "investigate" but not in any way that produces a good outcome. This is a case of security theater and penalizing FCOP for being explicit, as well as holding FCOP to a different standard than Typelevel COC is held to.
The Typelevel COC does not even define harassment, but let's leave that one there for now. According to the Typelevel COC, the scope of the COC extends to the following areas:
This may extend to include other venues that are "Typelevel-supported venues –including online venues– and social events associated with Typelevel". Therefore, if a private message is sent — let's say by snail mail — between two members of the Typelevel community, then because the postal mail service is not a "Typelevel-supported venue", the COC does not apply, and therefore the COC does not apply to the private message. FCOP allows each community to define its own boundaries (within reason). It would be perfectly reasonably for an FCOP community to define its boundaries to include all associated Github repositories, all associated Gitter channels, all associated IRC channels, all associated Google Groups, and all associated conferences and events, exactly in the same way as the Typelevel COC has defined its scope. In other words, FCOP implemented at Typelevel would permit exactly the same scope as the current Typelevel Code of Conduct. No difference whatsoever. Therefore, this is another example of holding FCOP to a different standard than the Typelevel COC.
Rather, I'd suggest your analysis reveals an ideological bias against FCOP, because the Typelevel COC does not provide any of the guarantees you deem so critical. So if FCOP is not Typelevel-compatible, then neither is the Typelevel Code of Conduct—which, I might add, has been subjected to no where near the level of scrutiny as FCOP (for good reason, it's too vague and wishy-washy).
Again, there is nothing in the Typelevel COC that prevents a community from banning people for doxxing or professional sabotage. If you disagree, please show me the exact line in the Typelevel COC that prevents banning people for doxxing or professional sabotage. There is no such line, because there is no such guarantee. You are looking for a guarantee in FCOP that no one will ever be banned for doxxing or professional sabotage — under any case, including GamerGaters viciously attacking people — when even the Typelevel COC provides no guarantee. Conversely, there is nothing in FCOP that guarantees a community will ban people for doxxing or professional sabotage. Rather, this is one of several cases that may result in a consequence being applied. Whether there is any consequence at all (let alone whether or not that consequence is banning) depends on the circumstances and the community.
See my above response to @alexandru. As mentioned before, the Typelevel COC does not prevent banning for any of the above — or any other reason, actually. There are innumerable ways you can be banned from a TCOC community, but only a few that could have a consequence of banning in an FCOP community. Penalizing explicitness and precision makes no sense. It will just lead to vague COCs that set poor expectations for participants, result in inconsistent judgements, and may be abused maliciously by corrupt community leaders without any accountability.
Which claim is trivially false since the Typelevel COC provides none of the guarantees you deem so important to being part of the Typelevel family. If you want the claim to be true, then I'd suggest revising Typelevel COC so that it guarantees an investigation for all third-party reports, and so that the scope of the COC extends to all possible environments, whether or not associated with Typelevel. Oh, and also preventing people for ever being banned, under any circumstances, for doxxing and professional sabotage. Then, and only then, will your critique have merit, because at that point, you will be able to hold the Typelevel COC to the same standard you are attempting to hold FCOP to. |
ShaneDelmore
commented
May 18, 2017
|
Is there an unwritten desire for the loose definition as it gives more leeway to the decision maker? Reading this discussion it does feel like maybe there is a desire by some to have a less strict definition and then be able to decide based on the offense (or the offender) what the appropriate action is. If so, we should just call it out. I understand the desire if so, I believe many Judges prefer to have a lot of leeway when assigning sentences and don't like mandatory sentencing guidelines. This allows them to exercise their considerable experience dealing with offenders and deciding what an appropriate punishment is. Unfortunately, we find time and time again that people are not very good at weilding this power and end up providing much harsher penalties to people they deem less attractive, or of some ethnicities, or if they are hungry because it is almost lunchtime. Even if FCOP is not adopted, I believe the precision is is attempting to bring needs to be available in some form or another. |
alexandru
commented
May 18, 2017
|
I do like precision, but it's worth pointing out that the more precise it is, the more legally binding it becomes. At least that's what I think as a non-lawyer. Speaking of which I do hope that all of these COCs we are talking about have gotten reviewed by lawyers. |
fommil
commented
May 18, 2017
•
|
@alexandru if the CoC becomes a legally binding document between me - a maintainer - and the community, then I'm out. I am not prepared to accept any legal or financial liability for my volunteer work. If anything there needs to be a disclaimer that says it is on a volunteer basis only. |
jdegoes
commented
May 18, 2017
FCOP prescribes no actions at all. For any behavior deemed a violation, the community is free to decide on no action, or maximum action (a temporary ban). I think going the route of prescribing specific actions for specific offenses is wrongheaded and will poorly account for the circumstances of every case (including the intention and history of the offender, etc). Where FCOP differs from TCOC is that the classes of behaviors that may be deemed a violation is well-defined. For example, you know that harassment is interacting with someone against their will. This provides clarity and transparency to participants so they can decide whether and how to participate, and guards against selective or capricious enforcement of the COC. I think this compromise — of limiting the scope of judgements, but still depending on them — achieves a balance between giving clarity to participants, discouraging abuses of power, and leveraging human judgment to tailor every action to the particulars of the situation, which we cannot know in advance.
That's incorrect. Whether or not it's legally binding has nothing to do with its precision, and everything to do with whether it's interpreted as an agreement. In fact, in the event a document is ruled as legally binding, a lack of precision opens the door to innumerable more lawsuits, and a lack of any cogent ability to defend against them.
FCOP states in the event the COC is interpreted as a binding contract, the limitation to remedy is a public apology. i.e. if someone sued you, the most they could get is an "I'm sorry." No other COC has such a limitation, so in theory it would be possible to sue someone using TCOC for community-aided defamation, for example, without limitation of liability. I'm talking with a lawyer in June to get feedback on this phrasing and ensure we have a strong guarantee of no liability for adopters of FCOP (and the only such guarantee of any COC). Many who insist on creating unnecessary work for leaders of a project / event have not spent sufficient years in the trenches, unpaid and unappreciated, and therefore place no value on the time of leaders. That's a mistake, because at the end of the day, it doesn't matter what fancy guarantees your COC provides ("every report will be thoroughly investigated") if you can't incentivize anyone to use or enforce it. |
fommil
commented
May 19, 2017
|
@alexandru thanks for suggesting that I update the ensime website with a clarification on my interpretation of the TL-CoC, I have done so http://ensime.org/civility/ |
alexandru
commented
May 19, 2017
|
@fommil in that document you're saying:
So according to this, the LambdaConf 2016 situation isn't relevant because CY is not a member of the Ensime community, however you would consider what happened last year to be professional sabotage and reasons for a ban. You also mentioned on Gitter that you're concerned that the adoption of Typelevel CoC drives potential contributors away, which is why you feel such precision (as provided by FCOP) is important. Well, personally I don't mind using or contributing to projects that don't have a CoC, like Spacemacs, for which http://ensime.org/editors/emacs/learning/ used to say that "We do not advise using Spacemacs as they do not have a Code of Conduct in place". I also don't mind using or contributing to projects that have a reasonable CoC in place, such as Typelevel's CoC or Scala. I do mind your "interpretation" of Typelevel's CoC, because even if Typelevel's CoC does not specify what should happen in this instance, that does not mean that you can do it while still claiming compatibility with Typelevel's CoC. I explained why that is in my reply to @tpolecat here: #74 (comment) @mjg59 made a very interesting point above in #74 (comment) and let me quote it because it's a good one:
In other words you may or may not ban a person depending on the situation (my interpretation of your text based on your use of the word "may"), but by specifying that you would is enough to turn me off from ever contributing to Ensime. AND this is different from being aggressive, or from making racist or sexist remarks. People can and do refrain from those, we are very adaptable depending on context and in case of genuine mistakes or cultural mismatches (e.g. non-English speakers), people end up being sorry, many times they apologise, etc. But I cannot apologise for something I believe in and as I said, if I were to turn back time, I would sign that document again, regardless if CY was a member of Ensime's community or not.Those are my personal beliefs and it's how free speech is supposed to balance society's extremes and we can always go on a tangent on what "professional" means (e.g. unpaid open-source work is not it). People usually contribute only when paid, or when they can claim ownership for what they did. Just an opinion, I guess time will tell |
fommil
commented
May 19, 2017
|
@alexandru you asked me to add some clarifying text on the website, and now I did and you don't think I should? FYI I'm not interested in talking about old versions of the ensime website. I changed my mind about Spacemacs, I was heavy handed and made a mistake. There is now a section for Spacemacs with a technical argument about why I don't support it http://ensime.org/editors/emacs/install/#spacemacs |
jdegoes
commented
May 19, 2017
You may be banned from a Typelevel COC project for any reason whatsoever, because no restrictions are placed on the reasons you may be banned. Avoiding the issue is purely a psychological trick, akin to avoiding the doctor if you cough up blood because you don't want to know what the diagnosis might be. In my opinion, hiding one's head in the sand may provide some emotional comfort, but it won't change the fact of your surroundings. FCOP has the virtue of being explicit about all possible circumstances that are violations. Only violations may result in a ban, but no violations are guaranteed to result in a ban. One of the obvious ways to customize FCOP in a community-specific way is provision of arbitration guidelines that could clarify a given community's view of arbitration and its propensity to apply different kinds of consequences to different circumstances. Arbitration guidelines could specify, for example, that a community will never ban (Scalaz), or that bans will only be used for repeated, malicious harassment (for example). Or even, should one desire, specify asymmetrical treatment of ad hominem offenses based on one's membership in various minority groups (Open Code of Conduct).
No one has asked you to apologize for anything, and everyone here fully supports your right to sign the statement. Speaking as both a conference organizer and a contributor to FCOP, I am friends with a number of people who signed the statement, and many of them spoke at the conference last year, at the winter retreat, or will speak soon this coming May. The professional sabotage provision provides a means of protecting members of the ENSIME community (for example) from other members who seek to maliciously do their career harm. @fommil has cited denigrating the skills of contributors in Reddit threads, but I assure you that is far tamer than what has been done to some others (e.g. Larry Garfield, who was accused of being a slave owner and human trafficker — claims without a shred of merit — all for his consensual Gorean lifestyle). No provision of FCOP provides any guarantee that any action will result in a ban. At most, FCOP allows a community to temporarily ban people for certain classes of actions. If that ability makes you uncomfortable, then I would emphasize again that the Typelevel COC permits innumerable more ways to ban you. That it does not discuss them may put your mind at ease, but I would argue that a rational interpretation of these facts should result in the exact opposite effect, because vagueness means you can be banned for any reason whatsoever. All communities depend on trust, and there's no getting around that. FCOP provides a little structure and a lot of precision that helps give people clear expectations, provide accountability, and guard against abuse—but like TCOC and all other COCs, you do have to trust the community in order to invest your time and effort into it; to trust they will treat you as they have represented. Regardless of the COC, your participation in the ENSIME community is going to come down to trust between you and (e.g.) @fommil. Thinking that we can avoid the need for trust by phrasing things in vague or deceptive ways, or by not discussing unpleasant scenarios on grounds we don't want to think about them, is, IMO, ultimately mistaken. |
mjg59
commented
May 19, 2017
As a result, FCOP makes it impossible to pre-emptively block individuals from a covered community even if they've engaged in persistent harassment in other communities. |
sullivan-
commented
May 19, 2017
Are you suggesting that a community where it is not possible to preemptively block individuals should not be eligible to be a Typelevel project? Or are you just arguing the merits and limitations of the FCOP? |
fommil
commented
May 19, 2017
|
@mjg59 you're describing a kind of social cartel. I'm not entirely sure how I feel about that. But if there was reason to believe that somebody from another community was going to cause harm - Community Sabotage - to ensime then I believe I would not be breaking my word to the ensime community to ban that person. It's also exceptionally unlikely to happen, your examples are really corner cases whereas I'm concerned with the day to day, week to week, matters. |
mjg59
commented
May 19, 2017
|
@fommil Community sabotage as defined by FCOP doesn't include harassment, so you're not entitled to ban them preemptively. It's not unheard of for communities to refuse entry to individuals who have engaged in harassment in other communities (see the recent discussion in the Kubernetes community, for instance), so I'd disagree that it's exceptionally unlikely or something that doesn't have to be thought about. |
mjg59
commented
May 19, 2017
|
@sullivan- A stated goal of Typelevel is to provide a friendly and welcoming environment. If a CoC makes it impossible for covered communities to preemptively block people with a proven track record of acting counter to that, I think there's a conflict between that goal and that CoC. |
sullivan-
commented
May 19, 2017
So you think that giving admins the ability to preemptively block people makes the community more welcoming and friendly. What if the admin is perceived to be biased and discriminatory within the larger community? Wouldn't giving such an admin that kind of power make the community less welcoming and friendly, at least to the people that feel discriminated against? |
fommil
commented
May 19, 2017
|
@mjg59 firstly, I believe in Rehabilitation. Secondly, I don't think Typelevel should be proactively banning people who haven't engaged in anything as serious as Community or Professional Sabotage. The moral bar for joining the Typelevel community is all of a sudden close to sainthood. I barely qualify as Civil, if we aren't allowed to forget the past, and neither do half the people here. |
jdegoes
commented
May 19, 2017
|
@fommil @mjg59 All threatening behavior and some types of harassment are illegal and can be preemptively banned under expectation of further illegal behavior ("the safety clause"). Bugging someone on Twitter is probably not good grounds for preemptively banning someone, IMO, and anything serious will rise to the level of being uncivil. Someone's behavior on Twitter or flame wars in a forum, with their quite different (and more liberal) terms of use, is probably not all that predictive of their contributions to an open source project governed by FCOP, and people are quite capable of behaving differently in different communities. |
mjg59
commented
May 19, 2017
|
@sullivan- A community leadership that behaves in an unfair way will be able to do so under the FCOP as well - there's nothing stopping them from making false accusations. The presumption has to be that anybody leading a community is doing so in good faith. But it's impossible to make a community welcoming to everybody. If you're welcoming to harassers, people who have been victims of harassment will feel unwelcome. At some point you have to prioritise. |
mjg59
commented
May 19, 2017
|
@fommil I don't believe that having engaged in inappropriate behaviour in other communities should automatically result in someone being prevented from participating in other communities, but I do believe that it should be possible for communities to take that into account. If someone has repeatedly driven people out of other communities and has shown no sign of having improved their behaviour, I think that's a legitimate thing to be concerned about. |
mjg59
commented
May 19, 2017
|
@jdegoes If someone engages in harassment in a multiple professional communities (without rising to the threshold of engaging in illegal behaviour), FCOP does not permit another community to preemptively bar them. |
sullivan-
commented
May 20, 2017
I'm confused as to why you are able to use this minor difference between the two contracts to your advantage, but I am not. Is it not true that having a CoC that restrains community leadership from acting in a unfair way would be a good thing? I am not pretending that FCOP will prevent all bad behavior from leadership. It certainly does protect the community from this kind of behavior much better than the TL CoC does.
That's quite a presumption! Are you certain that a potential contributor is going to feel the same way? Because if they don't, then your reasoning behind what makes your community friendly and welcoming is utterly flawed. It is not important that you and the community leaders think the community is welcome and friendly, it is the community members themselves - both potential and existing members. I haven't seen anything in the membership criteria or the TL CoC suggesting that community leaders are bound to act in good faith. Why would any outsider looking in assume as much? I don't see any guidelines discussing what should be done if a member of the leadership of a Typelevel project acts in a biased or unfair way. Or guidelines for how a community member should respond to an incident like this. You've got a long list of projects with the Typelevel label on them, with diverse leadership. Are you just going to rely on those leaders always acting in good faith, their better judgement never being clouded by their biases or prejudices? |
mjg59
commented
May 20, 2017
A CoC that blocked anybody from ever being banished from a community would prevent community leadership from acting in an unfair way even more than the FCOP does, but would also prevent dealing with any kind of harassment inside the community. So there's a tradeoff - you grant community leadership the power to make decisions about whether certain people should be permitted to remain in the community, and you trust that they'll use that power judiciously. If potential members don't feel that they can trust the leadership to banish harassers, the community will be less welcoming to them. But if you trust your leaders to behave reasonably when it comes to determining whether someone's behaviour within the community warrants their banishment, why do you not trust your leaders to behave reasonably when it comes to determining whether someone should be permitted to join the community in the first place? |
jdegoes
commented
May 20, 2017
That's not really true, because FCOP doesn't require them to have engaged in illegal behavior to be deemed uncivil. If the community credibly believes they are there to sabotage the community or members of the community, or if the community credibly believes there's a real safety risk involved (not a risk of "discomfort"), then they would deem someone uncivil. Preemptively banning people who got into heated discussions on Twitter or on some other OSS project is not welcoming, but rather, very exclusive and very threatening, because it judges people before they've been given a chance to prove themselves, and incentivizes members who don't like you to dig into your personal life for anything they can use against you (which has happened!). If someone with a temper and a propensity to insult others comes into an FCOP community, and will not behave themselves, you can reactively ban them based on their actual behavior, not some hypothetical concern that may or may not materialize. In practice, people can work around bans trivially in both online communities (fake usernames) and offline events (pseudonyms). So this obsession with preemptively banning people is not only exclusive and threatening, but ultimately useless against anyone who is actually malicious. The focus, IMO, should not be on banning left and right for every little thing, but on helping people find a way to communicate in a mature and professional fashion, and to resolve differences and clarify intentions peacefully and with respect for everyone involved. |
jdegoes
commented
May 20, 2017
FCOP serves as a statement of intent, and while you still have to trust leaders, at least you know how you have to trust them and exactly what they are asking for. This clarity has real value to some people who are rightly afraid that investing in a project may mean being kicked out for unknown and unknowable reasons, because it gave someone "warm fuzzies"; it may mean others who don't like you go on witch hunts for anything you've ever said or done (public or private) so they can smear you and get you kicked out; it may mean that saying the "wrong" word or sharing the wrong article gets you publicly humiliated, or worse, fired from your day job. All of these things have happened in open source projects that became politicized and cliquish, with power abused to favor the few—sometimes maliciously, sometimes not. A COC that is obsessively concerned with giving unlimited trust and unlimited powers to a few gatekeepers with no clarity, precision, or transparency on when, how, or why those powers will be used is naturally going to spook people away from contributing—as you have seen in this thread. A COC that tries to provide a little structure and balance has the potential to reduce this concern and help clearly communicate the intent of leaders to not use their powers capriciously, maliciously, or ideologically. |
mjg59
commented
May 20, 2017
Harassment is not something covered by either professional or community sabotage, so as far as I can tell it is really true.
I'm talking about preemptively banning people who've engaged in sustained harassment in other professional communities.
A CoC that makes it impossible to pre-emptively bar people who have previously harassed existing community members is naturally going to spook people away from contributing.
There are people who will not join any community under the FCOP. What evidence do you have to support the idea that FCOP is more welcoming than any other CoC? In any case, FCOP does nothing to prevent the growth of cliques - there's no requirement that the arbiter be independent, and so a community covered by FCOP could easily judge two competing harassment claims in a way that supports the existing power structures rather than bringing about a just resolution. You can't make a community trustworthy by writing rules. |
jdegoes
commented
May 20, 2017
Are you claiming that harassment cannot be a tactic used to sabotage a member's career or sabotage the community, and that harassment can never be considered as evidence of physical danger?
A COC that encourages shaming people for their personal beliefs, or which encourages bans or professional sabotage based on feels-of-the-day, will spook people away from contributing. Most people care about how they are actually treated, not about how they might hypothetically be treated based on a subjective, incomplete, invasive audit of a third-party's personal life history. This mentality of preemptively and aggressively auditing people's life history to classify them as saints or demons, and then treating the latter as contaminated and refusing to work with them in any fashion, is not universal. Some communities will have this mindset. Other communities will have a more liberal mindset focused on helping people develop better communication skills. Both types of communities are fully capable of ensuring people behave themselves professionally.
Every COC repels different audience, so I'd never make that claim. There's a sizeable audience of people who will treat others very well who will be repelled by vague, imprecise COCs that provide little structure, no transparency, and no accountability, and which further encourage threatening behavior that has the potential destroy the careers of members. The needs of this audience are served by COCs like FCOP.
Of course not, but you can make a community transparent and accountable to its members. We have a judicial system that follows a process for a reason — not because it lessens the need for trust, but because it provides transparency about the process involved, and allows people to hold the system accountable to that process (even if, in an OSS community, that's simply by saying, "Hey, looks like you're not doing what you said you'd do"). In my opinion, your ideals are best realized by a COC that provides no transparency and no accountability. If you want the ability to do whatever you want based on any feelings you might have that day, why not just come out and say that? This will help people better inform themselves about whether or not participating in your community is right for them. |
fommil
commented
May 20, 2017
|
Just a data point: ensime got an extra $75/month in sponsorships, and a thumbs up from somebody who said they'd never contribute to a TL project, on the day I clarified my intent to never over-reach. Pretty big coincidence if it's not related. |
mjg59
commented
May 21, 2017
I'm claiming that there is harassment that does not fall into these categories, and if there weren't then you wouldn't have needed to independently define harassment.
Sure. And if a community behaves in that way then that community will suffer as a result - just as a community under FCOP will suffer if it acts in a biased manner. If your leadership isn't trustworthy then imposing additional rules will not make them more trustworthy.
FCOP does not do this. A bad actor leading an FCOP community could produce a fake harassment allegation, choose to act as arbiter themselves (or appoint a co-conspirator) , and provide a fake anonymised account of the accusations. You haven't prevented bad actors from behaving badly, you've prevented good actors from acting in the interests of their community. |
jdegoes
commented
May 21, 2017
Well, yes. Technically, harassment includes saying hello to someone who doesn't want to talk to you. I think preemptively (or even reactively) banning people based on this is an example of cop culture, and it'll scare away far more contributors than it attracts. People don't want this drama, they just want to focus on the technology, in an environment free from hostility that encourages people to be adults and professionals. Those few who want to turn their open source projects into science projects for radical left politics are welcome to do so, so long as they don't force everyone else to.
Not to sound like a broken record, but the point is not to make leadership trustworthy, but to be transparent with the community about what it is they're supposed to be trusting them on, which provides a way for members to say, "Hey, you're not doing what you said you'd do," — the essence of accountability. When all you said you'd do is whatever the heck you felt like doing that day (which is No Code of Conduct or a vague and imprecise one that doesn't mean anything), well, that's as opaque as dirt and there's nothing to hold you accountable to. We've all seen how that plays out in open source projects, and it's always the contributors who lose. |
mjg59
commented
May 21, 2017
FCOP explicitly defines a set of behaviours that count as harassment which may be used to justify the banishment of a community member. If someone regularly engages in such behaviour in other professional communities, FCOP does not allow a covered community to pre-emptively block them from entering said community unless that behaviour is illegal or could be classified as community or professional sabotage. It's clear that not all harassment as defined in FCOP is community or professional sabotage, since otherwise there wouldn't be a separate definition of harassment. Individual A was a member of professional community B, which did not have a code of conduct. Individual C engaged in behaviour that FCOP would define as harassment, but A had no recourse. Individual A joins professional community D, which is covered by FCOP. C continues harassing A in community B. C then attempts to join community D. FCOP does not permit the leaders of community D to prevent C from joining. If C continues to harass A in community B but does not do so in community D, FCOP does not permit the leaders of community D to banish C because harassment in community B does not occur during active participation.
The issue is not whether community leadership does what they said they'd do, it's whether the community trust their leaders. Acting in a non-transparent way reduces that trust and provides an incentive for members to either replace the leadership or fork the community, and so any community leadership that consistently acts in a way that depletes that trust will find themselves without a community. You don't need a CoC that optimises for that, it's self-correcting. |
fommil
commented
May 21, 2017
|
This has kind of digressed significantly. @mjg59 are you a member of the typelevel / scala community or are you just here to argue? John has contributed significant advances to scala fp and typelevel so his opinion matters as much as any other member of this community. But if you're not interested in scala FP I request that you take this discussion elsewhere. |
|
My initial reaction to this proposal was "oh hell no" as I don't think that typelevel should have any interest in associating itself any more with lambdaconf which we have tried to distance ourselves from in the past. After reading through much of this discussion, and seeing some of the ideas behind this CoC, my vote remains "oh hell no". I do not think that typelevel should approve this. |
jdegoes
commented
May 21, 2017
|
So let me get this straight: instead of arguing that FCOP is incompatible with Typelevel COC, you instead wish to argue that because I am involved with both FCOP and LambdaConf, and that you do not wish to be associated with LambdaConf, therefore you cannot be associated with FCOP? Does this attitude of yours extend to the contributions I have already made, and the future contributions I intend to make, to Typelevel projects? How about the contributions that my company owns and presently organizes under Typelevel (Matryoshka)? How about the contributions from people who are friends with me, or people who attend LambdaConf events? How many degrees of separation are required to satisfy your quest for "distance" with LambdaConf? This is an example of the kind of political drama that scares people away from investing their time and energy into politicized open source projects. Speaking both personally and professionally, I don't care what your feelings are on the LambdaConf controversy. It's time for the whole community to act like adults, put their political differences aside, and work together in non-hostile environments to make Scala the leading choice for pure functional programming on the JVM. |
travisbrown
commented
May 21, 2017
|
@jdegoes Most (maybe all?) of the people who founded Typelevel in its current form don't see "political" as a slur. Not "political" in the sense of electoral politics, of course, but in the sense that Typelevel is and has always been actively open to making non-technical decisions to advance non-technical goals. If you don't like that, you can stay away, or you can work with the community to clarify, refine, or even change those political goals. I'm not in a position to say what Typelevel's position is on this particular question, but I think I definitely can say that walking up with "okay grow up, let's drop the political bullshit" demonstrates at best a pretty shallow understanding of the history of Typelevel and at worst an attitude that's antagonistic to the values of the organization. |
travisbrown
commented
May 21, 2017
|
@jdegoes This is getting off-topic, but obsessively screenshotting and reposting (out of context) the tweets of someone who has blocked you on Twitter is arguably pretty close to harassment. |
johnynek
commented
May 21, 2017
|
I also don't want to accept this proposal. I am concerned that the majority of the arguments in support of accepting seemed pitched at people who fear being kicked out of a community rather than convincing new people that they won't have to deal with sexism, racism or overt hostility in typelevel endorsed projects. Sadly no woman that is active in typelevel projects has commented (that I see) but several women active in programming in the past have told me they moved away from scala because of how hostile the community was. While FCOP probably may appeal to people who don't want to talk about these issues, or call them politics, I disagree. I don't think disagreeing about equal rights for all humans is something that should be on the table of legitimate differences of opinion that people should be expected to overlook in typelevel projects. Not everyone has to share this view, though I hope they do, but I think the mission of inclusion, especially of those that have felt harassed and excluded from scala in the past, is a mission of Typelevel. I don't think John agrees with this mission, or is at least very coy about saying so. I fear that the FCOP is crafted to protect harassers more than support Typelevel's mission of inclusion. I wish projects the best, but if they don't want to actively work to improve scala's image as a community hostile to women and accepting of cruel communication, they should work outside of the Typelevel umbrella. |
fommil
commented
May 21, 2017
|
Given that ensime seems to be the only Typelevel sub-community that has required moderation (unless other project maintainers are not admitting it), this entire conversion feels very much like I'm a soldier in the trenches and my generals are making philosophical decisions that don't help me and thinking about unrealistic edge cases. FCoP helps me to reason through a problem, without having to go back to moral principles. Especially it helps put my mind at ease regarding potential problems and means I don't need to waste time discussing it with others. That's very useful, I get brain cycles back to spend on managing our sponsored dev or fixing the CI, and occasionally writing some code. ensime is the only "application" in Typelevel, as opposed to a library, and subject to significantly different expectations from users. This last year I've changed the tone of the contributor/user relationship and things have improved dramatically. I'm getting hassled less, and more people are contributing and enjoying hanging out in the gitter rooms as learners rather than expecting a support line (except now I get shamed because I won't commit to helping every single user instead of spending time with my wife) By making it clear of my intention not to overreach, I hope less people will be put off by the wooly TL-CoC (a real complaint I've had from several potential contributors). More contributors (all of whom are civil) make me happy. More users make me happy too: you might enjoy your job, but you wouldn't do it without pay, right? I'm effectively using FCoP for ensime. I can call it "magical cuckoo land code of professionalism" if you'd prefer... which we can do when John releases a CC-BY version. I'd like the cuckoo code to be officially blessed so I don't have to explain this situation to anybody, and waste even more time. Furthermore, I'm utterly shocked that some of you have interpreted the TL-CoC to justify contacting somebody's boss/manager. I now understand, finally, why lots of scalaz developers won't touch Typelevel with a barge pole and I'm truly embarrassed. I've seen situations escalate to this, from fisty cuffs on mailing lists, and it ruins careers. I'm personally going to request a clarification on that from any TL project I engage with, otherwise I'm not interested in contributing to those projects that carry such a high liability. Let me assure you that I'd sue the bejesus out of anybody if they did anything of the sort to me: you are personally liable for any financial loss or professional standing and it is unreasonable to expect such a penalty regardless of how rude anybody is. We are like a startup who have hit a problem or growth spurt and the directors realise they assumed everybody else had the same plan for the company as them, but they didn't. |
jdegoes
commented
May 21, 2017
I have stated from the my very first post that I want an inclusive community free from all harassment, and FCOP is very clear on the matter, having a stronger anti-harassment clause than TCOC.
Please look at what you have done here. You are accusing me of intentionally constructing a COC to protect harassers (!!!). This is an unfair and untrue smear against my reputation and I request you retract this statement immediately. |
Gabriel439
commented
May 21, 2017
|
Are there programming communities that have historically demonstrated consistent success in being inclusive? If so, what lessons could we learn from them? |
johnynek
commented
May 21, 2017
|
John, I tried to go on a bit: do you agree with:
I think you have a very libertarian view that basically no personal view, that is not discussed in channel, should be grounds for exclusion. I think if I advocate stealing and eating children, or genocide, or supremacy of one ethnicity or nation above another, or any number of things in violation of basic commonly held beliefs about equality, and especially if I am actively working towards those goals, it is relevant. We used to have Godwin's law, and it was hyperbole, but now there are many actual Nazis active on the internet. I want to see Typelevel draw some line, but I feel that no private belief is too monstrous for FCOP to render it off limits. Lastly, you are distinct from FCOP. Additionally others, I understand, have worked on it. Me fearing that the bias is set wrong on it is not a smear of your character. This is my opinion about the document. I don't know you well enough to comment on your character. I'm happy to be wrong, and say so, if you let me know that you do want to support the mission of inclusion of women and others that are underrepresented in programming communities. I didn't read that and have feared you were calling that extreme left wing politics. I'm happy to be corrected. |
mjg59
commented
May 21, 2017
|
@fommil I'm happy to abide by your request that I stay out of this - I just wanted to say that providing guidance about how you'll interpret a CoC and the process that you'll be inclined to follow in doing so is something that's orthogonal to the CoC itself. FCOP conflates the two, and in the process restricts community leaders from doing things that they may feel are in the best interests of their community. Yes, many of the examples that I've used are corner cases, but if one ever does appear then FCOP leaves you forced to violate your own CoC if you want to do the right thing. That's suboptimal. I think a solid set of best community practices around CoC interpretation and enforcement would be of immense value to the wider community, and I see no harm at all in a community providing that clarity up front. I think providing that information alongside a CoC is much more valuable than attempting to write it directly into the CoC (eg, communities that differ in certain cultural norms may share the same goals and wish to encourage the same behavioural standards and so may wish to use the same CoC - however, their differences may mean that enforcement would look very different, and so having a separate document describing the process they'll use there is of value) |
jdegoes
commented
May 21, 2017
|
I absolutely believe there is too much hostility in the Scala community. I'm not sure it's particularly directed against women, although it affects women as well. I am very passionate about reducing hostility and increasing the accessibility of FP in Scala, including to women and all the others put off by said hostility and in-fighting. Having recently donated $40,000 toward this goal (much of it going toward scholarships for women and POC), taught and mentored numerous women and other minorities in functional programming, and labored long and hard to make high-quality accessible content available to everyone who wants it, I feel these credentials speak more strongly than any amount of talk. I personally know everyone who worked on FCOP and all of them are passionate about harassment-free environments (and also concerned about overreach). Whether you are smearing me individually or any of them collectively, I do not appreciate it at all. If you feel FCOP is incompatible against some Typelevel goal that is not written down anywhere, then I think the most constructive thing to do is to not impugn the reputation of those with whom you disagree, but rather, to make that goal explicit so the question of FCOP compatibility is decided in no uncertain terms. Smearing the character of people is no way to win a dispute, and merely drags the community down to a place none of us want it to be. |
fommil
commented
May 21, 2017
•
|
I very much agree with @travisbrown's comments (quoted):
The founders have definitely not defined the political goals strongly enough so I'd like to see that refined. I can't (nor can any of the other project leads) enforce a political agenda unless I know what it is. I don't even know if I agree with it in principle at this point, because I literally have no idea what it is after this thread. Typelevel supports pushover Libre licenses such as BSD, MIT and Apache 2.0 without requiring copyleft like MPL and GPL so I can't expect us to have anywhere near the same level of impact on the world as GNU and the Free Software Foundation. However, the commitment to Libre licenses is good enough for me to be involved with Typelevel and I would be happy to reject a proprietary project or contribution from inclusion. Because of Typelevel's political leniency in this regard, I have allowed ensime subprojects to use pushover licenses instead of requiring the GPL, as I would like. Inclusion is a lot less clear. Trying my best to read between the lines, are we saying that the political position on "inclusion" is that Typelevel are prepared to exclude a member who is known to be a casual racist, homophobic or sexist? What else is there (that isn't illegal or community/professional sabotage)? I thought "hostile communication" was a far more common problem in scala to be honest, and it sounds like addressing it head on is something of an elephant in the room. I think we should be clear where the list ends, the problem I've seen is that by leaving it open to (mis)interpretation we exclude people who don't want to sign up to an ambiguous arrangement - especially when the penalty can be as serious as "a well known figure in the scala community will email your boss with a formal complaint and it could affect your family's livelihood" (which I want to be outlawed, btw, I am not prepared to put my time into this if people are supporting this sort of nonsense). Being clear on who we're prepared to exclude from the outset is not incompatible with FCoP, it's literally a footnote. The point is to let members of the community know what to expect, not to draft a watertight legal document. |
mjaeckel
commented
May 21, 2017
|
I would like to preface my contribution to this discussion with a few disclosures: First of, I act as a volunteer reviewer of FCOP. I know, and respect, John De Goes as a man of great integrity, and I would never have offered my input to help make FCOP the gold standard for governing professional conduct in the technology industry if I had any reason to believe that he, or his organization, would not champion safe, friendly, and harassment-free communities for women and other marginalized groups. Second, I am a female senior software developer who has been involved in numerous developer groups and communities for well over a decade. I am, however, not actively involved in the Scala community — yet. I purposely emphasize the word yet because I am, truthfully, on the fence about becoming more involved based on some of the interactions I’ve perused in this thread. I respectfully acknowledge @fommil’s request for outsiders to refrain from further derailing the thread, but I would, nonetheless, like to dip a toe in the water, so to speak, in order to offer my perspectives as a woman who is considering whether or not to invest in this community. The main issue which I would like to address is that of the Scala community being perceived as hostile to women. Please allow me to unequivocally state that I’ve never experienced any hostility from the male members of any development community. While I recognize that my experience may not be typical, it is also true and valid, and, as such, my hesitation to become more involved with Scala is not based on concern over gender bias or overt sexism. Instead, I’m averse to becoming involved in any technical community or event that uses one of the poorly written, intentionally vague and discriminatory codes of conduct du jour which are being touted as exemplary. As a woman in tech, it concerns me that a fellow member of the community could dig up any juicy morsel from my social media accounts and use that as justification to ostracize and shame me. As a woman in tech, it concerns me that a fellow member of the community could get me fired from a job, cost me an account, ruin my business, or potentially ruin my relationships and professional reputation. As a woman in tech, it concerns me that I won’t have any recourse and that the leadership of a group could simply ban me without even offering any valid explanation. This is exactly what FCOP is attempting to prevent. By design, its intent is to employ appropriate penalties to address violations that occur during active participation in a specific community, without relying on preemptive exclusion. I personally consider this approach to be more tolerant and welcoming, whereas the way in which some commenters have interpreted the TL CoC makes me feel unsafe, and fearful that they, too, would discriminate against me. To conclude: As a woman in technology, it’s extremely important to me to ensure that other women feel safe and respected in a group. In fact, I’d like for anybody who chooses to volunteer time and effort to contribute to an open source project to feel safe and respected and valued. We should all be able to do what we love — write code, gripe about challenging problems, troubleshoot bugs — without worrying that something inflammatory or inane or inadvertently offensive that we may have uttered many years ago could be used as leverage against us in the here and now, to ruin our reputations and destroy our careers. |
stefanruijsenaars
commented
May 21, 2017
|
As someone who's very active in another large open source community that is now going through a similar discussion over Codes of Conduct, I have been watching this issue with great interest, and just wanted to follow up on @mjaeckel's comment with my own experience (while remaining respectful of @fommil's request for outsiders not to derail the thread): My open source community is now actively politicizing in a way that has already hurt some people's careers (people who were not guilty of any harassment). This has led to high-level contributors with no interest in political drama and smear campaigns to leave the project, and others (including myself) to reevaluate their involvement. I am now looking for other open source projects to contribute to (including Scala-based ones), but being politically more of a centrist, I would actively stay away from communities that exclude FCOP projects based on the kind of hostile, exclusionary rhetoric expressed by a small group of people in this thread. I agree with @jdegoes that the political goals expressed by some of his louder detractors here (@travisbrown, @mjg59, @johnynek, @stew) point to an an extremist political agenda that considers moderates like me, or right-leaning folks like Marlene, "political enemies". However, I do appreciate @travisbrown's honesty in #74 (comment) (having read the full Twitter thread, in context) where he makes very clear that, as far is he's concerned, my centrism is not welcome in Typelevel. |
alexandru
commented
May 21, 2017
•
As a Typelevel member that has had some contributions to Scala and Typelevel, I personally like seeing @mjg59's perspective here. I also appreciate seeing the perspective of @mjaeckel and @stefanruijsenaars, which are in support of FCOP. As long as somebody has reasonable arguments, they should be welcome to speak their mind. |
Yes, that is correct
no
more
Those entire issue is political drama that could have been avoided. I'm not sure what you think that you have to gain by filing this issue. I'm pretty well convinced that typelevel has little to gain by the proposal. |
johnynek
commented
May 21, 2017
|
I reject that centrists, as I understand the term from a US background, are unwelcome in typelevel. I consider myself a centrist. I also think we can find broad consensus that digging up someone's past to expel them from a community is generally not okay. Unfortunately, again in the US maybe only, things I have thought were very fringe views have re-entered public discussion. Things like vilification of Jews (use of the ((())) annonation on Twitter), nazi-ism, constant streams of rape threats to women on Twitter, etc... I am not willing to cede the term "centrist" to someone that thinks those are legitimate views and we should all get along and overlook these differences. Now, years ago, this would have been hyperbole, but this literally happens now and I don't want Typelevel to be okay with it. I feel like some are trying to say this is an extreme leftist view, but unless I am living in the twilight zone now (and it somewhat appears I am), these are pretty broadly held values. Excluding folks who are pro-nazi, pro-rape-threat or pro-slavery is perfectly fine (indeed in many countries such speech is not even protected). I don't want to see anyone kicked out for views that are still consistent with a basic agreement on, for instance th UN declaration of human rights. But the internet is a big place and I don't think centrism has to be a big enough tent to fit gamergaters who dox women critical of sexism in video games, nor do we need to accept people actively working to build ethnically pure nationalist movements. I'm not saying FCOP is doing that, and maybe it can even be improved to address such exclusions. A big problem with this debate and many such debates is talking past one another. FCOP proponents are very focused on the individual right to be treated fairly. This of course important. I'm not hearing, and am concerned there is opposition to, the right of a community to exclude folks who are hostile to pluralism and equality (and sadly, such folks exist). Nor is it addressing the very real issue of trolls that have long reputations of harming online communities. I agree typelevel's CoC is not great in this regard, and I appreciate John helping to point that out. But I think addressing these deficiencies is the top priority, not providing a legalistic document that I fear will shield bad actors (such as gamergaters, actual nazis, and men actively hostile to women in tech) more than it will help create communities where folks have an expectation that such behavior, which should be considered beyond the pale, will be rejected. There are many good people who have the belief that no opinion or speech should be limited. I tend to agree with such folks when it comes to government restrictions and I am not seeking to ban them from the internet. But I think typelevel is trying to create a community where basic value of each human, who respects the others, is not in question and we don't welcome folks working against basic human rights. |
|
I also would like to thank @mjg59 for contributing to this thread. I agree with many of the points he makes, and think that he did a great job of exposing thing I would label as technical shortcomings with FCOP that further make me want to continue saying "no" |
jdegoes
commented
May 21, 2017
Why do you think I am concerned? My company maintains one Typelevel project already, and will soon be at a crossroads deciding where we will invest our resources. I will not sponsor, endorse, or approve an organization with extremist political aims that will hurt the participation of contributors and tolerate the malicious destruction of the careers of professional software engineers. I don't believe Typelevel is such an organization, but as we have seen on this thread, we all have very different views about this. We all need clarity. It's time for Typelevel to decide what it wants to be when it grows up. |
jdegoes
commented
May 21, 2017
As far as I am aware, there are exactly zero Scala programmers in the world who vilify Jews, promote national socialism, or engage in rape threats to women (all of which are illegal somewhere, and most of which are illegal everywhere, and are already extensively covered by FCOP). Rather, all the real world cases are programmers being excluded for being conservative (including being banned from multiple tech communities), programmers being excluded for being Gorean, programmers being persecuted for questioning whether 4 year olds should transition, and similar. These are the actual issues facing programmers, not the imaginary ones that you list.
Any community could layer on restrictions on participation in FCOP; they just have to be transparent about it, which is all that is being asked for by concerned parties. Want to ban nazis, slavery apologists, and so forth? Fine, then just be explicit about it, rather than hiding behind a vague COC. These restrictions need to be clear on what they mean. Goreans have been accused of being "misogynists" and "slavery apologists", though everything in Gor culture is consensual. Neo-reactionaries have been accused of being "Nazis". People who have expressed concerns about the unbounded growth of gender pronouns have been accused of denying basic human rights to non-binary gendered individuals. People who believe there might be small differences in the distribution of IQ across sex or "race" have been labeled misogynists or racists. Don't expect everyone to agree on these issues, because they won't. |
johnynek
commented
May 22, 2017
|
thanks for clarifying John. If the concerns of Goreans and Neo-reactionaries are the real issues and antisemetism and sexism are non-issues according to the advocates of FCOP, I'm more confident that Typelevel should not be supporting the FCOP. |
jdegoes
commented
May 22, 2017
|
You're completely misrepresenting me. I never said antisemitism and sexism aren't issues, only that the list of "problems" you are claiming to solve (Nazis and rape threats) are not problems in the Scala community. Nazis and rapists aren't invading our community, and extreme issues like this are already dealt with by FCOP, so it's disingenuous to say these are the reasons you object to FCOP. But conservatives and people who choose some consensual lifestyle (like Gor) have and will again be excluded, not for any harassing behavior, but purely on ideological grounds. In your zeal to solve imaginary problems that are already mostly or entirely solved by FCOP, don't forget the real issues that contributors are facing today. |
mjaeckel
commented
May 22, 2017
|
As both a reviewer and female proponent of FCOP, I can assure you that it most certainly does not regard anti-Semitism and sexism as non-issues. If an aggrieved person file a complaint against an active member of an FCOP community for anti-Semitic behavior or statements, the complaint will be reviewed objectively and an arbiter may be appointed to speak to all parties and witnesses. If the arbiter accepts the complaint as an official violation, the violator will, at a minimum, be asked to apologize or to undergo counseling or mediation. If the offense is more egregious, the person may get banned from the community. The same holds true for sexist, racist, and homophobic conduct and/or speech. You appear to be deliberately misconstruing John’s statements based on your own preconceived notions. In my humble opinion, this is not conducive to the conversation. |
mjg59
commented
May 22, 2017
|
@mjaeckel I think a more precise way of putting it is that FCOP does not regard anti-Semitism and sexism as issues as long as they take place outside the covered community and are not regarded as criminal in the community's jurisdiction. Members who are subject to such anti-Semitic or sexist behaviour from another community member during inactive participation will have no recourse under FCOP. |
jdegoes
commented
May 22, 2017
|
@mjg59 Like Contributor Covenant, the Drupal Code of Conduct, and the Typelevel Code of Conduct, FCOP applies by default to the space of the community. Communities are free to extend the scope to other places in space or time, as noted in the FAQ, but broadening such a strict COC as FCOP to "all spaces and all times" would mean nearly everyone would be guilty of some violation or another, so that is not the default. |
mjg59
added a commit
to mjg59/fcop
that referenced
this issue
May 22, 2017
|
|
mjg59 |
4c6bb8c
|
This was referenced May 22, 2017
mjg59
added a commit
to mjg59/fcop
that referenced
this issue
May 22, 2017
|
|
mjg59 |
b2687db
|
mjg59
referenced
this issue
in fantasylandinst/fcop
May 22, 2017
Closed
Allow communities to define active participation #104
mjg59
added a commit
to mjg59/fcop
that referenced
this issue
May 22, 2017
|
|
mjg59 |
79c6bf7
|
adrienne
commented
May 22, 2017
•
|
As a data point from a community-adjacent outsider (i count as friends and colleagues a number of FP folks, including Typelevel participants & at least one maintainer): Mr. De Goes leaves out of his equation all of the women who have explicitly criticized the FCOP. He calls us liars and harasses us on Twitter. So while he would have you believe he's not trying to speak for All Women, the only women's viewpoints he ever mentions are the ones who agree with him. I would certainly not take Ms. Jaeckel's word as gospel, about what makes women in tech feel safe or unsafe. |
|
This discussion is not converging. I think it's time to suspend for lack of consensus. |
|
Thanks to everyone for their input on this issue. At this point I think the main arguments on all sides have been made and there has been sufficient time for clarifications to be requested and provided. As is evident from the above, there is clearly not a consensus in favour of accepting this proposal, so it will be discussed by the Typelevel core group (#16) and we will respond here in due course. This thread will be locked while that happens. |
jdegoes commentedMay 13, 2017
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.