Draft Code of Conduct

[Paul Chiusano]

Hi everyone,

I have been giving this a lot of thought and considering the feedback that people gave on this list, as well as some feedback that people have sent me off list. (I have encouraged people who contacted me off-list to post directly here, but not everyone felt comfortable doing so for various reasons.) I've also been considering the nature of the Scalaz project, its history, and its diverse set of contributors and users in putting together this draft.

I care deeply about this project. Not only is it a super useful library, I think it's become a haven for legitimizing the use of purely functional programming in Scala, which as we all know is strictly optional in Scala! Not everyone here remembers the "bad old days", where people interested in doing FP in Scala were sometimes labeled impractical "academics", were told that Scalaz wasn't "production-ready", and anyone using it risked being branded "elitist", not a "real-world programmer", and other FUD like this. It is great that we are (mostly) past this, and I'd very much like for things to continue without division, with people working toward their common goals of building awesome support for doing FP in Scala.

Now, before I show the draft, I have a couple thoughts:

* People are always going to have some differences of opinion about what constitutes good communication, and such things may be influenced by one's culture and background. The recent discussion on this thread about swearing might be considered an example of these differences.

* Egregious behavior, such as racist or sexist remarks and direct personal attacks, are not cool. If someone repeatedly demonstrates such behavior and ignores feedback, then that should be dealt with (see below).

* But for just about everything else, which isn't so clear-cut, I believe in being charitable and assuming the best about the other person. That is, assume their remarks are not intended to harm, and try to give _constructive_ feedback about how they can communicate better. I don't consider hurling judgements at a person and making threats (of banning, say) to be effective at getting people to change. And even if change is possible in this manner, it's not how I want to achieve it. Though I have my own opinions about how to communicate well, I don't really want Scalaz to enforce those things via top-down policing.

* Why do I feel this way? The Scalaz project has been and continues to be a project developed by a distributed group of individuals, all acting in different roles at different times. It really does not have a "Benevolent Dictator for Life", nor does it have an overarching organization with a clear mandate to enforce rules about how people communicate. In a way, it is "owned by no one", and simultaneously "owned" by all of us who contribute to it and use it. This is something I like about the project, and I'd really like to keep Scalaz as a loose assemblage, with loose moderation except for the most obvious stuff I mentioned above, and encourage people to form sub-communities (for instance, a #typelevel-scalaz IRC channel) if they wish.

  * Recently, I've experienced the other end of the spectrum--the Elm community, which I would consider to be very heavily moderated. The creator of Elm is making great effort to build a very specific culture, and develop "community standards" for how people talk about things even in informal settings (a recent thread debated what term people should use instead of "algebraic data types", which was considered by some to not be beginner-friendly). This is not something I really like, and it's not something I want to see for Scalaz. If people want to form their own Scalaz venues and cultivate a certain culture or way of talking in these venues, then I would definitely encourage them to do so. But I'd like to keep the main #scalaz channel, this list, and the GitHub repo more neutral and just police the really blatant stuff that everyone is in basic agreement is bad.

* The only thing I'd like to avoid if possible is forking the actual code of Scalaz. I don't want political differences in community management to result in having two very similar forks, which will just generate dependency hell for everyone else. So if the GitHub contributors could agree on some norms, that would be good, and that can be a separate discussion which I've already suggested Lars kick off after things settle down.

With that said, I've posted the draft here: 

Gist:

https://gist.github.com/pchiusano/9c32dd98e756d732b05c

Google doc version, if you'd like to add comments inline: 

https://docs.google.com/document/d/1WamKg83QSkHx78S2sxBhBqh0i7WgflU0ogOYHDn8Tlw/edit?usp=sharing

This is just a draft - feedback and suggestions are welcome. Feedback can be positive or negative. If you really feel this misses the mark, feel free to voice that opinion and state what you'd like to see instead.

Cheers,

Paul :)

[Jed Wesley-Smith]

This is an excellent proposal. Thank you Paul for your work on this, it has become a very difficult and emotion laden topic, and you have done a wonderful job of finding common ground and, I hope, repairing some of the fracture in the community.

cheers,

jed

[Grzegorz Balcerek]

Hi,

A few questions/remarks:

What is the purpose of having the first principle "Be excelent"
in the code?  Could you give an example of a statement that would
be inappropriate to include in an email because it would violate
the first principle?  Should I think before sending emails
whether I represent a level of excelence sufficient to
participate in a discussion?

Also regarding the first principle, why do you mention
a "rigorous" discource? I would understand that a discource
should be rigorous in a scientific paper, but not necessarily on
IRC. (note however that English is not my native language, maybe
I misunderstand the word in this context?)

Regarding principle 3. What is the reason of mentioning
newcomers? I imagine that openness to learning could apply to
other people as well.

Still regarding principle 3. I do not think the code should talk
about one possible reaction to "suggesting concepts that go
beyond your basic understanding" as THE way to go. I can imagine
at least one different reaction (reading more about the concepts)
that I would consider perfectly valid.

A more general remark is that I think it would probably be good
to try to include negative statements (do not do this or that)
rather than positive (do this or that) in the code. If you write
positive statements it is easy to overlook (and thus implicitly
discourage) some behaviour that would be perfectly valid and
acceptable (as in principle 3 above).

Ragards,
Grzegorz

W dniu 2014-11-19 15:13, Paul Chiusano pisze:

--
You received this message because you are subscribed to the Google Groups "scalaz" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalaz+un...@googlegroups.com.
To post to this group, send email to sca...@googlegroups.com.
Visit this group at http://groups.google.com/group/scalaz.
For more options, visit https://groups.google.com/d/optout.

[Grzegorz Balcerek]

Regards,

Grzegorz

W dniu 2014-11-19 15:13, Paul Chiusano pisze:

Hi everyone,

[Paul Chiusano]

Hi Grzegorz,

Thanks for the feedback. I want to clarify again that the "Principles" section is not a list of rules that are enforced via policing. With the exception of some of the really obvious stuff in (2) Be respectful and civil, these are just positive statements, things that are considered good, not rules. 

Here are some responses inline -

> Could you give an example of a statement that would

be inappropriate to include in an email because it would violate
the first principle?  Should I think before sending emails
whether I represent a level of excelence sufficient to
participate in a discussion?

I wouldn't talk about it in terms of "violating the principle of excellence". That principle is a positive statement--making the best technical decisions we know how to make and having a type of discourse that leads to such decisions is something that is valued. That is, it is good to be polite and civil, but people should not be so worried about this that they avoid calling out what they think are bad ideas, or pointing out serious problems with a pull request, say.

Re ''rigor", I'd also use your best judgement... if you are chatting informally on IRC, then do so in whatever way you think is natural. If you are proposing a change to some aspect of the library or are discussing the design of a new data type, I would be prepared for that to be a more rigorous discussion. Ideas may be critiqued, dismantled, etc.

> Regarding principle 3. What is the reason of mentioning

newcomers? I imagine that openness to learning could apply to
other people as well.

That is a good point. I can try to reword to make it sound less one sided.

> Still regarding principle 3. I do not think the code should talk

about one possible reaction to "suggesting concepts that go
beyond your basic understanding" as THE way to go. I can imagine
at least one different reaction (reading more about the concepts)
that I would consider perfectly valid. 

Also a good point! That wording (which I stole from the Scala CoC) is too strong. I can reword so it shouldn't sound like this is the One and Only True Way To Respond.

> A more general remark is that I think it would probably be good
to try to include negative statements (do not do this or that)
rather than positive (do this or that) in the code. If you write
positive statements it is easy to overlook (and thus implicitly
discourage) some behaviour that would be perfectly valid and
acceptable (as in principle 3 above).

Ah, I see what you are saying... but I also wouldn't want you or anyone else to feel like if something isn't mentioned as being "good" then it is considered bad or should be discouraged. I personally like having the positive statements in there just because, even though they aren't rules per se, they hopefully capture some things that are valued by people who contribute to and/or use scalaz.

That said, I could also see the argument that most of the Principles section is unenforceable flufff, and the CoC should just be some version of the "Unacceptable behavior and moderation policies" section. If you think that (or anyone else thinks that), don't hold back in saying so. :)

Okay, I hope that is helpful.

Cheers,

Paul :)

[Pascal Voitot Dev]

Hi,

I also prefer positive view to negative. Here, we are just speaking of code of conduct, not law...

Globally, the draft CoC is OK with the little addition proposed by Runar in comments about the case of a moderator being the origin of unacceptable behavior...

Pascal

[David Barri]

Hi

> the CoC should just be some version of the "Unacceptable behavior and moderation policies" section. If you think that (or anyone else thinks that), don't hold back in saying so. :)

I'm in that boat. My understanding of the CoC is that it is something we want in place to prevent and handle a set of unacceptable behaviours, such as sexual discrimination. The addition of positive guidelines, I feel, doesn't align with that goal at all, rather I feel that it puts the CoC one foot squarely in the grounds of social engineering. Social engineering is exclusionary and often asks (demands) that freedom purchase some kind of noble goal. History shows it corrupts. It reduces diversity of personalities. I'm not a fan of social engineering.

Look at part of the recent drama, an imperative was issued, implied enforceable by the CoC, justified by "or else" not suffixing said imperative.

Imagine now if someone is shut down with "HEY! If CoC clearly states that patiently asking for more information is the right way to go." There's no "or else" in that nor is there in the CoC nor is there in the spirit or intention of the CoC. But most people won't know that. Especially people new to the community who don't want to ruffle feathers.

I don't think we should facilitate that kind of environment. I don't actually disagree with the positives in the CoC, they're quite nice. But I think it's egregious when people (no one here, I'm speaking generally) say things like "the only right way to respond/react to blah is blah." No, fuck off, I often don't react like other people do and it's not malicious or ill-intentioned, not even 'wrong'. Over enough situational variety no one does. We should celebrate the fact that we are all different and any statement with "the only right way to" in it is going to be false for a lot of people in the world. Now the CoC in current form doesn't do this explicitly, but it does open the doors for that kind of thinking which soon becomes social pressure and intolerance.

We're giving the words in the CoC power. Power can be misused by anyone with access and the CoC will be accessible to everyone. I believe the CoC should contain the bare minimum needed to achieve its goals.

(I was actually just going to say "Yes, Paul, I'm in that boat" and then ramble ramble ramble. :D)

[Grzegorz Balcerek]

Hi Paul,

Thank you for your responses and clarifications.  However, people that are going to come to scalaz in the future will see the CoC but will not see those clarifications. If the principles are not supposed to be interpreted as a list of rules, then maybe a less "rules-like" wording would be more appropriate? Maybe something that uses "we value" or "we believe" or something similar?

> That said, I could also see the argument that most of the Principles section is unenforceable flufff, and the CoC should just be some version of the "Unacceptable behavior and moderation policies" section. If you think that (or anyone else thinks that), don't hold back in saying so. :)

Without holding back, I am fine with not having a CoC at all :)

