On Sat, Sep 15, 2018 at 8:11 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > Martin Mueller <martinmuel...@northwestern.edu> writes: > > Which makes me say again "Where is the problem that needs solving?" > > We've re-litigated that point in each burst of CoC discussion for the > last two-plus years, I think. But, one more time: > > * So far as the mailing lists alone are concerned, we likely don't really > need a CoC; on-list incidents have been pretty few and far between. > However, there *have* been unfortunate incidents at conferences and in > other real-life contexts. Core has been encouraging conference organizers > to create their own CoCs, but (a) they might want a model to follow; > (b) there needs to be a community-level backstop in case of failure of > a conference to have or enforce a CoC; and (c) conferences aren't the > only point of contact between community members. >
As a note, the current CoC wording appears to explicitly exempt enforcement from conferences as long as they have their own CoC (whatever either the terms or the implementation). So point b is not resolved at all and under this there is no community backstop if we take the text at face value. "This Code is meant to cover all interaction between community members, whether or not it takes place within postgresql.org infrastructure, **so long as there is not another Code of Conduct that takes precedence (such as a conference's Code of Conduct).**" [emphasis mine] Hence I think it would be better to suggest a more nuanced line, one where acting on things off list etc is subject to the overall balance of community interest and an inability of other parties to act. If the goal is to give conferences an ability to enforce their own rules, with a community backstop, then one needs a functional, not merely formal line. If the goal is a sort of subsidiarity, then such a functional line is better too. So I would recommend changing that to "This code of conduct may be applied to conduct on or off community resources so long as the conduct is related to the community, other parties are unable to act, and it is in the community's interest to apply the this code of conduct." That more or less explicitly puts the decisions on where and when to apply it in the hands of the committee, which is probably better than promising a large scope and then telling new folks "sorry, that isn't covered" after setting expectations to the contrary. > > * This isn't really directed at people who already participate in our > mailing lists. The reason for setting up a formal CoC is to reassure > potential new contributors that the Postgres project offers a safe > environment for them. As has been pointed out before, a lot of people > now feel that some sort of CoC is a minimum requirement for them to > want to deal with a community. Whether you and I find that a bit too > shrinking-violety isn't relevant; if we want to keep attracting new > participants, we have to get with the program. > > Now, the hazard in that of course is that someone will come in and > try to use the CoC mechanism to force the PG community to adopt that > person's standards of conduct. It'll be up to the CoC committee > (and core, in the case of appeals) to say no, what you're complaining > about is well within this community's normal standards. That's a > reason why a two-line CoC isn't a good idea; it leaves too much to > be read into it. > It's worth noting that in the cases I am concerned about, the CoC committee would have to decline the complaint. I am not worried about them acting badly. What I am worried about are people getting worked up about something outside the community when someone who complains gets told no. > > Anyway, the short answer here is that we've been debating CoC wording > for more than two years already, and it's time to stop debating and > just get it done. We're really not going to entertain "let's rewrite > this completely" suggestions at this point. > Agreed on not rewriting completely. However the particular recent addition I am objecting to is relatively troubling for a reason. Personally, I felt like we were assured when this process started that a code of conduct would regulate on-infrastructure behavior only. Now, for reasons you have said, that scope is too narrow and I understand that. Those reasons and the issues behind them have been discussed from the beginning, and so I don't really object to broadening the scope to things like campaigns of personal harassment including in real life, etc. I recognize that to be totally necessary. However, the addition goes way beyond that and it feels like a full reversal of a promise that was made to the community much earlier to try to keep the code of conduct from something that could be used to apply pressure from outside to get rid of community members for activity that is not related to PostgreSQL (in particular, unrelated political involvement, opinions, and participation). If you aren't open to rewriting even that one sentence, I hope maybe you can leave that sentence off and assert that it is up to the Code of Conduct community to develop the scope of application based on actual complaints and circumstances. Again for reference the only change I am objecting to is the addition of "This Code is meant to cover all interaction between community members, whether or not it takes place within postgresql.org infrastructure, so long as there is not another Code of Conduct that takes precedence (such as a conference's Code of Conduct)." I don't think that sentence solves the problems you are trying to solve, and I think it creates new ones. However I have said my piece. Unless there are replies that provide something new for me to add, I won't continue arguing over that from here. -- Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more
