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.
--
--
--
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.
I cannot respond before Wednesday.
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 :)
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!
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.
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.
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.
That said, if non-scalaz folks are lurking and want to pipe in with their thoughts, that is fine with me.
--
> 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".
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".
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.
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".
-- Stephen Compall "^aCollection allSatisfy: [:each|aCondition]": less is better |