Grzegorz

W dniu 2014-11-24 06:01, Paul Chiusano pisze:

[Lars Hupel]

Hi Paul,

> This is just a draft - feedback and suggestions are welcome. Feedback can
> be positive or negative. If you really feel this misses the mark, feel free
> to voice that opinion and state what you'd like to see instead.

I too think that you've put together a good proposal.

There are three points I'd like to see addressed:

1) Not only should newcomers be open to learning, but all people. This
also extends beyond learning, but for the general style of technical
discussions. Just to pick an example: Variance annotations. There's
disagreement on whether we should put them in there or not, but
regardless of which opinion you hold (that's besides the point),
everybody needs to acknowledge that such decisions are always tradeoffs
and that there's no clear winner. Hence, no point in dogmatically
asserting that one is better than the other.

2) In the second principle, the enumeration "regardless of age, ..."
should include "technical background" as well.

3) In the first principle, I share some concerns with Grzegorz. I
wouldn't necessarily include rigour there.

Cheers
Lars

[Cody Allen]

I'm weighing in a bit late, but here are some thoughts I have.

Firstly, thanks a lot for putting this together, Paul C. I appreciate all the work that people are doing to try to ensure that scalaz channels are a safe and effective space for learning, teaching, and discussion.

I too would advise against using the phrase "rigorous discourse". While I don't want to be overly pedantic, definitions for "rigorous" include "harsh" and "violent" which I don't think is really what we'd prefer to see. I love a good healthy learning session or debate, but that's not the type that comes to mind when I think of the connotation of those words.

I think we need to be quite specific about who our moderators and/or community leaders are. Names don't necessarily need to be embedded into the CoC itself, but I think they should at least be linked. One reason I say this is so that the people who are expected to be moderators know who they are. For example, should everyone who is part of the Scalaz GitHub organization consider themselves to fall into this category? Just moderators in #scalaz on Freenode? Is there a difference between the two lists?

But the more important reason I think we need to be specific about who our moderators and/or community leaders are is for the benefit of someone who seeks to address a concern. If someone feels that a member of the Scalaz community is participating in unacceptable behavior, how do they know whom to contact? We should have a list of several possible contacts in case one (or more) of the contacts is involved in the concerning behavior.

I also think that it is worth considering sources such as http://geekfeminism.wikia.com/wiki/Code_of_conduct_evaluations as the scalaz code of conduct is developed. I think we have a great group of people here doing their best to establish a helpful CoC. But let's be honest - active scalaz community members tend to fall into buckets (gender identity, race, etc) that don't face much discrimination. So we could stand to learn a lot seeking out input from people who might have more reason to desire a CoC. I suppose this falls into the principle of "be open to learning" :)

Cheers,

Cody

[Stephen Compall]

On Thu, 2014-11-27 at 21:41 +0100, Lars Hupel wrote:

1) Not only should newcomers be open to learning, but all people. This
also extends beyond learning, but for the general style of technical
discussions. Just to pick an example: Variance annotations. There's
disagreement on whether we should put them in there or not, but
regardless of which opinion you hold (that's besides the point),
everybody needs to acknowledge that such decisions are always tradeoffs
and that there's no clear winner. Hence, no point in dogmatically
asserting that one is better than the other.

This example is neither a prerequisite nor a natural outcome of 'all people should be open to learning'.  So it is not an example of that proposed principle.  I want to call this out because, should the abstract notion you have proposed be accepted as part of the CoC, I do not want people to refer to the example you have given as model behavior for following the principle.

The principle you are suggesting, rather, seems to be encoded in this example, separately from the notion that 'all people should be open to learning'.  So I will address the example, rather than attempting to extract the underlying rule encoded therein.

I don't dispute the premises, so turn to the implications:

everybody needs to acknowledge that such decisions are always tradeoffs
and that there's no clear winner.

They aren't always tradeoffs, and there often is a clear winner, so I acknowledge neither.  We don't have enough information about the variance situation alone to neatly categorize it in the way you have, never mind all long-term design issues.

I think, instead, in most such cases, we merely lack information to determine the clear winner, or a framework for connecting our information to correct conclusions.  To define such discussions as having "no clear winner" is to devalue the research that goes into finding the clear winner, and the justification for declaring it the clear winner, and thus to discourage fact-based design.  This can only work in favor of compromise-based design.

Compromise as a design principle may be right for government legislatures, but it isn't right for Scalaz.  We have the tools at hand to find the right answer, and we're principled enough to say that when there's a right answer, based on fact, the other answers are just wrong.

The best illustration for this is law-breaking instances.  Time and again, people have asked for law-breaking instances to be added, restored, or not removed.  Yet we remove them, because it's right, and when it comes to local convenience versus global reasoning, global reasoning is the clear winner.

None of this needs to be stated in a Code of Conduct.  This is how Scalaz has always operated; observing this devotion to correctness played the primary role in attracting me to Scalaz, and it's what continues to hold my interest.  We're scientists, and while we're human and sometimes prone to feeling protective of our ideas and designs, even when they turn out to be wrong, we've proven willing to acknowledge their wrongness when faced with the facts.

Hence, no point in dogmatically
asserting that one is better than the other.

Even when we don't have enough information, given available information, one is often better.  Now, that may change, or even reverse, once new things are discovered, but that doesn't change that fact!

With respect to the example you've given, invariance in transformers and higher kinds is better than variance, given our current information.  Maybe more information will arrive later to change that outcome.  Maybe new information will just reinforce that decision, or maybe we'll never learn anything else about it.  That's not a sufficient reason not to say we haven't made the right decision, today.

If a Scalaz contributor sees that one alternative is clearly better in a design discussion, they should say so.  You can say, "I am aware of these caveats, a, b, and c, but they do not outweigh the benefits d, e, and f", and form a much stronger position than if you pretend that a, b, and c don't exist.

I have said that it's not necessary to state this in a Code of Conduct.  However, if you want to state it in a Code, you might say,

"Prepare to be wrong, and to be told you're wrong.  Our goal in Scalaz is to become right, factually, not pretend we're right."

This is perhaps just a restatement of the first principle.  (Perhaps the above can clarify what is meant by the "Be excellent" principle.)

2) In the second principle, the enumeration "regardless of age, ..."
should include "technical background" as well.

At this point, I think this is stepping over the line, warranting David Barri's concern about these guidelines:

On November 24, 2014 2:21:32 PM PST, David Barri <japg...@gmail.com> wrote:

My understanding of the CoC is that it is something we want in place to prevent and handle a set of unacceptable behaviours, such as sexual discrimination. <snip> But I think it's egregious when people (no one here, I'm speaking generally) say things like "the only right way to respond/react to blah is blah."

I will summarize my previous message by saying that I'm glad this specific approach to discourse is working out for those who are trying it, but I'm not interested in a Scalaz community that codifies it as the method of discourse.

3) In the first principle, I share some concerns with Grzegorz. I
wouldn't necessarily include rigour there.

For clarity, I will quote the referenced concern.

On November 22, 2014 6:34:42 AM PST, Grzegorz Balcerek <gbalc...@gmail.com> wrote:

Also regarding the first principle, why do you mention
a "rigorous" discource? I would understand that a discource
should be rigorous in a scientific paper, but not necessarily on
IRC. (note however that English is not my native language, maybe
I misunderstand the word in this context?)

Grzegorz, your interpretation is accurate.  However, I must demur, because you should always be prepared for rigor when you propose an idea, even if you propose it informally.  If our goal is to find the right design, then when someone performs a rigorous objection to an idea of yours, it's never an acceptable defense to claim that the objection is "too rigorous".  On the contrary, presentation of an objection founded on rigor in IRC is a great time-saver; you'll save yourself the bother of proposing something that seems to be a good design at first glance but later proves to be ill-founded.  It's up to you whether you're to be discouraged to learn that your assumptions were wrong, or to be invigorated by having learned something new, all the more prepared to propose better designs in the future.

As such, I also strongly disagree with Lars's proposal to remove the aforementioned reference to rigor from the principles.  It's fine to admit that you haven't prepared a defense of a design that stands up to rigor, and probably unnecessary to prepare such a defense if no one demands it by raising an objection that calls for it in defense.  It doesn't serve Scalaz to claim that rigor, in any forum, isn't "sporting", or that it's "rude" or "unwelcoming".

---

This now intersects with my main concern about the use of the CoC.

I was initially in favor of the CoC because I believed it would only be used to ensure that Scalaz remains welcoming to those of traditionally underrepresented groups in [Free] Software development, and moreover that it advertises that fact.

If it is instead to be used to define a specific method of discourse by which it is acceptable to participate in Scalaz, then we would be better served by not having a CoC at all, reverting to the informal code that has held for Scalaz development until recently.  If it is to be put to use in the same way that the current CoC has, we would be irreparably harmed by having a CoC at all.

-- Stephen Compall "^aCollection allSatisfy: [:each|aCondition]": less is better

[Paul Chiusano]

Hi everyone,

Thanks for the responses. I am just getting back to this after Thanksgiving holiday. Based on this feedback I'd like to put together a revised draft this week and also send around some thoughts explaining the changes. Please feel free to continue the discussion in the meantime. 

Just a quick note - Cody, I agree that CoC should at least link to a list of moderators and also be more clear about how to report incidents. I also did reference the Geek Feminism CoC (and others) in preparing my draft. I was kind of hesitant to include a laundry list of behaviors that are considered harassment like the Geek Feminism CoC does. But I will give this some more thought, and if you or others have thoughts on this issue by all means post them here.

Cheers,

Paul :)

[Paul Chiusano]

Hi folks, 

Based on the feedback I've gotten here and yet more thinking, I've put together another draft CoC here:

https://gist.github.com/pchiusano/d446b841f2cc69ca0a84

It is an adapted version of the Geek Feminism template, which is restricted in scope to defining and preventing harassment. Hence it's much different than the previous draft. It's also clearer about reporting incidents (including being clear about the case where one of the harassers is themselves a moderator).

Here is my thinking on these changes -

