Discussion about a Scalaz Code of Conduct

1,132 views
Skip to first unread message

Paul Chiusano

unread,
Oct 27, 2014, 10:47:15 AM10/27/14
to sca...@googlegroups.com
Hi everyone,

As promised, this is the start of a thread to discuss a code of conduct. We'll be developing this in the open, with feedback from everyone who cares to participate. Let's try to make this thread polite and civil, an example of the sort of discourse we want to have going forward. Robust debate and differing opinions about the ideas are good, but let's not make it personal or have things devolve into ad hominem attacks. And I really want us to focus on what we are doing for the future rather than getting into arguments about who did what wrong in the past.

I'm optimistic that we can develop something that folks can get behind and feel good about. Lars did put up a CoC on the typelevel site but I'd like to get consensus on some key questions before debating the actual wording of the document we produce. Getting consensus and buy-in from folks is just as important (if not moreso) than the written document.

For the CoC, there are questions about scope (where should it apply), content (what should be in it), and process / enforcement (what is process for dealing with violations, and who is in charge or enforcement). Below, I'll try to list some questions and thoughts about each of these to help spur the discussion.

After people have a chance to discuss on this thread, I'll try to aggregate all the feedback and produce a draft CoC. We can then have a further round of comments on that draft, and then hopefully finalize something. My hope is that there will be broad consensus on what we produce, but if there is conflict and there needs to be a decision among competing opinions, I nominate myself and Lars, with a tiebreak from Jason Zaugg, to produce the final official version.

Let's keep this to a discussion about a CoC for the scalaz project. I'd like to avoid having this thread turn into a discussion about the role of typelevel, since there are widely differing views on that and I don't want to entangle that discussion with the immediate issues facing scalaz. If other projects want to adopt some variation of what we come up with, or if we want to get all the typelevel projects to agree on a common CoC which is similar to what we develop, those discussions can certainly happen later. That said, if non-scalaz folks are lurking and want to pipe in with their thoughts, that is fine with me.

One other thing - Lars, I think you were interested in developing some official norms for scalaz comitters and contributors, and I agree that would be great. This would cover things like - what sorts of changes should go through a PR process. (IMO, everything except minor stuff) Expectations about testing (don't just push code with no unit tests, duh). And any norms wrt to discussion in GitHub issues that isn't covered by the general CoC developed here. I propose that you put together a draft and send it around for comment *in a separate thread* from this one.

Okay, here are the key things I think need discussing with regard to a Scalaz CoC - 

Scope:

I think whatever we develop should apply and be enforced (in whatever way we decide) on #scalaz, this list, and at any other official Scalaz venue or gathering. There may be differing opinions about whether a CoC should be also be enforced on channels like Twitter and people's personal blogs.

My own view: it's not appropriate for a Scalaz CoC to attempt to police how people act in their own personal spaces on the web, where no one is obligated to listen to you anyway. Individuals are certainly within their rights to express their displeasure about how someone communicates on their blog, but that would be as far as it goes, unless this carries over into bad behavior in any of the official channels. Other people may disagree with this.

Content:

Here are few example codes of conduct we may want to draw from:


I'd encourage folks to read through those and think about what you like and don't like about them and post any thoughts here. If people know of other examples that they like, please do send out a link to the group.

Here are few general remarks / food for thought:

* I like that the Scala CoC has a pretty clear process for dealing with violations. We can quibble about the specifics, but I'd like to have something like this in our CoC, so no one is surprised by how things are handled. This also feels more fair to me.

* I like the YAPC CoC because it's well organized - I like the separation into sections, and I like that the scope is clear, and consequences are pretty clear. I also think it makes a useful distinction between "Expected behavior" and "Unacceptable behavior". We may want to think about what goes in what bin, and how to respond in each case. Like being "considerate and civil" is what I'd consider "expected behavior". Harassing someone about their religion, race, gender, or ethnicity is what I'd consider "unacceptable behavior".

* I like this bit from Lars' draft - "In particular, participants and community organizers should not use sexualized images, activities, or other material." I can't recall a time when this has been an issue in the scalaz community, but now seems like a good opportunity to develop a more official policy that this sort of thing is uncool.

* None of these example CoCs capture something that I think is pretty important. Namely that I'd like it if everyone takes some responsibility for helping to make sure the community is one you want to be a part of. This works in two directions. 1) If you witness someone acting in a way you don't like, try to give them feedback on that directly, in the moment. And 2) I'd like it to be a norm that such feedback is welcome and encouraged. If you are on the receiving end of some feedback about your behavior, give it serious thought rather than getting immediately defensive. This doesn't eliminate the need for official moderators, but it would be nice if we could police ourselves especially for the small stuff, rather than relying on policemen to do everything.

* I don't want a CoC to discourage people from having robust debate and discussion about ideas. The key is that such debates and discussions are not made personal. So not "you're an idiot" or even "that idea is idiotic", but rather "I don't like that idea for reasons X, Y, Z", which keeps the focus on the technical issues.

Process / enforcement:

* How will this be enforced, and by whom? Should we have different moderator(s) for each of the official channels? If there is disagreement about how a situation should be handled, how should that be resolved? My initial thought is to have one official moderator for each venue - #scalaz, this list, and GitHub, with the understanding that if any serious action is being considered, all three will get together and discuss. But maybe people have other ideas.
* What is the process by which violations are dealt with? As I mentioned before, we should have something that's pretty clear, and included in the CoC, so no one is surprised by what happens in the even there's bad behavior.

Okay, that's all I have to get this started. I look forward to a productive discussion! I'm not going to set a timeline for this initial phase, we'll just play it by ear and see when the discussion starts winding down. I'll try to step in and moderate here and there to make sure that the discussion moves forward and doesn't get stuck in bikeshedding.

Cheers,
Paul :)

Martijn Hoekstra

unread,
Oct 27, 2014, 4:07:21 PM10/27/14
to sca...@googlegroups.com


On Oct 27, 2014 3:47 PM, "Paul Chiusano" <paul.c...@gmail.com> wrote:
>
> Hi everyone,
>
> As promised, this is the start of a thread to discuss a code of conduct. We'll be developing this in the open, with feedback from everyone who cares to participate. Let's try to make this thread polite and civil, an example of the sort of discourse we want to have going forward. Robust debate and differing opinions about the ideas are good, but let's not make it personal or have things devolve into ad hominem attacks. And I really want us to focus on what we are doing for the future rather than getting into arguments about who did what wrong in the past.
>
> I'm optimistic that we can develop something that folks can get behind and feel good about. Lars did put up a CoC on the typelevel site but I'd like to get consensus on some key questions before debating the actual wording of the document we produce. Getting consensus and buy-in from folks is just as important (if not moreso) than the written document.
>
> For the CoC, there are questions about scope (where should it apply), content (what should be in it), and process / enforcement (what is process for dealing with violations, and who is in charge or enforcement). Below, I'll try to list some questions and thoughts about each of these to help spur the discussion.
>
> After people have a chance to discuss on this thread, I'll try to aggregate all the feedback and produce a draft CoC. We can then have a further round of comments on that draft, and then hopefully finalize something. My hope is that there will be broad consensus on what we produce, but if there is conflict and there needs to be a decision among competing opinions, I nominate myself and Lars, with a tiebreak from Jason Zaugg, to produce the final official version.
>
> Let's keep this to a discussion about a CoC for the scalaz project. I'd like to avoid having this thread turn into a discussion about the role of typelevel, since there are widely differing views on that and I don't want to entangle that discussion with the immediate issues facing scalaz. If other projects want to adopt some variation of what we come up with, or if we want to get all the typelevel projects to agree on a common CoC which is similar to what we develop, those discussions can certainly happen later. That said, if non-scalaz folks are lurking and want to pipe in with their thoughts, that is fine with me.
>
> One other thing - Lars, I think you were interested in developing some official norms for scalaz comitters and contributors, and I agree that would be great. This would cover things like - what sorts of changes should go through a PR process. (IMO, everything except minor stuff) Expectations about testing (don't just push code with no unit tests, duh). And any norms wrt to discussion in GitHub issues that isn't covered by the general CoC developed here. I propose that you put together a draft and send it around for comment *in a separate thread* from this one.
>
> Okay, here are the key things I think need discussing with regard to a Scalaz CoC - 
>
> Scope:
>
> I think whatever we develop should apply and be enforced (in whatever way we decide) on #scalaz, this list, and at any other official Scalaz venue or gathering. There may be differing opinions about whether a CoC should be also be enforced on channels like Twitter and people's personal blogs.
>
> My own view: it's not appropriate for a Scalaz CoC to attempt to police how people act in their own personal spaces on the web, where no one is obligated to listen to you anyway. Individuals are certainly within their rights to express their displeasure about how someone communicates on their blog, but that would be as far as it goes, unless this carries over into bad behavior in any of the official channels. Other people may disagree with this.
>
> Content:
>
> Here are few example codes of conduct we may want to draw from:
>
> * http://docs.scala-lang.org/conduct.html - the Scala CoC
> * http://www.yapcna.org/yn2013/code-of-conduct.html (for a conference)
> * http://opensourcebridge.org/about/code-of-conduct/
> * http://typelevel.org/conduct.html - Lars' draft CoC

As an absolute outsider I'd like to point to freenodes policy ( https://freenode.net/policy.shtml ) and channel guidelines ( https://freenode.net/channel_guidelines.shtml ) as well to take in to account as far as the CoC applies to #scalaz.

--Martijn

>
> I'd encourage folks to read through those and think about what you like and don't like about them and post any thoughts here. If people know of other examples that they like, please do send out a link to the group.
>
> Here are few general remarks / food for thought:
>
> * I like that the Scala CoC has a pretty clear process for dealing with violations. We can quibble about the specifics, but I'd like to have something like this in our CoC, so no one is surprised by how things are handled. This also feels more fair to me.
>
> * I like the YAPC CoC because it's well organized - I like the separation into sections, and I like that the scope is clear, and consequences are pretty clear. I also think it makes a useful distinction between "Expected behavior" and "Unacceptable behavior". We may want to think about what goes in what bin, and how to respond in each case. Like being "considerate and civil" is what I'd consider "expected behavior". Harassing someone about their religion, race, gender, or ethnicity is what I'd consider "unacceptable behavior".
>
> * I like this bit from Lars' draft - "In particular, participants and community organizers should not use sexualized images, activities, or other material." I can't recall a time when this has been an issue in the scalaz community, but now seems like a good opportunity to develop a more official policy that this sort of thing is uncool.
>
> * None of these example CoCs capture something that I think is pretty important. Namely that I'd like it if everyone takes some responsibility for helping to make sure the community is one you want to be a part of. This works in two directions. 1) If you witness someone acting in a way you don't like, try to give them feedback on that directly, in the moment. And 2) I'd like it to be a norm that such feedback is welcome and encouraged. If you are on the receiving end of some feedback about your behavior, give it serious thought rather than getting immediately defensive. This doesn't eliminate the need for official moderators, but it would be nice if we could police ourselves especially for the small stuff, rather than relying on policemen to do everything.
>
> * I don't want a CoC to discourage people from having robust debate and discussion about ideas. The key is that such debates and discussions are not made personal. So not "you're an idiot" or even "that idea is idiotic", but rather "I don't like that idea for reasons X, Y, Z", which keeps the focus on the technical issues.
>
> Process / enforcement:
>
> * How will this be enforced, and by whom? Should we have different moderator(s) for each of the official channels? If there is disagreement about how a situation should be handled, how should that be resolved? My initial thought is to have one official moderator for each venue - #scalaz, this list, and GitHub, with the understanding that if any serious action is being considered, all three will get together and discuss. But maybe people have other ideas.
> * What is the process by which violations are dealt with? As I mentioned before, we should have something that's pretty clear, and included in the CoC, so no one is surprised by what happens in the even there's bad behavior.
>
> Okay, that's all I have to get this started. I look forward to a productive discussion! I'm not going to set a timeline for this initial phase, we'll just play it by ear and see when the discussion starts winding down. I'll try to step in and moderate here and there to make sure that the discussion moves forward and doesn't get stuck in bikeshedding.
>
> Cheers,
> 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+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.

John Ky

unread,
Oct 27, 2014, 11:00:15 PM10/27/14
to sca...@googlegroups.com
Hi Everyone,

I'm speaking as someone who is just an observer on Scalaz.

I would like to take Paul's invitation to offer some ideas.

The CoC could benefit from having more detail on how to enforce the CoC in the face of CoC violation.  Such detail may reside in a separate document, the benefit of which is so that the CoC can remain short and relevant all community participants.

The process should be such that there is widespread trust in the process.  We want to avoid situations where leaks are made and where conflicts and disputes are expanded to the whole community.

The process should allow for iteratively self-improvement so that over time community expectations about the process and what actually happens converges.  

In terms of actual process, I think something along the lines of Harm minimisation >>= Mediation >>= Disciplinary action would be useful.

Harm minimisation
Some of the behaviour that violates the CoC could either be very serious or require urgent attention.  Severity and urgency, are orthogonal concerns.  Timely intervention might prevent a situation from becoming severe and is necessary to protect community participants, whilst a rushed intervention could cause a situation to become severe.

Community organisers (undefined in CoC) as individuals ought to be able to have access to non-disciplinary measures ranging from moderation to blocking individuals on a very temporary basis.  The point of this power should be to prevent harm, not to punish.  It should be by the judgement of the community organiser, apply no longer nor be no more severe than necessary to prevent harm or escalation.

Intervention of this nature should be publicly disclosed in a way that protects the privacy of involved participants as much as practical.  Disclosure should include the purpose of the intervention, duration of the intervention and a pathway to restoration of rights or mediation.

Mediation
Disputes or violations of the CoC should be resolved as much as possible by mediation.  It should involve a mediator who is impartial and not involved in the dispute.  It shouldn't be the same person who has intervened, since the mediator would need to mediate with that person as well.  The role of the mediator should be to try to extract concessions or agreement from individuals involved in a dispute in order to resolve the dispute via consensus without using disciplinary action.

The details of the mediation process should be kept private, but any outcome or agreement that should arise from the process should disclosed.  The mediator should also be allow to make recommendations to the community on how the process can be improved.

Disciplinary action
Disputes or violations of the CoC that cannot be resolved by mediation will need to be resolved by disciplinary action.  This ought to involve a wider circle of community organisers who will act on the recommendation of the mediator.  Its decision should be final and should be disclosed.  The final decision should include conditions for the lifting of the disciplinary action if any are applicable.

The process should also give consideration to legal obligations, how to achieve the impartiality of the moderator, how to balance privacy and disclosure, reporting requirements, and the range of non-disciplinary and disciplinary actions.

Cheers,

-John

Runar Bjarnason

unread,
Oct 27, 2014, 11:26:36 PM10/27/14
to sca...@googlegroups.com
I just want to chime in to say that we should be very careful to not structure the CoC too much like a bylaw or contract. This can create a "reasonable expectation" of enforcement which opens administrators up to legal risk. (this is my attorney's advice)

It's important to keep the context in mind here. We're not saving the world. We're individuals collaborating on making a library. There's never going to be a Scalaz emergency. I like the Scala CoC for the reason that it is explicitly not structured as a bylaw, but instead just lays out principles for collaboration.




--

Lars Hupel

unread,
Oct 30, 2014, 5:32:42 PM10/30/14
to sca...@googlegroups.com
Hi,

> I'm optimistic that we can develop something that folks can get behind and
> feel good about. Lars did put up a CoC on the typelevel site
> <http://typelevel.org/conduct.html> but I'd like to get consensus on some
> key questions before debating the actual wording of the document we
> produce. Getting consensus and buy-in from folks is just as important (if
> not moreso) than the written document.

first thing to note is that, as I've written elsewhere, that CoC is not
set in stone. Of course, there's room for improvement (there have been two
issues opened on GitHub already, e.g. asking for clarification about the
enforcement).

> Let's keep this to a discussion about a CoC for the scalaz project. I'd
> like to avoid having this thread turn into a discussion about the role of
> typelevel, since there are widely differing views on that and I don't want
> to entangle that discussion with the immediate issues facing scalaz. If
> other projects want to adopt some variation of what we come up with, or if
> we want to get all the typelevel projects to agree on a common CoC which
> is
> similar to what we develop, those discussions can certainly happen later.
> That said, if non-scalaz folks are lurking and want to pipe in with their
> thoughts, that is fine with me.

Sure. Presumably though, if we end up extending the current CoC, or
propose a different one which is not much "weaker" than the one on
typelevel.org right now, I think broader adoption is not a problem.

> One other thing - Lars, I think you were interested in developing some
> official norms for scalaz comitters and contributors, and I agree that
> would be great. This would cover things like - what sorts of changes
> should
> go through a PR process. (IMO, everything except minor stuff) Expectations
> about testing (don't just push code with no unit tests, duh). And any
> norms
> wrt to discussion in GitHub issues that isn't covered by the general CoC
> developed here. I propose that you put together a draft and send it around
> for comment *in a separate thread* from this one.

Okay, will do.

> My own view: it's not appropriate for a Scalaz CoC to attempt to police
> how
> people act in their own personal spaces on the web, where no one is
> obligated to listen to you anyway. Individuals are certainly within their
> rights to express their displeasure about how someone communicates on
> their
> blog, but that would be as far as it goes, unless this carries over into
> bad behavior in any of the official channels. Other people may disagree
> with this.

What we can do though is to phrase it in such a way that we emphasize what
we'd like to see elsewhere. Especially if we add a positive section to the
CoC, one could say e.g.

"We encourage all community members to apply the same standards to their
own personal blogs, social media accounts and other public spaces. We can
all work together on giving a good impression of our community."

(This obviously needs rewording by someone better in English than me.)

The reason why this might be a good idea is that no, people are not
obligated to listen, but they will listen anyway, and draw their
conclusions. I also think that someone who behaves badly on their Twitter
is also likely to behave badly elsewhere. We should try to make it clear
that as a community we don't want to be associated with any of that.
I like the Scala CoC, especially because of the positive parts. I think we
should steal some ideas from there. A candidate is the section about "Be
Excellent". In the same spirit, we could have another section called "Be
Charitable", which would positively explain in what way we think other
people's writing should be interpreted.

A disadvantage of the Scala CoC is, IMHO, the "Be Thorough" part. It could
potentially discourage newcomers to report bugs of which the specific
cause is unclear. However I think these kinds of contributions are
extremely important. On the other hand, responses like "this is wrong" in
an argument without giving a reason are detrimental, so this should be
clarified.

> * I like that the Scala CoC has a pretty clear process for dealing with
> violations. We can quibble about the specifics, but I'd like to have
> something like this in our CoC, so no one is surprised by how things are
> handled. This also feels more fair to me.

Yes. This definitely needs to be specified.

> * None of these example CoCs capture something that I think is pretty
> important. Namely that I'd like it if everyone takes some responsibility
> for helping to make sure the community is one you want to be a part of.
> This works in two directions. 1) If you witness someone acting in a way
> you
> don't like, try to give them feedback on that directly, in the moment. And
> 2) I'd like it to be a norm that such feedback is welcome and encouraged.
> If you are on the receiving end of some feedback about your behavior, give
> it serious thought rather than getting immediately defensive. This doesn't
> eliminate the need for official moderators, but it would be nice if we
> could police ourselves especially for the small stuff, rather than relying
> on policemen to do everything.

That's also very important, and has been written on this list as well.

> * I don't want a CoC to discourage people from having robust debate and
> discussion about ideas. The key is that such debates and discussions are
> not made personal. So not "you're an idiot" or even "that idea is
> idiotic",
> but rather "I don't like that idea for reasons X, Y, Z", which keeps the
> focus on the technical issues.

Another important point here is to acknowledge that there is not a single
objective truth. I'm not yet sure how that could be phrased, but something
along the lines of "Keep in mind that different people might emphasize
different points, so an inconclusive result in a technical argument is
entirely possible" could go a long way.

> * How will this be enforced, and by whom? Should we have different
> moderator(s) for each of the official channels? If there is disagreement
> about how a situation should be handled, how should that be resolved? My
> initial thought is to have one official moderator for each venue -
> #scalaz,
> this list, and GitHub, with the understanding that if any serious action
> is
> being considered, all three will get together and discuss. But maybe
> people
> have other ideas.

Sounds good. Writing that down is definitely a good idea, so that in the
future situations like this can be avoided.


Apart from the points above, I think Paul is on the right track. Thanks!
Lars

eec...@gmail.com

unread,
Nov 2, 2014, 3:07:56 PM11/2/14
to sca...@googlegroups.com
If the code of conduct is longer or more detailed than a few statements, people will start hiding behind them: "It's not in the code of conduct". My guess is that it works better if discussions are started about the topic instead of the code of conduct itself.

On top of that, for me personally, open source software is about freedom. I spend my free time working on stuff that I give to others for free in order to inspire them to create cool shit. I hope that my work helps them to achieve their goals. A handbook or manual on how to handle certain situations seems to much.

I would suggestions something like this:
  • Try to remember that the other person is on his (or her) own journey in programming
  • If you feel the other person is lazy and wants you to do their work: ask questions to prove otherwise.
  • If you feel the other person is being rude: ask questions to prove otherwise.
  • When you ask a question, it helps when you clearly state if it is academic or work related. Do you want to understand the principles or do you want to get it working?

Erik

Paul Chiusano

unread,
Nov 2, 2014, 8:29:22 PM11/2/14
to sca...@googlegroups.com
Thanks for the responses from everybody so far. I think we have some good things to work with. I'm thinking what we'll do if there isn't much further discussion is give folks until Wednesday, and then I'll try to take what's been discussed and put together a draft that we can react to.

I was thinking some more about what I think is important about Scalaz, and I came up with three principles. I'm not sure if these are part of the CoC we write but I'll just put them out there:

1. Be civil: at a minimum, be civil to others; strive to be warm, welcoming, kind, patient, and charitable, especially when expressing disagreement.
2. Be excellent: strive for the highest level of technical excellence. Seek out the best ideas via direct and rigorous discourse, and be encouraging and welcoming of robust discussion and debate.
3. Welcome feedback and give feedback: be open and welcoming of feedback from others on how to communicate better. Take opportunities to give feedback to others. Help make the community one you want to be a part of.

I think the 1) Be civil is something that is on everyone's minds, but the 2) and 3) are really important too. I do not want people to be afraid to make controversial statements or have a rigorous technical discussion (which could include dismantling or seriously criticizing various technical ideas) out of fear that some might be offended. As long as such discussions are civil (no personal attacks, calling people names, swearing at others, etc), I think it is critical that they be encouraged.

And 3) is important because I've started to think it is not feasible (or appropriate) to have a CoC that tries to *enforce* issues of tone and communication style, which are inherently subjective. Barring the obvious stuff (personal attacks, racist / sexist remarks and the like), I think it makes more sense to "enforce" the more subtle stuff with a culture of feedback. I do not want to boot someone from the channel just because their style is a bit more abrasive or less kind than I think it could have been, however I would like to give that person feedback (if I am there to notice it). If it's a norm that such feedback is welcome, I'm hopeful that the more subtle stuff can become more like cultural norms, rather than rules enforced via top down policing.

Thoughts?

Paul :)

--

Matthew Pocock

unread,
Nov 3, 2014, 7:54:53 AM11/3/14
to sca...@googlegroups.com
Hi All,

I've been holding off responding to this because a) I'm only peripherally involved in scala development b) I've not read all the documents or the past exchanges c) codes of conduct in my experience can turn into a bike-shed bun fight. However, I would like to throw out a few things if that's OK.

Codes of conduct serve several different purposes. It has utility for people joining a community that are different from those of people who are established within it. For example:

1: Clarity about expectations about what a community is like for those joining it, how welcoming and inclusive an outsider will find it, some expectations that people who join and troll will be shown the door

2: A yard-stick for if you are over-reacting or if something is sufficiently out-of-line that it needs addressing, because sometimes we all over-react

3: Demarcation for when you've overstepped and need to apologise or remove yourself

There are other things. It needs to be short enough and clear enough that people can briefly read it, and that it sounds like a community standard, not a legal document (very important distinction IMHO).

The very fact that we're having this discussion means that there have been issues about conduct, but also that the community feels that there are standards of conduct worth upholding. This is a positive thing, because some communities don't recognise this and don't notice or care when things over-step.

Lastly, here's an incomplete list of things that I feel a CoC needs to cover for an inclusive, open, welcoming and above all, community-driven social standard of behaviour:

1. respect: Always respect the person, even if you don't respect their beliefs or opinions, and even when they are self-evidently wrong. The person deserves to be treated with respect. If you think their ideas don't, then address that to their ideas, not to them as people.

2. inclusion: Everybody can be involved in some role with coding. There are a multitude of roles. None of these are related to that person's age, gender, sexuality, religion, politics, hair color, education or any other personal attribute. This cuts both ways. Don't make your code opinions about these other things, and don't argue other people's code on the basis of these things.

3. safety: All people within the community, from the first day they hit a q&a or bug report via google, should feel that this community is a safe space. This sometimes means being careful with language so as not to appear to attack people, particularly people that you think know less than you. The health of a coding community is measured by the volume of noobs you attract and keep, not the number of code wizards that were there from the start.

Lastly, most of the time there should be no need to even make an issue of this stuff. Nothing puts me off a community more than having to read and sign some equalities statement before I even set foot on the forum. If you push these things in people's faces, you're making an issue of something that in the normal course of things shouldn't be an issue.

That's all really. Be excellent to one-another.

Matthew

--
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.



