Re: Code of Conduct plan - Mailing list pgsql-general
| From | Chris Travers |
|---|---|
| Subject | Re: Code of Conduct plan |
| Date | |
| Msg-id | CAKt_ZfskKdkf6v_Xc-9tzeUv7Z9ws-LYJLT9Cx+fVxOfvRmxwA@mail.gmail.com Whole thread Raw |
| In response to | Re: Code of Conduct plan (Tom Lane <tgl@sss.pgh.pa.us>) |
| List | pgsql-general |
On Sat, Sep 15, 2018 at 8:11 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Martin Mueller <martinmueller@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.
pgsql-general by date: