Initial draft of communication guide #3
Conversation
snoyberg
force-pushed
the
communications-guide
branch
from
69b4696 to
394df4a
Compare
|
@vedksah I appreciate the suggestions here, they're helpful. However, I'd like to request that you avoid implications against other projects. This repo is about improving the Stack community, there's no need to reference other projects, even via implication. |
|
Ok, got it! I already inadvertently failed to honour the code of conduct 😆 |
|
No problem, we're all learning. The most important thing is doing better next time. |
|
I suggest moving 'Don't take it personally' down the list. While it is a very important piece of advice — that we have to try to approach our work objectively — it may be better to begin with advice on giving, rather than receiving feedback. As it is, it read to me like 'the most important thing is to receive the message well'. Whoever sends a message has the first responsibility to ensure it follows the guidelines; whoever receives that message only then takes the responsibility to listen to the content. Changing the order matches the responsibilities. |
|
One thing currently missing (though I may have missed it) is how to deal with, and possibly resolve, conflict. The proposed code of conduct defers to the project leads. The communication guide might set expectations of how this would work. |
|
I'm fine with moving the paragraph lower. I'll be honest: I wrote down a bunch of headings as they came to me, and didn't think about their relative position. There may be even more reorderings that are worth having. See issue #1 for a discussion of enforcement. |
|
What is the purpose of a separate communications guide? The contributor covenant (which is very widely used, including by linux, and is suggested in the other PR) seems like it suffices to cover communications, as it lists the following:
I don't see what purpose a separate communications guide holds, especially since the current draft, if anything, seems to cut against the spirit of the above, and be weaker. In particular, the draft communications guide says "These guidelines are non-binding." But the CoCov has a section on "Enforcement." Further, the draft communications guide says "don't take it personal" -- but this is advice to someone that feels that they are on the receiving end of a personal attack. Since personal attacks are actually ruled out by the CoCov to begin with, which has an "Enforcement" clause, why is this guide telling people to ignore them? If anything, wouldn't "don't make it personal" suffice? Anyway, the more full take I have is that the CoCov is widely adopted and essentially self-sufficient. Nearly all projects that have adopted it have not felt the need to augment it with things, especially not things that may run against it in some ways. To me, adopting it, and then adopting a whole other thing as well, feels like adopting a standard open source license and then tossing in a whole bunch of other custom clauses, and I'd suggest not doing so. The one thing I can see that is particular here is the section on "avoid partisanship" but I don't think this belongs in a CoC at all -- rather, it is a general statement about the purpose of stack, and could well live in stack-specific documentation, because it pertains to the goals of stack, not to how to conduct discussions relevant to these goals. Finally, I also question the "respect privacy" section since it seems to again introduce the principle only to immediately introduce language that undermines it: "As such, communications can only reasonably |
|
You're free to disagree with me and my motivations. However, I have given my full explanation for why I want this separate document in my blog post, so I have nothing to add here. |
|
Well there are both general and specific concerns that I don't think the blog post addresses. I'm not imputing any motivations nor disagreeing with them. I'm suggesting a technical problem -- two documents, which potentially conflict, don't make for a good joint CoC. Similarly two licenses which both have different clauses covering the same things, don't make for a clear single license. What I am suggesting is that whatever CoC is adopted be authoritative, and any further guide have its status clarified as a set of personal notes as to the interpretation and spirit of things. I'm also proposing that the "avoid partisanship" section be moved just to an entirely distinct thing that's part of the mission statement of stack. And finally, I'm suggesting that the "respect privacy" section does not make sense, and similarly the "don't take it personal" section. In the latter, the point that one should distinguish personal criticism from technical discussion can fit perfectly well under the subhead "don't make it personal" much more clearly. |
For me, the value is that communications and conduct are not quite the same thing. The covenant does not have anything to say about the project, and there is likely to be best practice in communicating that doesn't relate to the pleasantness of the community. The covenant is also quite abstract; there may be value in a more detailed document — as long as that document complements it.
That's a good point. I agree with the sentiment (a mix of 'gracefully accept constructive criticism' and an attempt to avoid escalation) but it ought to say that explicitly. Edit: Should have hit refresh before submitting the comment! |
|
The distinction between the two documents could be that the CoC is enforced, while the communication guide is merely suggested. That way, if any contradictions are detected, the CoC generally trumps the communication guide. (However, the two documents are, afaict, reasonably harmonious). |
|
@dbaynard You've captured my thoughts on the different documents perfectly, and expressed them better than I could. Thank you. With the "don't take it personally," I'm actually getting at something very specific, and perhaps I need to be more explicit about it. I want to encourage people (and, more honestly, myself!) to try and decouple "criticism of my code" and "criticism of me as a person." There's certainly value in differentiating between criticism and attack. If I'm told that I'm not an organized person, that's criticism, but not necessarily an attack. But I'm not even getting to that level. I'd like to encourage the thought that it's healthy to separate the code we write from our own personal identities. Maybe this is a problem I've had, and others don't have as much. But remember, these are my personal guidelines, and I'm trying to capture things that have affected me. |
|
I'm not sure I see the purpose of the communications guide, specifically, why it is paired in the same repo as a code of conduct. This relates to my uncertainty over why these documents are deemed "unofficial." I would suggest moving in one of two directions:
By "make official", I would actually recommend this be reparented under |
|
Again, I have no objection to adding a CoC to Stack, or commercialhaskell generally. I feel less good about the communication guide going there. This is very much guidelines, and I don't feel like giving them any air of authority, because they have none. |
|
@simonmichael made a very constructive comment on reddit, pointing out the GNU Kind Communications Guidelines. See email introduction and Hacker News discussion. It is well worth reading. The needs are slightly different to stack, but the broad pattern holds. One interesting aspect is the choice of language — the anaphora of beginning each line with 'Please' stands out, and really sells the idea that you as a reader are following the policy because you are a Good Person. |
|
@dbaynard Thanks for the link. I've looked through the guidelines, and I like what I see there. Providing a link to those guidelines from the COMMUNICATIONS.md document seems fine, after I review it a bit more thoroughly. But to be clear: this looks to be as opposed to a CoC, not a different choice of CoC. I understand (at least some of) the arguments in that direction, and think the Reddit thread had a really healthy discussion around it. But I wanted to confirm if that's your reading as well. |
|
I thought the GNU document was in line with these communications guidelines, and somewhat orthogonal to the CoC (which is why I put it here and not on #1). Do note: orthogonal, not opposed. To me, it says much of what you say in the communications guide: in less detail but with a style that addresses some of the issues raised in this discussion. |
Personally, I think an explicit "don't take it personal" guideline is a great idea. Let me try to explain why. Regarding "Since personal attacks are actually ruled out by the CoCov to begin with, which has an 'Enforcement' clause, why is this guide telling people to ignore them?", my position is that something being a "personal attack" is not easily determined or well defined in general. The receiver might feel like something is a personal attack, while the giver might not intend it that way. You don't know someones intent, you only know their impact on you. And you have some control over that impact. Communication is often ambiguous, especially online in text where we don't have voice and body language cues. So, related to "don't take it personal" could be "assume goodwill" or "assume you're dealing with a reasonable person". I.e., given several possible interpretations of a person's intent, that are consistent with their actions, assume the most charitable. Another way to say this is that emotional reasoning is not logically sound: just because you feel bad doesn't mean someone has done something bad to you; you might just feel bad. And, you might be able to think about the situation a different way and not feel bad. And you're in control of that, and you don't need other people to change to achieve that. The "don't take it personal" is a reminder to consider these possibilities, and make yourself more robust communicating in an environment you don't control. |
|
I like that — changing from a negative 'don't take it personally' to a positive 'assume goodwill'. The GNU guidelines begin with 'Please assume other participants are posting in good faith.' |
The way I understood it, the GNU document is instead of a CoC for GNU. I agree with @dbaynard that it's (at least fairly and in practical terms) orthogonal to a CoC and can serve as a nice example and inspiration for the Recommended Communications Guide. |
|
While technically orthogonal, I noticed the following in the email from RMS:
So I believe we have two different issues at play here:
It may have only been me who was confused about potentially discussing the second point here, so I'll leave it be. Coming back to (1): I will review a bit more thoroughly right now and, unless I see a problem, I'll add a commit linking to the GNU guidelines in this PR. |
|
Thanks for the feedback all. I'm going to merge this PR. Further discussions can happen with additional issues and PRs. |
No description provided.