--
Dr Matthew Pocock
Turing ate my hamster LTD

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

skype: matthew.pocock
tel: (0191) 2566550

Tony Morris

unread,
Nov 3, 2014, 7:32:45 PM11/3/14
to sca...@googlegroups.com

I cannot respond before Wednesday.

Paul Chiusano

unread,
Nov 3, 2014, 7:41:17 PM11/3/14
to sca...@googlegroups.com

Okay, take your time. I threw Wednesday out there, but we can definitely wait until later. I don't think there is a big hurry and I want everyone who wants to weigh in to have a chance to do so.

We'll also have an opportunity to discuss further after I put together a draft based on people's feedback.

Paul :)

Alois Cochard

unread,
Nov 6, 2014, 4:50:52 PM11/6/14
to sca...@googlegroups.com
Hey everyone,

I'm very sad that I feel like I have to send the following email today, specially because I consider *all* persons involve in the conflict as friends. I truly mean this.
The thing is that I expect to be able to reasonably discuss with my friends when a problem occur, that's why I'm sad today because I felt it was not possible with Lars.

Today, I did ask a question on IRC to which I followed with some swearing on scala forcing me to be explicit about my type application (ref: http://pastie.org/private/wqml9bmunfajq9ygcohsew).

Yes I swear, that how I am, I swear because that allow me to express my emotion, and expressing my emotions is a massive part of what I consider make me a human.

I like to swear, I like when others swear, not all the time of course... not in an abusive way (yes that's subjective...) but that make the life more interesting to me. It's like using emoticons, it bring feelings to otherwise emotionless humans (online) interactions.

What would be a life where everyone would be polite all the time? A world where no one ever complain, where everything is always accepted as is?
Well, I'll tell you what I think of a world like that with my own (swear) words: That would be so fucking boring.

When Lars comes to discuss privately with me, I was hoping to have some kind of discussion like I usually do have with my friends... even when we are upset about each others... we try to understand each other differences and move on... but here is how it went:

Following that I decided to leave (I am **not** banned) the #scalaz and #typelevel channels as it's not clear to me how one can communicate in those rooms without fearing that Lars might find what that person say unacceptable.

According to the log it seems there was few discussion after I left:

Which encouraged me to write the email your are currently reading ...

I think there is two main aspects of management in an open source project:

- Managing the **technical** part of an open source project
- Managing the **social interaction** between the contributors and moderate them

These are two very different skill-sets, I can count on one hand the persons I've met who have both.
Lars is amazing at the first one -no freaking doubt about it- but today, it's obvious to me that he unfortunately lack the skills required for the second one.

I'm not interest to discussing the details of a CoC, nor that I'm interested in wasting any of Paul time for some mediation, I have expressed my opinion and I'll simply see what is the result of the discussion...
Lars, I'm happy to discuss about it directly with you if you like (but you seems more inclined having discussion on the subject here), you know how to contact me anyway.

Finally, I'm not especially happy exposing such event publicly but it seems like it is sadly necessary.

Peace, Love and Referential Transparency

Alois

Nick Partridge

unread,
Nov 6, 2014, 5:46:10 PM11/6/14
to sca...@googlegroups.com
I don't really have the time to spend on this discussion, but there are some conclusions being drawn from this thread because of lack of responses/opinions (silence does not imply consent!). So I want to quickly note a couple of things:

<larsrh> and fwiw, the consensus in the current mailing list thread is that swearing is discouraged

Strongly -1 on banning swearing in the CoC.

<larsrh> But it's likely to be in the next version of it. Hence my statement.

I don't think there's been enough discussion here to warrant that statement. Are we not looking for more input before deciding on the content of the CoC? This should not be a process where we rubberstamp someone's ideas without critique.

And further, the rules of #scalaz have now been changed from being moderated according to the CoC, to being moderated according to the CoC plus other rules that will be in the CoC one day.

We can do better than that!

Chris Lewis

unread,
Nov 6, 2014, 5:51:40 PM11/6/14
to sca...@googlegroups.com
Exactly what Nick said.
-chris

David Barri

unread,
Nov 6, 2014, 5:52:29 PM11/6/14
to sca...@googlegroups.com
Wow, this is exactly what I feared. That "no racism/sexism/bullying" would become "no swearing" regardless of context.

I strongly oppose any stance against swearing or satire or sarcasm or exaggeration. Making the community sterile will surely deter involvement just as bigotry would.

Matthew Pocock

unread,
Nov 6, 2014, 6:03:59 PM11/6/14
to sca...@googlegroups.com
I'm not anti-swearing. I, like most people who fight code all day, swear profusely, and like most brits, fluently. I tend not to walk down the street swearing though. That would be somewhere between a mental condition and a breach of the peace.

Swearing about things is different from swearing at people. I'd hope that everyone can agree that swearing at people isn't on, and should be explicitly or implicitly banned by the CoC.

So then for swearing about things. Basically it boils down to balancing the legitimate needs of people to express their emotions, and the effect that swearing has on making the channel not seem like a 'safe space' for other people. Personally I've no issue with mild swearing - the occasional f$^k or bo*&ox doesn't seem out of place. Persistent swearing, on the other hand, would make me think twice about publicising the channel as a 'safe place' to talk with the scalaz people.

Matthew

On 6 November 2014 22:52, David Barri <japg...@gmail.com> wrote:
Wow, this is exactly what I feared. That "no racism/sexism/bullying" would become "no swearing" regardless of context.

I strongly oppose any stance against swearing or satire or sarcasm or exaggeration. Making the community sterile will surely deter involvement just as bigotry would.

--
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.



--

Ricky Elrod

unread,
Nov 6, 2014, 6:09:54 PM11/6/14
to sca...@googlegroups.com
Strong -1 on banning swearing in the Scalaz CoC.
Strong -1 on moderating #scalaz by arbitrary rules that someone wants to have added to the Scalaz CoC.
Strong -1 on inferring from silence that the Scalaz community agrees to have something added to the Scalaz CoC.

-Ricky

James Livingston

unread,
Nov 6, 2014, 6:12:35 PM11/6/14
to sca...@googlegroups.com
On Monday, November 3, 2014 10:54:53 PM UTC+10, Matthew Pocock wrote:
1. respect: Always respect the person, even if you don't respect their beliefs or opinions, and even when they are self-evidently wrong. The person deserves to be treated with respect. If you think their ideas don't, then address that to their ideas, not to them as people.

2. inclusion: Everybody can be involved in some role with coding. There are a multitude of roles. None of these are related to that person's age, gender, sexuality, religion, politics, hair color, education or any other personal attribute. This cuts both ways. Don't make your code opinions about these other things, and don't argue other people's code on the basis of these things.

3. safety: All people within the community, from the first day they hit a q&a or bug report via google, should feel that this community is a safe space. This sometimes means being careful with language so as not to appear to attack people, particularly people that you think know less than you. The health of a coding community is measured by the volume of noobs you attract and keep, not the number of code wizards that were there from the start.

Lastly, most of the time there should be no need to even make an issue of this stuff. Nothing puts me off a community more than having to read and sign some equalities statement before I even set foot on the forum. If you push these things in people's faces, you're making an issue of something that in the normal course of things shouldn't be an issue.

That's all really. Be excellent to one-another. 

+1 to those comments and most of what's been posted so far.


I believe that there is a distinction between personal attacks on a person or group, indirect attacks via (well-known) derogatory slurs and similar things, and general behaviour that some may find offensive (e.g. swearing not directed at someone). I think that the CoC should concentrate on the first two, and that they shouldn't have a place in our community. Attacking people's ideas is fine, but don't attack them.



Behaviour that some may find offensive is something which I think would be much more problematic in a CoC. Aside from a general dislike of rules around that, there are major practical problems - who gets to decide what is offensive? We are a global group, and what is considered majorly offensive, mildly offensive, or non-offensive will vary a lot between cultures and people.

Any time I've seen rules that "ban swearing" they don't do actually that, it's "ban an unwritten list of swear words that the particular moderator thinks may be offensive, or may think someone else may be seriously offended by". There are lots of mild cuss words which in large parts of the world may be offensive, I'm sure many of us don't give a second thought to using "crap" or "hell", and I and many others don't to "fuck" or "shit". I know there are words which are offensive in both Australia and the US, but their level of offensiveness differs greatly, one for example is a offensive word in Australia but no worse than many others, but is close to the top of the list of offensiveness in the US. I believe "Paki" as a shortening of "Pakistani" is used as a derogatory slur in the UK, but in my experience is just a non-offensive word shortening here in Australia.


Who gets to decide the offensiveness? If it's the speaker, then there are effectively no rules so why have it? If it's the listener, then due to the one-to-many global nature of our communication it means you can't safely use anything regardless of how mild it is, which would be a problem since many won't even think that using some words could be at all offensive. If it's "the community", then you have the problem that no-one is sure what is okay and what isn't and, as this exercise shows, there is no agreement on it.


I'm fine with having a CoC, but I don't think that very vague things like "no swearing" is a good idea since many times you want to enforce the rule it will just spark another debate about what is and isn't offensive. You'll get people saying whatever was said isn't offensive enough to be banned, and other pointing out other words used by people asking why they shouldn't be banned too.

--
James "Doc" Livingston

Sukant Hajra

unread,
Nov 6, 2014, 6:23:40 PM11/6/14
to sca...@googlegroups.com
On Monday, October 27, 2014 9:47:15 AM UTC-5, Paul Chiusano wrote:

For the CoC, there are questions about scope (where should it apply), content (what should be in it), and process / enforcement (what is process for dealing with violations, and who is in charge or enforcement). Below, I'll try to list some questions and thoughts about each of these to help spur the discussion.

A lot of responses thus far have have presumed that a "Code of Conduct" is really what we've needed all along.  Do we really need a punitive structure?  Or is the purpose really to explicitly define the kind of culture and community we'd like to promote?  Personally, I'd prefer not specifying anything punitive, but rather only to emphasize positively which behaviors we'd like to encourage.  If anyone does anything at odds with this goal, just point out the goal, and suggest a better way -- not demand it, or make threats.

I wanted to explain this preference a bit.  For me, there's a difference between a private space and a public space.  Both have strengths and weaknesses, but I need both to exist healthfully because they balance one another.  I prefer public spaces to be open and permissive -- up to the point of human rights violations.  In private spaces, I'm open to a lot more restriction.  I don't try to invert this largely because it's impractical.  The number of people in a public space can never agree on the set of restrictions.

This might all seem obvious, but it leads to an interesting question of whether the Scalaz Github pull requests and comments are more public or private.  Furthermore, is #scala public or private?  For me, IRC is about as public as it gets, so it's somewhat jarring when people try to convert it to a private forum.

Alois's experience frames why I feel my position is justified.  I want more disenfranchised minorities to participate not only in technology, but in FP.  But I can't see how disputes about profanity helps this cause.  If any thing, it's wash with respect to the stated goal, and ultimately just motivates Alois's detachment from active participation.

That said, if non-scalaz folks are lurking and want to pipe in with their thoughts, that is fine with me.

Thanks.  There's been some discussion about how "community" can be more exclusionary of a term than the inclusive one people presume it is on face value.  I have no idea whether I'm a "scalaz" folk or not.  I've been using Scalaz for a few years now, and it's the only thing that makes the JVM bearable, so it means a lot to me.

Holy crap.  The web interface is saying that 6 new messages are available.  I'm going to post this message, because I think it answers the original post, but I hope it doesn't confuse issues more.

Best to all,
Sukant Hajra

etorreborre

unread,
Nov 6, 2014, 9:45:32 PM11/6/14
to sca...@googlegroups.com
If the side-effect of the code of conduct is that Alois is out of #scalaz, that means we're doing it wrong. There's a big difference between "I don't f****** get it" and "you don't f****** get it". 

I hope we won't have to police everything word by word to have a friendly and welcoming community. Isn't swearing the thing you've been doing with your friends since you were a kid? If it's not against anyone, what's the harm? (Persistent swearing would be tiring though as Matthew Pocock wrote, I would not enjoy to have conversations with 8 year olds all the time :-)).

Thanks for Alois for posting this real "use-case" that should help us agreeing on what's in, what's out of the CoC.

Eric.

Raoul Duke

unread,
Nov 6, 2014, 9:47:24 PM11/6/14
to sca...@googlegroups.com
well, shit.

Jed Wesley-Smith

unread,
Nov 6, 2014, 10:17:06 PM11/6/14
to scalaz
I would like to preface this with the statement that while I may not agree with everybody on this, I have the highest regard for all of you. This community is one of the most helpful, welcoming and useful I have been privileged to be a part of.

However, somewhat ironically, Tony's objections* to a CoC have essentially come true.

I was an enthusiastic supporter of the original CoC with its focus on removing harassment from the community, and I completely agree with that aim. I did not initially agree with Tony's assessment that it could _or would_ be used to police arbitrary behaviour that any particular individual deemed distasteful. Yet, that is exactly what has happened, and the damage to the community is material.

Any enforcement of a CoC that tries to mandate things like "civility" is bound to be arbitrary and subject to interpretation. Was Lars being civil in responding to Alois? He shut down conversation without explanation. A case could be well made that this was neither civil nor excellent, and didn't welcome or provide real feedback. Did Lars violate the CoC? Should Lars be banned then? I think the answer is pretty obvious…

So, the question is, what sort of behaviour do we want to ban, what sort do we want to deprecate, and who and how do we go about policing it. I'd hope that the situation we find ourselves in should show that trying to do much about anything short of actual harassment is both difficult to the point of impossibility and potentially as damaging as that we are trying to stop.

Personally I vote for retaining the current CoC. We should not accept harassment at all under any circumstances. We should also not mistake something someone said that we didn't like for harassment.

cheers,
jed.

* his full rant starts here http://ircbrowse.net/browse/scalaz?events_page=576 9 hours later he was summarily banned.

Paul Chiusano

unread,
Nov 6, 2014, 11:24:58 PM11/6/14
to sca...@googlegroups.com
I too see a big difference between swearing *at* someone ("fuck you") vs swearing about *something* ("shit, why doesn't that work??"). And I'm hearing lots of agreement that we shouldn't try to *police* the latter with threats of banning, etc. Of course, if someone is cussing enough that you personally find it bothersome, I see nothing wrong with politely asking them if they can tone it down. But at this point it's a request made from one adult to another, not a demand. Along these lines, I really like this comment.

I do also like Mathew's observation:

Basically it boils down to balancing the legitimate needs of people to express their emotions, and the effect that swearing has on making the channel not seem like a 'safe space' for other people. Personally I've no issue with mild swearing - the occasional f$^k or bo*&ox doesn't seem out of place. Persistent swearing, on the other hand, would make me think twice about publicising the channel as a 'safe place' to talk with the scalaz people.

I'd probably be okay if the channel had a policy against "excessive swearing", where that is left up to the judgement of moderators for the channel to interpret and decide how to handle on a case by case basis. Though I also kind of think normal social conventions will take care of things and this isn't something that necessarily needs spelling out. I don't think this has been a problem in the past, though I don't hang out on IRC very much.

Lars, I think that while things are limbo it would be better if you keep your moderation in the channel to the obvious stuff, until we have a CoC that people are bought into and we know what policies we want to enforce.

I think this particular issue is sort of indicative of a larger question, which is whether we want a CoC and associated moderation policies to be just about preventing the "obvious" stuff like harassment, abuse, personal attacks, and so on, or if people want it to go further than that.

Paul :)

Lars Hupel

unread,
Nov 7, 2014, 2:44:42 AM11/7/14
to sca...@googlegroups.com
> Lars, I think that while things are limbo it would be better if you keep
> your moderation in the channel to the obvious stuff, until we have a CoC
> that people are bought into and we know what policies we want to enforce.

Just a quick remark to that: At no point I said "no swearing ... or else".

From what I've gathered from the previous discussions in this thread, a
clause "be civil" seems to be generally agreed upon in a CoC. And in my
cultural context (since we were speaking about that), swearing in a
public (and publicly logged) channel is definitely not civil. It's not
necessarily unprofessional, but it indicates that the speaker might not
have the best judgment.

In fact, Paul, I've taken your recent posts as occasion to think about
the (my) general style of technical debates, and it has convinced me
more that swearing adds nothing and is likely to solicit emotional
responses. Interestingly enough, swearing happens more often in IRC
channels than on, say, GitHub or mailing lists. There seems to be some
crucial difference (I don't know). But keep in mind that swearing is not
the only kind of speech we all are probably comfortable in using private
conversations (I am), but refrain from in public/professional contexts.

If we want to have productive conversations, we need to distinguish
ourselves from the HN crowd which upon learning a bug/feature/whatever
of Scala or scalaz immediately jump to saying "fuck this
language/library/whatever".

Apart from that, +1 to what Matthew said.

Cheers
Lars

David Laing

unread,
Nov 7, 2014, 3:43:50 AM11/7/14
to sca...@googlegroups.com

Doesn't that suggest that the current feeling, at least amongst some people, is that "or else" is implied by recent events and discussions?

I know a handful of people who have strong views on these recent events who are basically afraid to enter the discussion.

I've been off to the side for most of this, so there could be some severe sampling biases in play, but in the aftermath of Tony being banned, I saw people asking the following questions:
- where did the mandate for a code of conduct come from?
- who are the enforcers?
- are there warnings?
- does it apply retroactively?
- is questioning the code of conduct a violation of the code of conduct?

In the majority of instances, I didn't see answers to these questions.  I saw a few of the people who were strongly in the "pro-ban" camp harassing the folks asking the questions, and then they mostly stopped asking questions and most of them have chosen not to participate in the discussion since then.

My theory is that there's an implied "or else" that has been in the background this whole time.

It's possible that is an overly sensitive interpretation of the events that occurred.  I'd just like to see some of those folks involved in the discussion, since they're folks whose opinions I value and some of their questions still haven't been answered.
 
I hope all of this drama leads to a good place, and I usually try to bring something constructive to threads like this, so here it goes.

If the code of conduct does have a punitive component, my view is that
- we need to know that the community is broadly behind it
- we need to know who is making the decisions
- we need to know the progression of measures (ie private warning, public warning banning)
- there should be some kind of record of the decisions, especially if some of the discussion around a decision happens in private
- there should be consequences if the enforcers threaten people with bans or ban them for unrelated matters

That might not be the right list.  It might not even be helpful to emphasize those particular points or to constrain the people doing the work to keep a Code of Conduct begin effective.  But something like that might help to build some trust in the process and help people view it less like a loaded gun.

I'm not actually trying to ruffle feathers, I'm just in a hurry and think the above represents some points that haven't really entered the discussion yet.

Cheers,

Dave

Pascal Voitot Dev

unread,
Nov 7, 2014, 5:11:19 AM11/7/14
to scalaz
Hi,

Nobody is against swearing on tech things even using the most outrageous & ugly expressions. Those things are worth it sometimes and I spend a long time everyday swearing against things in Scala and even Scalaz sometimes!!!

But, nobody should ever swear against people behind those things, no matter how much they disagree with what they did & even with the person itself.

Swear on things never on people (or keep it for you)...

And go on validating this putain de CoC de chiotte (swearing in french is always better) & swear against it as much as we want after that. This will just be a way to establish publicly a state of fact and it won't restrict any freedom to anybody, even to those who love swearing loudly...


Pascal

--

Tom Switzer

unread,
Nov 7, 2014, 9:43:18 AM11/7/14
to sca...@googlegroups.com
On Fri, Nov 7, 2014 at 2:44 AM, Lars Hupel <hu...@in.tum.de> wrote:
> Lars, I think that while things are limbo it would be better if you keep
> your moderation in the channel to the obvious stuff, until we have a CoC
> that people are bought into and we know what policies we want to enforce.

Just a quick remark to that: At no point I said "no swearing ... or else".

I don't think this is fair. You may not have said it, but if I was in Alois's shoes I would certainly have assumed it. I think most would, given your position. If a police officer tells me "do not cross this line!", while he may not have said "or else", it is only safe to work under the assumption that I may be penalized should I cross the line.

In fact, Paul, I've taken your recent posts as occasion to think about
the (my) general style of technical debates, and it has convinced me
more that swearing adds nothing and is likely to solicit emotional
responses. Interestingly enough, swearing happens more often in IRC
channels than on, say, GitHub or mailing lists. There seems to be some
crucial difference (I don't know).

There is a very crucial difference: IRC is a realtime conversation between people while mailing lists and issue trackers are not. In an e-mail I take time to ensure that the tone and presentation of my e-mail is professional. In a real time chat, like on IRC, I'm encouraged to type what comes to mind and hit enter. Sure there is some self-censure, but certainly not to the degree of a 3 paragraph long e-mail that I've reviewed and revised 2-3 times! Because of this you get much more of a person's personality coming through in IRC (or any chat system), since it's closer to how that person would come across in a conversation. Some of us swear - I do. It's a habit I'm trying hard to curb, but I do occasionally let slip an expletive.
 
But keep in mind that swearing is not
the only kind of speech we all are probably comfortable in using private
conversations (I am), but refrain from in public/professional contexts.

Again - the difference is that as the medium of communication becomes more realtime, we have less time to censor ourselves. We should account for this in the CoC. A swear word in a ML or practiced presentation? Can easily be avoided and likely should. A swear word in IRC or a real life conversation, perhaps give the person a bit of slack.
 

If we want to have productive conversations, we need to distinguish
ourselves from the HN crowd which upon learning a bug/feature/whatever
of Scala or scalaz immediately jump to saying "fuck this
language/library/whatever".

Defintiely agreed. But, while a blanket ban on swear words would achieve this goal, it is not necessary to curb this kind of talk. I'd hope we can find some middle ground.

Stephen Compall

unread,
Nov 10, 2014, 9:50:04 AM11/10/14
to sca...@googlegroups.com
On November 7, 2014 2:44:37 AM EST, Lars Hupel <hu...@in.tum.de> wrote:
In fact, Paul, I've taken your recent posts as occasion to think about
the (my) general style of technical debates, and it has convinced me
more that swearing adds nothing and is likely to solicit emotional
responses.

I've seen the response to this strategy Paul [Chiusano] has gotten in other fora, and it's impressive.¹ However, I don't think we should go straight from "this strategy of technical discussion seems to work well" to "this is the way we have technical discussions in Scalaz". Paul's results have been impressive, but I doubt his approach is right for everybody, and I strongly doubt it's a prerequisite for valuable, socially inclusive technical discussions.


If we want to have productive conversations, we need to distinguish
ourselves from the HN crowd which upon learning a bug/feature/whatever
of Scala or scalaz immediately jump to saying "fuck this
language/library/whatever".

I strongly disagree with this characterization of the "x sucks" approach to criticism traditionally taken by the Scalaz community. After all, Scalaz itself is the outcome of "these things in scalax/scala-library suck, we can do better". Many individual features of Scalaz fit the same template, too:

  1. covariance sucks, let's make IList;
  2. right-projection sucks, let's make \/;
  3. BroYoneda sucks, let's make a Functor stack;
  4. equals/hashCode suck, let's make ISet;
  5. pattern matching on Option sucks, let's make cata;
  6. case class copy sucks, let's offer a lens algebra;
  7. <:< and =:= suck, let's provide Liskov and Leibniz (and maybe make the former better);
  8. hk-inference sucks, let's build Unapply;
  9. I'd rather not enumerate every example I can think of.

The difference between the aforementioned "HN crowd" and us is that for them, "fuck this whatever" is the last step. The spirit of Scalaz is in the second step, "we can do better, let's go!" The will to the second is derived from the first remark, though: "I've had it up to here with Object#equals and I'm not going to take it anymore!"

That's a positive emotional response to a negative feeling. I've been kind about some of the things above, for the sake of this particular discussion. But I have no doubt people feel more strongly about some of the examples above. If someone says "fuck feature x", we should take that as a greater opportunity for action. A stronger emotion is a stronger imperative to do better.

We, too, are capable of producing things that suck; I'd rather this be a project where we're comfortable pointing that out when it happens, holding ourselves to the same, even higher, quality standards we [apparently] hold scalac and scala-library to.

I, too, want Scalaz to support a diverse community, and supported the initial release of a CoC on that basis. I don't think that goal requires the radical shift in discourse that Lars and Paul have undertaken as a broader mandate for the discourse of Scalaz, though I welcome the data on any positive results this approach brings to them, personally.

¹ I won't point to a particular instance, but I've seen Paul put forth great effort to apply this approach and fight derailment. The results are exceptional in the case I'm referring to, but seemed to require a great deal of care and steering to prevent the conversation from being derailed and reaching his goals in the conversation.

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

Paul Chiusano

unread,
Nov 10, 2014, 11:12:10 PM11/10/14
to sca...@googlegroups.com
Hi everyone, 

Thanks to all who responded. I've heard from Tony off-list (he is still recovering in the hospital), and he's said he'd rather hold off on giving input at this stage and that it's ok to proceed without him. I'll let Tony pipe in if he wants to clarify.

So at this point, I'd like to wrap up this first phase and produce a draft CoC based on this discussion. I'll give folks until Thursday if they have anything they'd like to add to the discussion before I start on that. I'm going to try to think seriously about everyone's feedback and put together a draft that I think is reasonable. It probably won't fully satisfy everyone, but I think that is okay. No one should feel like the best/only way of influencing things is via this code of conduct. In fact, I still think the best way of changing things is by setting an example yourself, and by giving constructive feedback to others.

Hopefully by the end of this weekend I'll have a draft and we can discuss it and/or make edits next week.

Cheers,
Paul
Reply all
Reply to author
Forward
0 new messages