* The positive statements in the earlier draft about "things that are good" are incomplete, and as people have brought up, they might be mistakenly treated as "rules" or in some cases used to stifle discussion. Also, everyone is going to quibble about what to include there and how to word it (there's already been some of that). Since these things aren't intended to be enforced anyway, I'd rather just consider them out of scope for the CoC. I don't want to discourage people from advocating for ways of communicating they consider to be positive and good. It's just that the CoC does not need to enshrine any one particular mode of communicating.

* Thus, the new draft just focuses on defining unacceptable behavior and how it will be handled. It's really just about ensuring people's basic right to not be harassed online.

I'd like to call attention to a couple points:

* This CoC *does* try to enforce preventing people from making offensive comments about one's race, gender, ethnicity, etc.

* This CoC does *not* try enforce standards of politeness, niceness, or tone. Not everyone is going to agree on what this means, and not everyone is going to agree on how to capture it even where they do agree. Related to this, I actually decided to remove the language restricting "direct personal attacks" as being overly vague. For instance, the statement "you're being sexist" or "you're being a bully" could be construed impolite or a personal attack. (And it turns out this argument does get used to dismiss people who come forward with complaints. See this page on "Tone Arguments".) Do we really want to discourage people from saying such things out of fear they'll be banned?

* Instead, with respect to tone / politeness / etc, the approach taken here is if you don't like how someone is talking to you, you have the right to ask them to stop directly communicating with you, and this CoC requires that they respect that. You do not have the right to force that they communicate in ways you find congenial or pleasant.

* According to this CoC, it's not considered harassment to insult a person's preferred programming language, text editor, or ice cream flavor. The CoC that is on the typelevel site right now has this language: "Harassment includes offensive comments related to... gender, sexual orientation, religion, *programming experience or background*" I feel that insulting a person's programming experience is just not at the same level as a derogatory remark about a person's race or gender, and they don't belong in the same bucket. This draft considers intentional or perceived insults about "programming experience" and the like to be out of scope. Obviously, I would discourage direct insults and would choose not to engage in this myself, but by this CoC, they aren't a reason to ban a person.

* Likewise, this CoC is not about banning people we don't like or find unpleasant. The standard of this CoC is - is the person harassing others, as defined? I think this is something most people can get behind.

Along these lines, I'd like people to think about how this CoC would have applied to the events that precipitated this controversy. I don't really want to debate on this thread what the outcome would have been, nor do I personally feel I have all the facts needed to make such a judgement, this is just food for thought for people who were involved.

So, while this CoC is restricted in scope, I am hoping most people would agree it covers the really obvious stuff. Perhaps some would like something that goes further, but for those who wish for more, I'd like you to consider the following:

* A CoC that is vague or tries to specify too much (like what is considered "rude") is (a) difficult to reach agreement on, and (b) runs the risk of being used to discourage many of the complaints and criticisms that we would like people to feel safe in bringing up! 

* As I've said before, I encourage people to form alternate IRC channels and/or mailing lists for scalaz. If for instance people would like to try to *enforce* some standard of politeness or civility in such venues or have some other rules for behavior, that is their right to do so. I think people's ability to form their own communities around scalaz alleviates some of the need to get everyone to agree on what is good.

All right, let me know your thoughts!

Cheers,

Paul :)

[Sukant Hajra]

On Wednesday, December 3, 2014 5:58:37 PM UTC-6, Paul Chiusano wrote:

All right, let me know your thoughts!

Hi Paul,

One problem I had with your new draft of the CoC is that I saw all kinds of "tone argument" problems with it still, and it took reading your reponse to the mailing list here to more clearly understand your intent.  The fact you had to write so much to clarify it suggests to me how flawed the document still is.

Another problem I'm having is that we're talking about all of this in the absense of talking about Tony and the facts of what happened.  I think it was good for a moment to let us cool off, and reflect on what's going on holistically.  But without /any/ discussion about Tony, I'm left evaluating these documents in two contexts:  How might this apply to genuine malice, and how does it apply to Tony?  Certainly no one cares if I "*hug*" Tony or anyone else; there's something disturbingly puritanical in its phrasing.  Your document is one that reads okay when you think of the fiasco Briana Wu and company are going through now, but very poorly when you think of the issue Scalaz actually has at hand -- namely Tony's banning.

I'm one of those people that tries not to be cynical, but am susceptible given some context.  The fact that Tony was banned as part of a process to install a CoC for me sullies the spirit of the whole process.  I'm finding it very hard to "fix" the whole thing.

Frankly, what we had before this ordeal (an unwritten contract of excellence) was superior to what I believe we'll have in accepting such a document -- especially now.  We have a problem of temporal coupling that as human beings I think we can not decouple.

It's possible that if you want to alleviate this coupling, you can wait some more time, but I think that amount of time would have to be something along the lines of a year or so -- not weeks -- which is even worse considering that Tony has had a major spinal surgery through this whole process.  I'm pretty sure that Tony's been in a hospital, with atrophied muscles and pain, on a laptop trying to figure out what's going on with Scalaz.

So I'm lobbying that we return to the way things were with respect to Github, this list, and IRC.  If people want a polite #scalaz-gentle channel, we can create one, but I'm not at all happy with how ##scalaz was born from Tony's banning.

I felt this way really early on, but I wanted to see how discussion panned out.  If people were getting too heated, I didn't want to add to that unnecessarily.  But at this point, I think a lot of the discussion has mellowed out, and it feels okay to bring up now.

If we want to do the right thing, I want to make sure we do it the right way.  This way still seems wrong.

-Sukant

[Cody Allen]

Paul C,

The latest draft looks great to me. I'm certainly not an expert on these matters, but it seems to hit on the right things. Thank you very much for all of the work you have put into this. I'm sure it can be mentally and emotionally draining.

Sukant,

So I'm lobbying that we return to the way things were with respect to Github, this list, and IRC.  If people want a polite #scalaz-gentle channel, we can create one, but I'm not at all happy with how ##scalaz was born from Tony's banning.

Are you suggesting that this CoC should only apply to an environment where people want things to be "gentle"? It doesn't read that way to me. It even specifically says that the team will not address complaints regarding "Communicating in a 'tone' you don't find congenial".

To me this CoC seems to just identify completely inappropriate behaviors which don't seem very controversial to me. It makes it clear that the sort of things that Briana Wu, Anita Sarkeesian, and many others are going through simply are not okay and will not be tolerated. There is certainly still discussion to be had about Tony's banning and how that situation might be remedied and prevented in the future. But I think that it would be throwing the baby out with the bathwater to suggest that in the interest of decoupling it from what happened to Tony, we might need to wait a year before we could endorse a document that forbids such terrible things as Briana and Anita are going through.

[Sukant Hajra]

On Saturday, December 6, 2014 10:43:19 AM UTC-6, Cody Allen wrote:

Are you suggesting that this CoC should only apply to an environment where people want things to be "gentle"? It doesn't read that way to me. It even specifically says that the team will not address complaints regarding "Communicating in a 'tone' you don't find congenial".

To me this CoC seems to just identify completely inappropriate behaviors which don't seem very controversial to me. It makes it clear that the sort of things that Briana Wu, Anita Sarkeesian, and many others are going through simply are not okay and will not be tolerated. There is certainly still discussion to be had about Tony's banning and how that situation might be remedied and prevented in the future.

It may seem to do the right thing on the surface, and yet the first attempt to apply it was directed at Tony.  So I definitely lost faith in it's ability to be enforced.

I know Paul is trying to regain my trust with this new CoC, but instead what we're doing is starting an odd social experiment on who gets to be an enforcer and what gets to be enforced -- apparently missing the fact that that is a very hard game to play and one we've already bungled at least once with Tony, possibly more if we looked at a complete history.

Also, this experiment doesn't come at no cost because we're heavily fracturing a great community that had a way of working together before.

 

But I think that it would be throwing the baby out with the bathwater to suggest that in the interest of decoupling it from what happened to Tony, we might need to wait a year before we could endorse a document that forbids such terrible things as Briana and Anita are going through.

I put forth that we do have a strong body of people that care -- that will do the right thing -- without a flawed written document.  We're not operating on nothing, begging Gamergate types to come flock to #scalaz with their mad tirades and violent schemes.

Adopting the Geek Feminism CoC is not necessarily the greatest way to be a good feminist (feminists come in all varieties).  If we're serious about the cause, I'd be much more impressed by a people that reached out to show FP to various minority groups.  Instead, just erecting a borrowed CoC feels more like a symbolic gesture than something of real social substance.

I'm speaking up now, largely because I think the discussion on the mailing list suggests too few opposing views, when these views are clearly being expressed in strength in other forums (namely ##scalaz).  My gut instinct is that people aren't speaking up, because either 1) they've completely lost trust and feel their voices would be ignored  2) are afraid of being blanketly bucketed with a group of destable bigosts for defending a subtle position perhaps with poor phrasing.

-Sukant

[Paul Chiusano]

Hi everyone, 

I think both Cody and Sukant make good points. It greatly concerns me that some people have lost faith in this process and may not be participating for that reason (I strongly suspect Tony is in that boat). If that is the case, then this exercise is much less valuable, since it was important to me that everyone with an interest in these issues participate in the discussion. So I'd like to take a step back here.

I agree with Sukant that we do not necessarily need a written CoC right now to guard against Gamegate-level bigotry and the like. If someone is making death threats in #scalaz or something similarly egregious, they are going to be booted regardless of whether we have a formal CoC in place, and I cannot recall a time when this has ever been an issue for scalaz in the past. That said, I do think having a written CoC can be a good thing. Even if most of it "goes without saying", having it written down can help people to feel safe. I also think having something written down like what I drafted could have prevented this particular issue from spiraling out of control, as it would have been more clear what constitutes harassment, and what behavior is just communication that some find unpleasant. And it would have been more clear how situations like this are handled.

Sukant, I think the details of any CoC matter significantly, and IMO the previous CoC that was put together was overly broad in scope, too vague, left too much up to interpretation (especially the process by which a person was removed from the community), and was not developed with buy in from people. I believe Lars regrets how this was handled, and he's graciously submitted to this process and overall is coming from a good place. I also think the same of Tony, btw.

So, I really am not sure what to do. I have one suggestion, which is that I think Tony should be added back to the project and #scalaz ASAP. Especially if this process of agreeing on a CoC is going to go on for a while, it really sends a bad message to leave him locked out until it's done (it sends the message that Tony's dismissal was entirely legitimately done and he must wait around for others to agree to a "lesser sentence" and let him back in---even for people who don't like Tony, do you really think that is fair?). I believe this in and of itself is causing division and getting in the way of having a constructive discussion about a CoC, in addition to not being fair to Tony.

With Tony being added back, if there is conflict and disagreement, I'd like people to deal with it as constructively as possible, without resorting to threats of banning or the like. And I'd like to continue the discussion about a CoC. Perhaps after New Years, so people can enjoy the holidays, cool off, and come back at this with a fresh perspective in 2015. I feel pretty drained myself from being in the middle of all this. :\

Lars and Tony, I'd like to hear from you both on this, in particular. But others should feel free to pipe in.

Paul :)

--

[Alois Cochard]

+1 to what you just proposed Paul!

Also, I just want to mention that I share Sukant's concerns.

I don't think we can have a constructive general discussion on the CoC without discussing "the Tony situation" first and solving it.

If we cannot solve first that problem, there is no hope about having a meaningful CoC/moderation imho...

Cheers

[Sukant Hajra]

On Monday, December 8, 2014 10:57:34 AM UTC-6, Paul Chiusano wrote:

So, I really am not sure what to do. I have one suggestion, which is that I think Tony should be added back to the project and #scalaz ASAP.

This really makes sense to me.
 

With Tony being added back, if there is conflict and disagreement, I'd like people to deal with it as constructively as possible, without resorting to threats of banning or the like. And I'd like to continue the discussion about a CoC. Perhaps after New Years, so people can enjoy the holidays, cool off, and come back at this with a fresh perspective in 2015. I feel pretty drained myself from being in the middle of all this. :\

If we can say clearly that we made a mistake banning Tony, and take some steps to repair the mistake, perhaps we can engender enough trust to have not only Tony -- but others that left with him -- return for active participation.  I think we should invest in this first before rushing to talk about a CoC.  Of course, there's no reason to procrastinate, but let's take things one step at a time.  There's no upper manager pressuring us to resolve all disputes by some artificial deadline.

Also, Paul, thanks for trying to wrangle this.  I know it's not easy.

-Sukant

[Tony Morris]

Making threats in relation to the Scalaz project has not been an issue
from the day the project started around 2007/8 up to October 2014.

[Chris Marshall]

> Paul wrote: "some people have lost faith in this process and may not be participating for that reason"

Looking from the outside, this thread looks a lot like a car crash. My opinion is that it is rather ludicrous that there's been so much discussion about this and (it seems to me that) this is a result of trying to integrate stuff like "racial slurs are not OK" (that I hope everyone would agree on) with stuff like "be excellent/rigorous" (which is meaningless). It should at least be obvious that there is no consensus about the latter. I think the CoC should keep itself to the former and be explicit about the process by which breaches of the code are dealt with.

The shorter it is, the better.

[Lars Hupel]

Sorry for my belated reply. I'll keep it short.

I think the process for coming up with a CoC failed, but that's hardly
Paul's fault, who really gave his best. Thank you, Paul.

I'm inclined to agree with Chris, which is also why I think that the
current Typelevel CoC is a good start and can be kept for now.

I've acknowledged in earlier threads that my initial actions were far
from ideal. However, if you think that it's somehow not obvious that a
track record of insulting people and derailing technical discussions
without any actual prospect of change qualifies one from being banned,
then I have to disagree. I also can't with good conscience work together
with someone who has such a track record and believes that that is
somehow crucial for contributing.

Lars

[Tony Morris]

The code of conduct for Scalaz, which has existed from 2007/8 to October
2014 will stand.

[Paul Chiusano]

Hi everyone,

Up until this point, I'd really been hoping that there might be some way forward where all parties could at least tolerate working together, but in the past few days or so and seeing these responses I've become increasingly doubtful that's possible. There just seems to be too much stuff between people and too much baggage from the past. So I'm going to take a step back and let others work things out (or not) amongst themselves. I don't know what this means for the future of the project.

I may still participate in any discussions as a regular Scalaz user and contributor, but I don't want to keep acting in this mediation / leadership role which has occupied a lot of my time and energy, and which I no longer think is going to be fruitful. I'm sorry to let people down, and I'm sorry that the status of the project is very much up in the air at this point.

Paul

--
You received this message because you are subscribed to the Google Groups "scalaz" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scalaz+unsubscribe@googlegroups.com.

[Tony Morris]

Thank you Paul for your help. I genuinely appreciate your efforts, despite the outcome.

Those of you who know what Scalaz means and the principles that it stands for, also know that the future of the Scalaz project is relatively decisive (not so much "up in the air"). As has been discussed, Scalaz has no central authority (no "benevolent dictator") and never will. Unfortunately, trust has been violated on this matter and so we are still trying to work out how to overcome it for the future, while still being productive and staying true to the principles of Scalaz. The rest is decided and requires some work.

To those of you who represent the principles of Scalaz, all of the original contributors, all of the people who have used these principles to better themselves and their workplace, I am sorry that your trust has been violated so deeply. I am sorry I trusted the wrong people with the project and that you incurred the consequences that you did. I am committed to doing the best I can in the circumstance.

To unsubscribe from this group and stop receiving emails from it, send an email to scalaz+un...@googlegroups.com.

To post to this group, send email to sca...@googlegroups.com.
Visit this group at http://groups.google.com/group/scalaz.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "scalaz" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scalaz+un...@googlegroups.com.

[Gershom B]

On Friday, December 12, 2014 3:31:19 PM UTC-5, Lars Hupel wrote:

Sorry for my belated reply. I'll keep it short.

I think the process for coming up with a CoC failed, but that's hardly
Paul's fault, who really gave his best. Thank you, Paul.

I'm inclined to agree with Chris, which is also why I think that the
current Typelevel CoC is a good start and can be kept for now.

I've acknowledged in earlier threads that my initial actions were far
from ideal. However, if you think that it's somehow not obvious that a
track record of insulting people and derailing technical discussions
without any actual prospect of change qualifies one from being banned,
then I have to disagree. I also can't with good conscience work together
with someone who has such a track record and believes that that is
somehow crucial for contributing.

I write this not as a scalaz author, but as a sometimes scalaz consumer who knows many of the parties involved, and as someone who has discussed the ideas in scalaz at times with any number of people who have made some contributions.

Lars, I think this message plays your hand fully. Your advocacy of a CoC has clearly not had to do with the reasons advanced by e.g. geekfeminism in terms of providing a harassment-free environment in which people do not feel threatened by contributing or interacting.

Rather, as you state here, the motivation has been that you feel, let's name names, Tony, has a "track record of insulting people and derailing technical discussions without any actual prospect of change". What this translates to is that you do not like how Tony has argued. I can only infer from this that this is because you have disagreed with Tony about technical issues in the past, and found this process trying. (i.e. if you do not like how someone argues, it is nearly always the case that you notice this more because you do not like _what_ they are arguing).

You made this clear in your earlier post where you cited variance annotations, saying "There's disagreement on whether we should put them in there or not, but  regardless of which opinion you hold (that's besides the point), everybody needs to acknowledge that such decisions are always tradeoffs and that there's no clear winner." Tony, and others, have been of the opinion that there can be clear winners, at least to the best of our knowledge, and have built the library on that basis. You have obviously held some countervailing opinions, and rather than think that either A) you may have been wrong or B) you may have been right but inept at convincing people instead preferred to toss it into C) well, there's no clear winner so let's agree to disagree.

Others, such as Tony, have disagreed with that. Because you have failed to convince people, who obviously can and have been convinced of things in the past, you attribute the fault to them, and chalk it up to a "track record of insulting people and derailing technical discussions without any actual prospect of change".

And now the real motivation for the CoC: you "can't with good conscience work together with someone who has such a track record". I.e., the motivation of the CoC has been to ban Tony, and you will not accept any CoC which cannot be wielded to this end.

That's not the point of CoCs, and using them in this fashion makes it harder for those of us who see in CoCs motivated for the right reasons an important tool in fostering diversity in technical communities.

If you truly "can't with good conscience work together with" Tony, I have an alternate, much simpler suggestion: you leave scalaz to him and the other people who historically were the core contributors and developers, so they can continue to pursue their vision. Scalaz is open source, so anyone can fork it. As it seems that it is your technical vision of the project and social vision of the community surrounding it is at variance with that of the founders and historic core contributors to the functionality of scalaz, it only stands to reason that you should be the one who forks. If you do so, I sincerely wish you the best of luck in your endeavors.

Sorry it had to come to this, but it seems like it is the correct conclusion given your statements about who you can and can't work with.

Cheers,

Gershom

[Lars Hupel]

> Lars, I think this message plays your hand fully. Your advocacy of a CoC
> has clearly not had to do with the reasons advanced by e.g. geekfeminism in
> terms of providing a harassment-free environment in which people do not
> feel threatened by contributing or interacting.

No. People felt harassed in the channel and were deterred from
contributions specifically because of the hostility of Tony.

> Rather, as you state here, the motivation has been that you feel, let's
> name names, Tony, has a "track record of insulting people and derailing
> technical discussions without any actual prospect of change". What this
> translates to is that you do not like how Tony has argued. I can only infer
> from this that this is because you have disagreed with Tony about technical
> issues in the past, and found this process trying. (i.e. if you do not like
> how someone argues, it is nearly always the case that you notice this more
> because you do not like _what_ they are arguing).

This is a non sequitur. In fact, I more often than not agree with Tony
on technical terms. It's what I was trying to say with "that's besides
the point".

> You made this clear in your earlier post where you cited variance
> annotations, saying "There's disagreement on whether we should put them in
> there or not, but regardless of which opinion you hold (that's besides the
> point), everybody needs to acknowledge that such decisions are always
> tradeoffs and that there's no clear winner." Tony, and others, have been of
> the opinion that there can be clear winners, at least to the best of our
> knowledge, and have built the library on that basis. You have obviously
> held some countervailing opinions, and rather than think that either A) you
> may have been wrong or B) you may have been right but inept at convincing
> people instead preferred to toss it into C) well, there's no clear winner
> so let's agree to disagree.

That's an unfounded assumption.

<https://github.com/scalaz/scalaz/pull/383>

That pull request removes the majority of variance annotations
pre-7.1.x. I made it.

Lars

[Edward Kmett]

On Saturday, December 13, 2014 7:31:19 AM UTC+11, Lars Hupel wrote:

I'm inclined to agree with Chris, which is also why I think that the
current Typelevel CoC is a good start and can be kept for now.

I personally think this sequence of events shows very much the opposite, that we have a demonstrated inability to apply such a CoC.

I've heretofore been a strong proponent of putting forth a code of conduct in the Haskell community. We'd been overcome the opposition and were right at the cusp of getting something released to mitigate more of the concerns of the #nothaskell community.

I've now personally spoken to at least 2 dozen members of both the scala community and the haskell community who were previously very strong proponents of the concept of a code of conduct who are now terrified of the potential for abuse and I'm back at square one.

This has shaken my previous conviction, and caused me to drastically scale back my ambitions on this area. I am not proud of that fact. 

I for one do not remember a vote to adopt the typelevel code of conduct, nor, really, anyone officially appointing you as the "defacto benefactor" of the scalaz community. The level to which this was raised was a fairly quiet 'hey lets organize typelevel', 'yeah lets organize the functional programming community in scala' -- not a strong mandate to delegate authority to some benevolent dictator. As for the ownership flag on the scalaz project, as far as I can tell that was granted so we could transition it to an organization. Mark Hibberd mentioned to me that he transferred the founder flag for the #scalaz channel more or less without thought when asked, not as a way to pass a torch or a mantle of authority.

The only person I can look to who has any legitimate "ownership" in this situation, like him or not, really is Tony here. He started this project by porting a bunch of code I had in Haskell and that Runar had in functional java and invited us all in to play with his toys.

I point to Runar walking away from the project, Paul's exhaustion and the level of drama pushing Jason Zaugg even further to the fringes to avoid getting embroiled in a conflict as that from a POSIWID perspective (the purpose of a system is what it does) the purpose of the code of conduct we have today has been to completely kill all existing interest from the primary contributors to scalaz in dealing with the project at all.

You went to shoot Tony in the head and shot scalaz in the foot.

I've acknowledged in earlier threads that my initial actions were far
from ideal. However, if you think that it's somehow not obvious that a
track record of insulting people and derailing technical discussions
without any actual prospect of change qualifies one from being banned,
then I have to disagree.

 

I also can't with good conscience work together
with someone who has such a track record and believes that that is
somehow crucial for contributing.

For all the damage Tony may or may not have done, he still had a project going with active maintainers.

For all the disagreements he's had with folks like, say, Cedric over the years, well, you'll note Cedric was still active in the channel when this all went down.

The primary folks hurt by the current rift are the users for whom you claim to stand.

We are left with a completely toxic environment after you chose to kick a man from his own project, preemptively, twice, and cutting off debate by autocratically decreeing that it was a lifetime ban with no avenue for further discussion.

That very strongly weakens the argument that it is he that should leave. My mother gave me a fairly simple rule to apply when someone issued the "it is them or me" ultimatum.

-Edward

[Kris Nuttycombe]

On Sat, Dec 13, 2014 at 2:00 AM, Lars Hupel <hu...@in.tum.de> wrote:

> Lars, I think this message plays your hand fully. Your advocacy of a CoC
> has clearly not had to do with the reasons advanced by e.g. geekfeminism in
> terms of providing a harassment-free environment in which people do not
> feel threatened by contributing or interacting.

No. People felt harassed in the channel and were deterred from
contributions specifically because of the hostility of Tony.

That's their problem, not ours. 

I've spent a lot of time in #scala, #scalaz, and ##scalaz over the past 6 years. And while I've certainly seen some contentious discussions that Tony was involved in, I have never once seen him act with malice. I have seen him be dismissive, condescending, and vulgar toward people who were clearly unwilling to set aside their preconceptions in order to discuss a technical question. In many cases, this approach has caused people to choose not to interact with the community; in many others, I have seen this sort of social shaming cause individuals to step back and reassess their premises, and go on to become contributing members of the community. 

On balance, I have no idea whether the value of contributions produced by the latter outweighs the value of contributions that never materialized from the former. However, I do believe that Scalaz is what it is today because of the community that evolved with Tony as a part of it. Frankly, if Lars and others want a different kind of community, then they should fork. Let the best community win.

Kris

 

[Tony Morris]

As it happens, I was told some pretty nasty lies about this event, before I was able to talk to Mark. And, since Mark no longer lives nearby, it was very difficult for me to sort out over email. This resulted in problems.

I'd have done anything to have avoided those problems. And I mean *absolutely anything*. Please be careful when you choose to tell lies, I assume, "for the greater good" or whatever you believe.

[Luis Ángel Vicente Sánchez]

I was quite reluctant to participate in this discussion as I'm just a scalaz user but last emails make worry. As Edward Kmett has pointed out, any benefit of having a code of conduct has been outweighed by the damage that the arbitrary application of that CoC has made done. Unless I missed something, the scalaz hasn't a single owner and the fact that a single person made such a decision without asking others is worrisome.

It's fairly obvious to me that the person that sponsored and applied the CoC retroactively is not willing to change his decision no matter what the opinion of other "owners" of the project; that attitude not only harms scalaz but the entire typesafe ecosystem. I can't see any other way of solving this situation but forking the project... and that's terrible.

Regards,

Luis

--

[Tony Morris]

Hi Luis,
I will clarify some points for you below.

On 14/12/14 07:40, Luis Ángel Vicente Sánchez wrote:
> Unless I missed something, the scalaz hasn't a single owner and the
> fact that a single person made such a decision without asking others
> is worrisome.

You are right. Scalaz does not have a single owner. It never has had
"owners" and never will. I created Scalaz in the corner of a room, then
Runar Bjarnason joined me soon after. We had already worked together on
other projects. Runar has recently left the Scalaz project and he has
discussed his reasons with me -- I think they are good reasons in light
of recent events.

Along with "no owners", the Scalaz project has also operated under the
principle of, "always assume the best intentions from others [even under
strong disagreement]." This principle is summarised here, but it took
hours of discussion to figure out in detail. It became a core component
of what makes up the Scalaz project. Runar and I operated under this
principle (and we had strong disagreements at times!) and so did many
others who chose to help with the Scalaz project. I have spoken to those
people and they agree that this principle, and others that we discussed,
are important and valuable. I do too.

Unfortunately, "assuming the best of others", is also exploitable by
vindictive motivations and not necessarily with a commitment to the
principles of Scalaz. I can only repeat my apology, I am so sorry for
letting this happen to the Scalaz project. It was also a "known hole" in
the way we conducted ourselves, but I didn't ever consider the potential
practical outcomes in any detail, along the vector of "devastation."

For example, we didn't care who we gave the keys of the project to. It
didn't ever matter and was never really a concerning question. "Just go
ahead and be awesome!", we would chant. Yes, well, that has problems.

I am sorry and I will do my best to make it better. Be assured, the
principles of Scalaz will stand.

>
> the opinion of other "owners" of the project;

Well, like I said, there are no "owners." There are people with their
own opinions though. Historically, Scalaz attracted people who I would
describe as "having unique & intelligent thoughts." It is not surprising
to me that those same people [original creators of Scalaz] are able to
see what is truly happening in front of them. They are doing their best
too. They are good people.

Take it easy and stay true to your goals.

[Daniel Spiewak]

I've held off replying here to date, mostly because I had hoped that things would resolve out and were moving in the right direction (thus I could be lazy and just reap the benefits of everyone's actions down the road), and partially because I don't consider myself to be a particularly significant member of the scalaz community, much less any sort of serious contributor.  I fall into the category of "serious scalaz user, freeloading off of everyone else's hard work", and I'm extremely grateful for the work that everyone has put into the project: Lars, Paul, Runar, Jason, most certainly Tony, and many others.  I don't know if my opinion on these issues matters at all, or if it will have any effect, but I wanted to make a statement before I lost the opportunity to do so.

Let me be very clear about where I stand on several points:

• Tony's behavior in public channels towards many people has been unacceptable by any standard.  He is single-handedly responsible for keeping me away from Scalaz for most of the lifetime of the project.  I can't speak for anyone else, but I can speak for myself in saying his presence is best described as "toxic".
  
• Tony's behavior in private channels and in person has been universally fantastic, helpful and insightful.  I've learned a lot from him, just never in a public channel.  This fact makes his public behavior all the more disappointing, because I know what a patient, knowledgable, and invaluable teacher he can be.
• Tony's technical contributions speak for themselves.  He founded the project, and he continued to valuably contribute over the years.
• Lars was the de facto project maintainer for Scalaz in recent days.  He earned that title not by ownership of an IRC channel or GitHub permissions, but because he did a crapton of work and successfully catalyzed contributions and technical progress.  He has my respect because he has earned my respect.
• Unilaterally banning Tony, in particular the "public discussion muzzle" clause, was a completely inappropriate way to handle the situation.  Two wrongs do not make a right.
• The "top-down" nature of the original CoC process was highly disappointing.  Community codes of conduct need to be chosen by the community.  Rewinding six months, I think we as a community would have chosen something very close to this, but we cannot do so now given how the whole thing is tainted by what happened.

I don't really know how to move forward.  Runar, Paul, Jason, Lars and Tony being driven away from the project just by virtue of the stress and drama and insanity of all this is exactly the opposite of progress.  I think there's plenty of blame to go around here, and honestly dwelling on it isn't helping us heal as a community.  It also isn't doing any favors for the future of this library.

I am of the opinion that we should step away from the "code of conduct" concept for the time being.  I think it would be beneficial to have one, but at this point the whole notion is tainted.  We should also back off of the leadership questioning and attempting to trace the significance of various inconsequential actions.  Lars was doing the work.  That's all that should matter.  The corollary to this is that we need to assume a clean slate where Tony is concerned as well.  My opinion is that his public behavior is a problem, but the actions taken against him were heavy-handed and the process by which they were justified was flat-out wrong.  I think the best thing to do would be to rewind, step back, and treat him as the respected member of the community that he is, without prejudice.

We are perilously close to a point where this incident defines and destroys this community and this project.  None of us wants that to happen.

Daniel

[Gershom B]

On Saturday, December 13, 2014 4:00:34 AM UTC-5, Lars Hupel wrote:

No. People felt harassed in the channel and were deterred from
contributions specifically because of the hostility of Tony.

You obviously feel the path to a better library would be one which was managed in a different style than the one in which scalaz has, historically. Luckily, there is a way to empirically determine the answer to this question. You can fork scalaz and adminster this fork in whatever style you choose. Over the course of time, the practical ramifications of these differences in approach will become apparent.

I should clarify one point from my previous post. I am not encouraging a fork. I am noting that you have stated that you cannot in good conscience work on project with Tony. The obvious practical conclusion to this is that you should leave the scalaz project. If you wish to continue working on the code base, you _are welcome to_ fork. I'm fairly indifferent as to whether or not you choose to do so. I do now have a strong opinion, after having extended this entire process a great deal of benefit of the doubt, that you should step down from the scalaz project, because you have now burnt through all the trust and goodwill that your work over the work has accrued to you, and your continued intransigence is now the primary obstacle to the future progress of the scalaz library.

Cheers,

Gershom

[Tony Morris]

Daniel,

In around November 2013, the followed discussion occurred on twitter, to paraphrase:

@djspiewak Something, something about IO side-effects that is a common beginner mistake.

@[several other people, including Runar, Brian, others] No that is not true. [Effort toward helping you understand]

@djspiewak [more beginner misunderstandings]

@[same people] More help

@dibblego Here is another way of understanding why this is in error ...

@djspiewak [protesting, assumingly in an effort to understand] ("assume the best of others")

@dibblego More explaining of why this is an error [and a common beginner one, encountered a lot, and so we already have the tools to deal with it]

@djspiewak The thing I said earlier is not the thing I meant. However, the thing I meant is indeed true. I am not telling you what that thing is. [almost exact wording]

At this time, under a principle of "assume the best of others", I could not come to any other conclusion than, "Daniel Spiewak currently has a very poor understanding of this subject. Daniel Spiewak is currently unwilling to change that." I tried every explanation I could think of; was it because of twitter and its limitations? Was Daniel just having a bad day? It turns out that no, because it has been repeated this behaviour later on in other contexts.

I am left to conclude these things. Now, I might be making a mistake in my interpretation here. And that is why, above all things, I will fight for a forum in which we can openly discuss those mistakes. It doesn't fucking matter [to our common goal] ultimately. It is not about *who* is making that mistake. It is about determining the economy of addressing that (supposed) mistake and moving forward on that basis. Creation of that forum is what Scalaz *is made of*. That principle is currently under threat.

Now, all of this sounds very personal, but really, it is a matter of efficiency -- it is in fact, very impersonal. I cannot take these poor understandings into consideration indefinitely. After all, there are other people who also have a poor understanding, but *are* more willing to understand those subjects better. Further to this, there are people who go out of their way to help *me* understand things when I need that help. It is simply a matter of moving forward appropriately. I simply have to move on, quickly, at some point. I have had my position on this matter reviewed by many (trusted) others and I have adjusted my position accordingly (to what it is now).

I have all the patience in the world for you Daniel. However, currently, the displayed attitude toward learning what is otherwise a very basic subject, is not so much "toxic" as it is inefficient. I will simply wait for that to change, forever if I must. It is also in contradiction with the conduct of the Scalaz project. All of us (original Scalaz committers) made a commitment to reject this type of inefficiency in the most hasty (efficient) way possible once it is very clearly not an economical approach.

You have confused this response with personal matters, giving yourself the liberty to decide what is "appropriate behaviour" and what is "toxic." This is just more unconstructive bullshit.

Like I said, I will wait.

PS: I'd have preferred sorting this out privately, but well, when one starts bandying about terms like "toxic", then permitting oneself to decide what is "appropriate", well, I stop caring about the integrity of this discourse ever so slightly more.

--

[Pascal Voitot Dev]

So do we go forward from now & stop that cyclic neverending discussions that will re-feed itself as soon as one says anything about even the smallest aspect?

Please let's break the vicious circle now & definitely go further all together whatever happens later.

Let's add that a few more people like me who are "scalaz-fresh" enough could spend a bit more time answering those "dumb" questions and everybody would be happy then.

Pascal

[Kevin Wright]

To me, at least, what most stands out as being toxic is profanity.

For (I suspect) the vast majority of readers, phrases such as "it doesn't f***ing matter" come across as disdainful and contemptuous.

If there's a very real chance here of such language being viewed as disrespectful, then it does NOT come across as "assuming the best of others", which I think we all agreed on as a useful goal.

[Richard Wallace]

Please define profanity.

[Daniel Spiewak]

In around November 2013, the followed discussion occurred on twitter, to paraphrase:

I think we're both able to draw extensive examples from past twitter exchanges that can show various points.  A particularly memorable one for me was when I asserted that the IterateeT#run function should return its result inside MaybeT, to avoid throwing an exception when the iteratee failed to terminate.  Your response was a laconic "No.", followed by protestations that you didn't have time to address drivel (or something very close to that; can't remember the wording).

My point from earlier is that, while I do have very strong feelings about the appropriateness of this behavior from any community member, it doesn't matter NOW.  The attempt to censure you was ham-fisted and generated a community rift that festers today.  That rift is what is important.

 

At this time, under a principle of "assume the best of others", I could not come to any other conclusion than, "Daniel Spiewak currently has a very poor understanding of this subject. Daniel Spiewak is currently unwilling to change that." I tried every explanation I could think of; was it because of twitter and its limitations? Was Daniel just having a bad day? It turns out that no, because it has been repeated this behaviour later on in other contexts.

Again, without puncturing old wounds or attempting to drag out any attempt to indict you, I will say that your behavior in that particular exchange was 100% typical of every public exchange we have ever had for the entire time that I have known you (now somewhere in the vicinity of seven years).  I certainly held extensive misconceptions in the past, and I'm sure I hold others now.  I don't think it's fair to conclude, either then or now, that I am unwilling to learn.  Because, if I were, then clearly I would not have learned.

I do think it is very fair to say though that I will outright reject and challenge anyone's claims if they fail to justify them in a calm and civil fashion, answering objections appropriately.  I don't think I'm the only one who feels this way.  In your defense, as you have said on many occasions, Twitter is a terrible medium for this sort of thing.

I have all the patience in the world for you Daniel. However, currently, the displayed attitude toward learning what is otherwise a very basic subject, is not so much "toxic" as it is inefficient. I will simply wait for that to change, forever if I must. It is also in contradiction with the conduct of the Scalaz project. All of us (original Scalaz committers) made a commitment to reject this type of inefficiency in the most hasty (efficient) way possible once it is very clearly not an economical approach.

Sometimes, efficiency matters less than accurate conveyance.  Teaching and mentoring is never an efficient path, relative to peer-level interaction and knowledge exchange.  Similarly, attracting (and by extension, avoidance of repelling) new members of a community is far from an efficient pursuit, but it is clearly one that pays off in the long term.

 

You have confused this response with personal matters, giving yourself the liberty to decide what is "appropriate behaviour" and what is "toxic." This is just more unconstructive bullshit.

I prefixed it with the "opinion" qualifier.  I stand by my characterizations, but I make no claims about whether they are shared by others.  Though, I will say that I know for a fact my experiences (as distinct from my opinions) are not unique.

Bringing this right back 'round…  My broader point was that, despite what I believe are your missteps, and what I believe are missteps by others (such as Lars), I think we need to simply move on from this issue as a community.  At this point, any discussion of conduct in the Scalaz community is tainted by this issue.  Not just discussion of the proposed Code of Conduct, but also discussion of past conduct.  We could argue all day about the past, but I don't think that's going to get us anywhere.

What I care about, ultimately, is not your tone or actions or even intent.  What I care about is the community mending itself and continuing forward.  On a very selfish note, I rely heavily on Scalaz, and thus anything that affects its future profoundly affects my own as well.

Daniel

[David Barri]

I don't consider swearing profane. To me, "it doesn't fucking matter" comes across to me as emphatic, not disdainful.

I was going to suggest that we not conflate that with the current issue, then I realised it's not conflation. The real issue here is that Team A doesn't like Team B's method of communication. We all agree on being well intentioned, we mostly agree on technical goals and the like. Am I alone in thinking that it seems like such a silly thing to quibble over? I doubt it.

The ability to speak and satisfy all listeners' moral values gets harder with the size of the audience. Trying to block potentially offensive speech is unachievable and pernicious. Speakers, it would be nice to be aware and not rile up people you know will get riled but more importantly: Listeners, take responsibility for your perceptions and your reactions, and acknowledge both the ambiguity of language and the diversity of communication styles (and diversity of cultures). Umbrage is in the ears that hear; to borrow Kevin's example, how about when one offended by swearing reads "it doesn't fucking matter", they translate it to "it doesn't matter" in their head? If one doesn't like another's sarcasm and ranting, ignore it, don't respond to it. There are easier and more effective ways to deal with these differences without making law and trying to prune the world. Surely we're all mature enough to live and function effectively in a world/community with people that we don't get along with or like.

Even if this is naive, my intention in saying this is to have a positive effect. For me, personally, this understanding is all that we need to just move on and be harmonious. Hopefully it affects others similarly.

--

You received this message because you are subscribed to a topic in the Google Groups "scalaz" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scalaz/ki3MjAxD3Bs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scalaz+un...@googlegroups.com.

[Robert Norris]

Alright.

At the risk of vastly oversimplifying things, I have a modest proposal that I would like to put forward:

Turn scalaz off and back on again.

Specifically:

1. Remove the CoC.
2. Reinstate both Lars and Tony.
3. Pretend this never happened.

I realize (3) will be impossible for some people, but I think for most of us things in scalaz were just fine right up until this crap started. Some people claim that things have been terrible for a long time, but I never saw any evidence of this myself. In any case it is extremely important to me that we not force a fork over non-technical issues, because I work on libraries that depend on scalaz and I don't want to have to choose a religion on behalf of *my* users.

I'm sorry if this sounds overly grumpy, but FFS we're all grownups and we should be able to resolve a pissing match without setting the world on fire. We're all friends here, at least from where I'm sitting, and this does not need to be an existential crisis. If we want to talk about a CoC, fine, make a PR and let's talk about it. Lars made a mistake. Tony's quantum states are 0 and 11. Fine. Move along.

I realize this notion may seem silly, but I have talked to a LOT of people over the past month on all sides of this mess and this is the best I can come up with.

rob / tpolecat

[Daniel Spiewak]

Rob, your proposal is exactly what I want. Hit the reset button, pickup where we were six months ago. None of us holding anything against Lars, Tony, or anyone else involved.

Daniel

[Edward Kmett]

This approach is more or less the "middle ground" that Paul has been trying to pursue so far. It seems to be working out great except for actually, you know, successfully healing any wounds or keeping folks engaged in the project. 

Lars seems to see Tony as a villain he can't work with. He clearly believed he was just taking out the trash and that he had a broad mandate of authority to do so, and seemed shocked when there was a backlash.

On the other hand, Tony did go apoplectic over the CoC, although, admittedly in retrospect, that seems a heck of a lot more foresighted than at the time. Tony sees Lars as someone who earned folks' trust and went powermad. Given the way things went down and the amount of time he's had to do nothing but dwell upon this, he's jumping at shadows and sees conspiracies all around him, which have the unfortunate side-effect of at least having a small kernel of truth here and there.

In essence, you're effectively proposing that we continue the status quo indefinitely and I've already seen long term contributors withdrawing from the project entirely to avoid dealing with this situation. It creates uncertainty, and uncertainty is a terrible thing to have in the air around a project upon which a large number of people depend.

Prolonging the drama indefinitely doesn't seem a viable avenue to re-engage with either those committers or the users who now just see scalaz as a cauldron of toxic drama.

-Edward

On Sunday, December 14, 2014 1:45:19 PM UTC+11, Rob Norris wrote:

Alright.

At the risk of vastly oversimplifying things, I have a modest proposal that I would like to put forward:

  Turn scalaz off and back on again.

Specifically:
 
  1. Remove the CoC.
  2. Reinstate both Lars and Tony.
  3. Pretend this never happened.

rob / tpolecat

[Kevin Wright]

David, Robert,

I must respectfully disagree.

There's a claim that "we're all adults here", which sounds an awful lot like stating that "kids don't code".

Extraordinary claims demand extraordinary proof, and the onus is on YOU to prove this one.

In counter, I give you exhibit A: Shadaj Laddaj. Scala programmer, scalaz programmer, speaker at numerous conferences, and NOT an adult.

I've also encountered numerous gifted children via the stemnet programme, some of whom I've steered towards Haskell.

My own children, I'll be teaching them functional programming (because the schools certainly won't).

This will include both Haskell and scalaz, mostly to take advantage of the kojo environment.

And I'll do so IN SPITE of the community, not because of it - a very sad state of affairs indeed.

Children code.  And if we're to ever improve on the status quo as to how they do so, then tools like scalaz will likely be part of the solution.

Is *that* not a worthy goal that we could all get behind?

David: As an aside, EMPHATICALLY stating that somebody's opinion doesn't matter is hardly an improvement here, it's practically the definition of disdain.

Robert: In a grumpier mood I'd interpret your post as trolling and not as emphasis in the best python-esque tradition, but this is not an alternative

comedy sketch show.  It's programming, and it's most definitely broadcast before 9pm.

[Tim Pigden]

We run the risk of putting the Judgement of Solomon into practice here (the story about cutting the baby in half, if you don't know).

Please, please kiss and make up.

I was at Scala Exchange last week. 800+ attendees. Runar's book was the hot item and scalaz (and other things typelevel) was the hot topic. Underscore has started commercial training in scalaz. Over here at least, it seems primarily identified with Lars these days - possibly due to geography. Suggesting he fork off is shooting yourselves in the stomach not the foot.

If you must bifurcate effort, can't we just split the discussion lists? We could rename them to  be clear:

scalaz<::&^!%$

and 

scalazzzzz

[Tim Pigden]

Sorry that should have been Paul's and Runar's book

[Richard Wallace]

I disagree. Your suggestion seems to presume that the goal of scalaz is to be used. It is not. It never has been. The goal is to be useful. Has this attitude driven some people away? Perhaps. Does this or should this matter to the core contributors? That's really up to them. I won't presume to speak for them, but based on my observations it seems like many still care more about building a useful library. Further, since this goal is aligned with the original goals of the project, it seems like a logical conclusion that those core contributors looking to change the primary goals of the project should create a fork and run the project according to their own goals.

--

You received this message because you are subscribed to the Google Groups "scalaz" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scalaz+un...@googlegroups.com.

[Daniel Spiewak]

Healing isn't happening, Ed, and it's not going to happen any time soon.  I don't want to prolong the drama indefinitely.  Quite the opposite.  I think this thread is responsible for prolonging the drama as long as it has been (to be clear, that isn't Paul's fault in the slightest; this thread started with the best of intensions).  I want to take the whole matter and sweep it off the table.

Regardless of what my personal feelings are about codes of conduct and what-not, it seems extremely and abundantly clear that now is not the time for Scalaz to hammer one out.  The whole issue is presently tainted by what happened.  Maybe we can discuss it in the future, but for right now, pushing the issue forward only perpetuates this tension and drives contributors away from the project.

At present, I see three courses this project could take:

• Drop this issue on the floor without prejudice, and try to move forward from where we were six months ago
• Fork Scalaz
• Allow Scalaz to die, or at the very least dramatically diminish from loss of contributors

The second option is basically untenable for purely technical reasons.  Maven artifact resolution doesn't allow for "separate, but equal" forks of the same project.  One of them has to be primary, otherwise we just generate dependency hell for the entire functional Scala community.  Additionally, forking Scalaz bifurcates the community of potential contributors.  Even if you don't care about the community of users, the community of contributors is vitally important to the very existence of the project, since those are the people who, you know, actually do the work.

The third option is unappealing by definition.  In fact, it is so unappealing that I doubt it could actually happen, since option 2 would be chosen by a subset of the community were option 3 to ever transpire.

I really think option 1 is the only way to go.  This thread proves that the hypothetical compromise option isn't going to happen (where we develop a mutually-agreeable CoC and bring people back into the fold).

Daniel

[Robert Norris]

Hi Edward, thanks for your comments.

So, I think my proposal (which may have seemed unserious from the tone of my message, apologies) recognizes some aspects of the situation that Paul's "middle ground" process did not directly address. It is also much more conservative and is immediately actionable: return to the last known good state (now with the benefit of hindsight) and proceed with caution.

I want to examine two points of fact in a bit more detail:

The first is that there truly is no middle ground here. There is an important subset of contributors who will never accept a CoC in any form, nor will they recognize any "democratic" process that chooses to bring one about. For them this is a matter of principle and settled fact, and arguing about it is like legislating the value of π. So in order to establish any hope of bringing them back, the minimum ante must be the following CoC: Nothing. Those who feel that a written CoC is critically important have nonetheless been working without one for a long time, so it is my hope that in the spirit of getting out of the ditch they will consent to returning, as you say, to the status quo.

The second is that the immediate tangible effects of Lars's overstepping can be reversed, and it is my suggestion that this happen immediately. The less-tangible effects (i.e., bad feelings due to violation of trust and acting alone, or at the urging of unnamed co-consipirators, whatever, doesn't matter) are a matter of personal willingness to forgive and forget. Some may be unwilling to do this, but it is my hope that most of us can. In any case this doesn't seem like a matter that can be resolved en masse on the ML.

So, I don't know whether this will increase or decrease uncertainty in the long run, but it would certainly take us back from the brink of a fork, which as I have said is my primary concern. And it would allow those who have no particular dog in this fight to continue moving forward, which they (I among them) are eager to do.

Thanks,

rob

[Tony Morris]

I don't think this is perfectly accurate. The Scalaz project does not
have settled facts. We argue about them intensely, until we arrive at a
tenable position on issues -- this includes social issues, which have
always been important. This mode is the definition of Scalaz.

* It is a "settled fact" that Scalaz will have no written code of
conduct, because it has been argued (for days) already and established,
on the basis of the goals of the project, that it is rejected. Scalaz
has always had a mode of operation, which is held to be important by its
core contributors.

* In this case, a few people with ulterior motives and a poor
understanding of the goals of the Scalaz project, had secret meetings
and came to their own determination. Zero Scalaz core contributors were
consulted on the instatement of a code of conduct, among a few other
recent perversions of the Scalaz project. That's not how we do things
around here. We never have and we never will.

Unfortunately, as a consequence of the principle of "assume the best
intention of others", this might include giving the "keys to the
project" to those who need it and are trusted to use those tools to do
their best to achieve the goals of Scalaz. Of course, we now know this
is a mistake. I am deeply sorry for the consequences that others have
been forced to incur as a result of this mistake.

It is my supposition that it is the two points above which have forced
several people, who once used Scalaz as a haven to escape from
undesirable commentary and ill-formed ideas (elsewhere) that have now
been forced upon us, to leave the project entirely. Their goals are no
longer consistent with Scalaz as they once were. They have profited in
many ways by exploiting this haven, which has now been taken away from
them, with no apparent recovery.

[Gershom B]

I don't understand why we're talking about codes of conduct anymore, frankly.

Lars has now stated that the aim of a code of conduct for him is, effectively, to ban Tony.

The problem is Lars does not wish to be in a project with Tony. The institution of a code of conduct was only a means to this end, and the obstacle to a CoC discussion has been that Lars will not accept a code of conduct that does not mean that Tony is banned.

From the start, Lars has had the power to reinstate Tony's access to the repo. Instead, he's kicked him out of the repo, repeatedly. From the start, Lars has had the power to say that there is no CoC until there is a clear discussion. Instead, he's maintained that the current CoC, which he considers bans Tony, must stand. He has the power now to end this, in an instant, by reinstating Tony, who he unilaterally kicked off the project. He has always had this power.

The only problem with any "reset button" proposal is that Lars has repeatedly refused to take any steps towards this.

From the start, the ball has been in his court, where it remains. Instead, he refuses to move at all, or to give anything resembling a full accounting of his actions. His apology has been meaningless, because he stands by the result of his actions. A genuine apology would have been coupled with a reversal of the actions he was apologizing for.

Again, Lars has said he won't be in a project with Tony. That is what has driven everything thus far.

He must either hit the reset button and reinstate Tony (the power has always been his), or step down, or give an accounting as to why he refuses to take either path.

--Gershom

[Edward Kmett]

On Mon, Dec 15, 2014 at 5:28 AM, Daniel Spiewak <djsp...@gmail.com> wrote:

Healing isn't happening, Ed, and it's not going to happen any time soon.  I don't want to prolong the drama indefinitely.  Quite the opposite.  I think this thread is responsible for prolonging the drama as long as it has been (to be clear, that isn't Paul's fault in the slightest; this thread started with the best of intensions).  

 

I'm not blaming Paul for anything. I'm amazed he's managed to stand in the middle of this whole issue as long as he has and not lose his center, but the current approach is burning him out, just as it drove Runar from the project.

Regardless of what my personal feelings are about codes of conduct and what-not, it seems extremely and abundantly clear that now is not the time for Scalaz to hammer one out.  The whole issue is presently tainted by what happened.  Maybe we can discuss it in the future, but for right now, pushing the issue forward only perpetuates this tension and drives contributors away from the project.

Ignoring the issue just legitimizes it. It effectively says "that was okay" and further isolates the significant portion of the community that split off into ##scalaz and feels the status quo amounts to effectively a take over of the project by an outside force. It deepens the wound rather than closes over it.

The CoC was imposed on a community rather than grown with the community. Fundamentally if you want to change the character of interaction with a group like this, if you want them to "buy into a new license" like that you are asking them to join a separate movement, perhaps one with more character and stronger, or at least different, principles, but its a different deal. It is also one that doesn't just by nature of "wanting it" deserve the imprimatur of authority that comes from "being" scalaz.

At present, I see three courses this project could take:

• Drop this issue on the floor without prejudice, and try to move forward from where we were six months ago
• Fork Scalaz
• Allow Scalaz to die, or at the very least dramatically diminish from loss of contributors

The second option is basically untenable for purely technical reasons.  Maven artifact resolution doesn't allow for "separate, but equal" forks of the same project.  One of them has to be primary, otherwise we just generate dependency hell for the entire functional Scala community.  

One of them does have to inherit the existing name, yes.

I'm advocating that if Lars wants a community free of Tony, that he can fork and make one. There is a very well understood process for how this works.

Is a fork a painful proposition? Yes. 

Does it mean all sorts of technical hurdles to adoption? Yes. 

It means all sorts of separate typelevel-scalaz packaging, etc. Folks have to change the name of the artifact they resolve to. There is a short sharp shock and we all move on with our lives.

Does Tony deserve to have to fork his own project back because of a disagreement with Lars? No. 

Lars is the one here saying that he can't work with Tony. I think the burden here falls on the group that wants to change the game.

Additionally, forking Scalaz bifurcates the community of potential contributors.  Even if you don't care about the community of users, the community of contributors is vitally important to the very existence of the project, since those are the people who, you know, actually do the work.

We've already bifurcated the community. They have split into people with a strong enough stomach to deal with the drama and those who are fleeing in terror or just quietly wishing for all of this to go away. Currently the latter crowd includes most of the folks who actually started the project.

But, with a legitimate split, folks don't need to compromise on the character of the code of conduct that they want. It can be much stronger than any crippled half-document that seems possible to pass through the existing process. If they are right about the role of a code of conduct in growing a community then the groundswell of new users that such an approach can support will eventually outweigh the transitional pain. 

Honestly, I think such a community would be a good thing to have exist. We have both #nothaskell and #haskell within the Haskell community, and it has been uniformly a force for good. 

I would love for some good to come of this in that respect. 

Various flavors of BSD continue to exist and exchange code, despite different organizing principles and certain strong personalities being unwelcome across the aisle.

