Closed larsrh closed 7 years ago
Agreed. I also like the fact that it includes encouraged behaviour.
Should the Typelevel rules be amended to say that for member projects, either the Typelevel CoC or the Scala CoC is acceptable to be eligible for Typelevel membership?
I don't understand why a change in the Scala CoC requires attention from Typelevel.
once the new Scala CoC is fully finalized & publicized (afaik, it's aaaaalmost there) projects may start adopting it, and it would be nice if joining Typelevel later didn't require achieving consensus on switching to Typelevel CoC instead
just as Typelevel has a CoC requirement, so does the Scala Platform. I don't know what the chances are of a project wanting to be in both Typelevel and the Scala Platform, but it would be nice if the CoC requirements were compatible.
I don't know, "let's cross that bridge when we come to it" would be a sensible response to this, I guess? but still, "I don't understand why a change in the Scala CoC requires attention from Typelevel" seems to have an air of "we're here and you're over there and we have nothing to do with each other". I don't see why it has to be like that unless there some real point of contention exists. I think this is an issue we could actively be cooperating on.
(EDIT: and are cooperating on, given @non's participation in the Scala CoC drafting)
one more note: since Typelevel Scala has a policy of requiring PRs go to scala/scala first before they go to typelevel/scala, in practice the requirements for contributors are already intertwined.
cc @heathermiller @adriaanm
We already say "the Typelevel code of conduct or something equivalent".
great! if the Scala CoC is considered equivalent, I think it would be nice if you said so.
This does not mean that we will adopt this CoC – that is a different discussion. (NB: I think that different discussion should happen soon-ish.)
I'd rather avoid an Apache2/MIT situation where two mostly similar things cause confusion and debate for years. If Typelevel considers this equivalent, I'd rather just adopt it. If Typelevel does not consider it equivalent, I'd rather see if we can work out those differences. If we endorse without adopting, we have two CoC's when I'd much rather have one.
We do view the Scala code of conduct as equivalent.
I don't see that there's any particular urgency about this. We don't need to couple our endorsement of the Scala code of conduct with our switching over to it. We can do the first pretty much instantly (and we should IMO) and switch over gradually ... I say gradually, because there are a lot of projects which will need to switch over independently.
Concretely I think we should proceed as @larsrh is suggesting ... put together a blog post endorsing the Scala code of conduct and saying explicitly that we consider it as equivalent to the existing Typelevel one. Then projects can switch over at their leisure.
I have not heard any complaints or concerns about the Typelevel code of conduct. Is the Scala one clearly better? I don't understand why we're considering making 50 projects consider a policy change when what we have now seems to be working fine.
@tpolecat My understanding is that the Typelevel CoC is primarily focused on harassment (based on a CoC from HaskellNow), whereas the Scala Center CoC has examples of positive behavior, is a bit more specific, and is based on the Rust CoC (which was written later).
I agree with @larsrh and @milessabin -- I think projects under the Scala CoC meet the requirement of Typelevel CoC or equivalent and I support the CoC the Scala Center has created. I don't think we are under any pressure to do anything else at this point.
Full disclosure: Scala Center asked for my input on the CoC, so I'm a bit biased. There were no concrete problems they identified with the Typelevel CoC, but they felt it was too narrowly based around harassment for them to adopt. I don't think there are specific things that are going on in the Typelevel community that they are trying to ban (in case anyone is worried about that).
@non thanks, that's helpful.
It's out now: https://contributors.scala-lang.org/t/please-read-scala-code-of-conduct/28. I'll draft a post for the blog. As far as I can tell, the consensus seems to be to state that we consider the new Scala CoC to be "acceptable" or "equivalent" to ours and that we encourage project maintainers to switch over at their discretion.
encourage project maintainers to switch over at their discretion
Do we actually want to "encourage" people to switch? Is it not enough to note that they're free to switch if they want to?
Actually nevermind.
That's what I meant with "at their discretion", but that might have been bad English from my side. I do think that it's a good idea though.
On 11 December 2016 20:35:47 CET, Rob Norris notifications@github.com wrote:
encourage project maintainers to switch over at their discretion
Do we actually want to "encourage" people to switch? Is it not enough to note that they're free to switch if they want to?
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/typelevel/general/issues/51#issuecomment-266302163
@tpolecat I seem to have replied to an old version of your comment ... Did I miss anything?
Sorry for the radio silence from me; I was tied up at work & at home. Blog post forthcoming this evening.
At the last advisory board meeting, Heather has presented the draft of the new Scala Code of Conduct. It applies to the following domains:
I suggest an official endorsement of this CoC from our side. This does not mean that we will adopt this CoC – that is a different discussion. (NB: I think that different discussion should happen soon-ish.)
I'm hoping that we can get out a message of support for official Scala channels adopting this CoC.
What I like in particular about the new draft is that it explicitly lists encouraged behaviour.