<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 13, 2015 at 3:23 PM, Bruce Yinhe <span dir="ltr"><<a href="mailto:community-manager@erlang.org" target="_blank">community-manager@erlang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>This code of conduct lays out a guideline of how to communicate within the <a href="http://erlang.org" target="_blank">erlang.org</a> community in a way we hope is easy to read, help mutual understanding and avoid flames.</div></blockquote></div><br>If I were to critique something here, it would be that the current CoC mixes text on social interaction[-1] (that is, how to behave with respect to other people) from mailing list etiquette (how to quote, how to make older mail readers happy[0]). By mixing these two, it is somewhat harder to read the CoC and I am pretty sure there are different sanctions if I decide to call someone a quebecois trying to speak proper french (in earnest), or if I write a single line at 75 characters (where the last one is ASCII decimal 32 naturally). Say we add a bug tracker to <a href="http://erlang.org">erlang.org</a> in the future. It would be logical to extend the CoC to the bug tracker as well. I've seen my share of inappropriate behaviour in bug trackers, sadly. This is why I'd like to make a point that proactively, it would be nice to think about how different sections of the documents fit into categories, so the generic parts are really generic, and the etiquette-parts specific to a communication medium have their own sections.</div><div class="gmail_extra"><br></div><div class="gmail_extra">On the question of the necessity of a CoC itself, I'll politely pass. While I don't personally see the benefit of CoCs in most projects, I do respect that this is not the view of many others. I much prefer the FreeBSD developers handbook approach than anything else. I do note that a large project, like Erlang, which isn't driven by a single monarch overseeing its construction, is better served by a well-defined code. If escalation is necessary in a certain situation, it is nice to know in advance which Tribunal you will be judged by, however. If governed by a despot, you already know who it is, but for a grouped project, the definitions are better laid down.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The CoC might get flak in the future for not being inclusive enough, too terse, or damaging to some greater cause. A great recent example was the Linux Kernel's Code of Conflict. Who handles suggestions for changes, what is the process of changes, and do we track changes somewhere, so one can see the additions and removals of wording? Like in other societies, codes are not static/immutable/constant once laid down, but dynamic/mutable/volatile and thus subject to change as we learn. I've been calling for the CoC equivalent of the software license, with versioning, so it would be easier to discriminate them from each other. But we are not far enough for this to happen yet.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Other than that, I think it looks nice. The content-guidelines on social interaction is always nice to lay down formally as they were once informal. I'm +1'ing Mr. Dahlberg here. The guidelines on etiquette reads like 1998 to me, which is not necessarily a bad thing, but it may feel unnecessary technical to some. What mail clients behave nicely out-of-the-box by default with the current etiquette guidelines?</div><div class="gmail_extra"><br></div><div class="gmail_extra">[-1] Björn-Egil calls this 'content'.</div><div class="gmail_extra">[0] If you use Pine, I'll shoot you, sorry :) Mutt is okay though.<br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">J.</div>
</div></div>