Moreover, the desire to include all sorts of technical just "agree to disagree on technical issues, its all opinions anyways" stuff in the CoC is a grand experiment as well. It risks losing all signal in the noise. Is it worth it for greater harmony? I'm not sure, I suspect not, but I've been surprised before.

Say what you will about Tony, but he did provide a strong set of organizing principles and a skeleton for a cohesive design that fits together.

The third option is unappealing by definition.  In fact, it is so unappealing that I doubt it could actually happen, since option 2 would be chosen by a subset of the community were option 3 to ever transpire.

 

This isn't a death knell for scalaz. Unlike the wisdom of Solomon, the baby here is a conjoined twin and one or both can survive the process, but it is currently sickening by the day.

The third option is happening by default as we doggedly continue to try to pursue #1.

I really think option 1 is the only way to go.  This thread proves that the hypothetical compromise option isn't going to happen (where we develop a mutually-agreeable CoC and bring people back into the fold).

Option 1 is no option at all, it is a fantasy. Telling someone to "get over it" is a great way to get them to nurse a grudge. I'd love it if we could all get drunk at a bar together, but I have friends on both sides of this debate who will probably never talk to each other again. This pains me a great deal, but that won't cause me to put my head in the sand and pretend it isn't happening. 

If we continue to ignore the situation, we'll just be having this discussion again in a month or two, among fewer people.

-Edward

[Chris Marshall]

Edward wrote: "I personally think this sequence of events shows very much the opposite, that we have a demonstrated inability to apply such a CoC."

+1

I think Daniel is talking a lot of sense here too. Where that leaves things is anyone's guess.

--

[Simon Ochsenreither]

Your suggestion seems to presume that the goal of scalaz is to be used. It is not. It never has been. The goal is to be useful.

Looking at it from a different angle, it would certainly reduce the amount of people having to change their build files if those who care about users keep the name and those who care primarily about the usefulness for their own purposes pick the fork.

[Daniel Spiewak]

Does it mean all sorts of technical hurdles to adoption? Yes. 

It means all sorts of separate typelevel-scalaz packaging, etc. Folks have to change the name of the artifact they resolve to. There is a short sharp shock and we all move on with our lives.

This is not a sharp shock and we move on with our lives.  We live on the JVM, and the JVM doesn't have a real module system.  Forking an upstream utility project generates ongoing pain that we will never overcome.  Sure, you can namespace off everything in the fork such that stupid classloading doesn't cause conflicts, but you're never going to have sane interop, and every single project that cares at all about using Scalaz has to choose between one or the other.  Specs2, notably, uses Scalaz, which instantaneously picks a winner for 90% of the Scala community.  There's plenty of other examples of this.

So unless one fork gets to keep the name, the package, the artifact ID, the GPG keys registered with Sonatype, and the loyalty of the entire functional Scala ecosystem, we're in a land of deep suckage for a long time.

In other words, we either have two forks of Scalaz, one which is ignored by the entire community save a few niche followers and one which is the de facto standard that everyone uses, or we're in dependency hell from now on.

 

Does Tony deserve to have to fork his own project back because of a disagreement with Lars? No. 

I'm not going to give anyone special rights to a project just because they were the first to it.  Tony hasn't been the primary committer on Scalaz for years.  Is he an important part of the contributing community?  Yes.  Does he merit a say in the future of the project?  Absolutely.  Is it his project?  Not even close.

 

Option 1 is no option at all, it is a fantasy. Telling someone to "get over it" is a great way to get them to nurse a grudge. I'd love it if we could all get drunk at a bar together, but I have friends on both sides of this debate who will probably never talk to each other again. This pains me a great deal, but that won't cause me to put my head in the sand and pretend it isn't happening. 

I have exactly zero hope that the situation will ever come to a positive end.  At this point, I'm frankly in damage control mode trying to do whatever I can to blow into the sails of a project that I depend on for my day-to-day work.

Daniel

[Paolo Giarrusso]

Dear Stephen, dear all

your email gets at the core issue: if you were right, many design debates would be between science and obscurantism and their tone justified.

I'm certain Scalaz should have one coherent, non-compromise-based design. But it won't and can't be a scientific design. This email will try to debunk this widespread misconception, and test your claim:

> "Prepare to be wrong, and to be told you're wrong.  Our goal in Scalaz is to become right, factually, not pretend we're right."

Of course, I welcome contrary evidence.

Compared with hard sciences, there aren't many facts in evidence. Language design (which does not include mathematical truths) is nowadays mostly philosophy, not science; I think that's entirely fine and that's enough to make scalaz what it is, it just does not legitimate insulting alternative philosophies. I do believe that our philosophy will produce better conjectures than Aristoteles' theory of gravity. Also, parts of our arguments are based on math, the best foundation you can have — but next to it, there are parts which could only be based on cognitive science, which is much swampier territory.

In fact, programming language researchers who went beyond math into design have seldom done hard science, and nowadays the community is starting to debate this problem, even though we lack scientific tools to investigate language design. (On this, see also http://www.codemesh.io/static/upload/media/141562653162935languagewars.pdf and http://www.codemesh.io/static/upload/media/141562653162935languagewars.pdf, though I don't fully agree with all details). To be sure, I do believe that we are making progress by following some design principles (heck, I'm working on entering that community by being a PhD student and writing papers), but we don't fully know how true they are. To be sure, some researchers are worse offenders, and I'm sorry we scholars don't stigmatize them enough.

That's why I like Steven Shaw's points better — he cites Simon Peyton Jones, and since Scalaz is strongly inspired by Haskell, I feel that's an example we should think hard about.

https://medium.com/@steshaw/adopting-a-cambridge-culture-2e16ec53137f

On Monday, December 1, 2014 2:05:30 AM UTC+1, Stephen Compall wrote:

On Thu, 2014-11-27 at 21:41 +0100, Lars Hupel wrote:

They aren't always tradeoffs, and there often is a clear winner, [...]

I think, instead, in most such cases, we merely lack information to determine the clear winner, or a framework for connecting our information to correct conclusions.  To define such discussions as having "no clear winner" is to devalue the research that goes into finding the clear winner, and the justification for declaring it the clear winner, and thus to discourage fact-based design.  This can only work in favor of compromise-based design.

Rust does not seem a compromise-based design, yet their CoC is apparently stricter than the ones proposed for Scalaz: https://twitter.com/jonsterling/status/542431462218162177.

As a case study on presumed facts, I'll analyze https://github.com/scalaz/scalaz/issues/671 (cited earlier in CoC discussions). That discussion revolves about coherence for type class instances, versus the fact that some types have many natural instances for some type classes. In the research community, there's an open debate in the research community between Haskell type classes and ML-like modules (see for instance http://www.cse.unsw.com.au/~chak/papers/mtc-popl.pdf), and while Haskell does have one interesting answer to some problems, namely coherence, it has drawbacks, and there's an open debate about it (http://blog.ezyang.com/2014/07/type-classes-confluence-coherence-global-uniqueness/) where some contributors suggest Haskell should abandon it!

Now, Scalaz should remain free to make this tradeoff. But pretending that's the only alternative prevents from looking at the truth *and* legitimizes unwarranted insults or dismissive dogmatic comments such as:

> It is possible to debunk this nonsense with a whisper of breath. It is annoying to be compelled to expend any further effort on it. I refuse to do so.

which run counter the first CoC proposed in this discussion.

Compromise as a design principle may be right for government legislatures, but it isn't right for Scalaz.  We have the tools at hand to find the right answer, and we're principled enough to say that when there's a right answer, based on fact, the other answers are just wrong.

The best illustration for this is law-breaking instances.  Time and again, people have asked for law-breaking instances to be added, restored, or not removed.  Yet we remove them, because it's right, and when it comes to local convenience versus global reasoning, global reasoning is the clear winner.

That's relatively clear-cut compared to other issues, and I want to program by that principle, but let's not delude ourselves into "that's scientific fact" — it's not even precise enough to be false. What's the question?

Many would say that the question (in programming/library design) is "how do we help programmers (without restrictions) to program correctly and conveniently?" But that's clearly not Scalaz's goal:

> The goal of scalaz is to be used. It is not. It never has been. The goal is to be useful.

The goal's closer to "how do we help 'Haskell-liking' programmers to program correctly and conveniently?", where 'Haskell-liking' is a very vague concept.

But it's impractical to check whether we achieve this goal with the scientific method (that is, with scientific studies on such programmers), so let's not delude ourselves by talking about science.

None of this needs to be stated in a Code of Conduct.  This is how Scalaz has always operated; observing this devotion to correctness played the primary role in attracting me to Scalaz, and it's what continues to hold my interest.  We're scientists, and while we're human and sometimes prone to feeling protective of our ideas and designs, even when they turn out to be wrong, we've proven willing to acknowledge their wrongness when faced with the facts.

So I hope you (and others) will consider my points.

Hence, no point in dogmatically
asserting that one is better than the other.

Even when we don't have enough information, given available information, one is often better.  Now, that may change, or even reverse, once new things are discovered, but that doesn't change that fact!

With respect to the example you've given, invariance in transformers and higher kinds is better than variance, given our current information.  Maybe more information will arrive later to change that outcome.  Maybe new information will just reinforce that decision, or maybe we'll never learn anything else about it.  That's not a sufficient reason not to say we haven't made the right decision, today.

That's still not a dogmatic assertion, but a reasoned argument, which will have a different tone.

If a Scalaz contributor sees that one alternative is clearly better in a design discussion, they should say so.  You can say, "I am aware of these caveats, a, b, and c, but they do not outweigh the benefits d, e, and f", and form a much stronger position than if you pretend that a, b, and c don't exist.

I like this phrasing — it's much more accurate than some objectionable statements one sees sometimes.

 

I have said that it's not necessary to state this in a Code of Conduct.

Documenting the design principles might help newcomers. Or steer them off if they figure Scalaz is not for them. Finally, it might help the evolution of the community: Scalaz is beyond the point where "everybody just knows the rules".

[Tony Morris]

Are we there yet?

--

[TexasMynsted]

This has been a ridiculous waste.  It is time to move forward by implementing a variation on Rob Norris's plan.

1. Eliminate the CoC
    It seems to do nothing but eliminate a valuable and outspoken leader.

2. Reinstate both Lars and Tony.

    We need both their voices to ensure everybody is heard.  A single benevolent dictator is still a dictator. 
    I would guess most dictators think they are benevolent, and many actually start out that way.  I feel I need both voices to ensure mine is heard.
 
3. Fully expose and remember what happened so it does not happen again.
    This whole situation feels like some kind of clandestine chicanery or coup d'état.  The only way I see to overcome that is to expose everything to public scrutiny, and ensure
     we do not make the same mistakes.

After those things are done, if there are still irreconcilable differences, then by all means fork off (to a new project).  Who knows, there could be real value to having two such projects.