Hi all,
This is my first mail to the list so please let me know if I do anything
wrong or if there's a better channel by which to have this kind of
discussion.
I'd like to propose adoption of an alternative code of conduct, the Go
Code: https://golang.org/conduct
The primary reasons for suggesting this code are:
- The Go Code focuses primarily on desired behaviours ('be patient', 'be
respectful') and only secondarily on 'avoiding destructive behaviours'. - The Go Code explicitly notes that it "is not a mechanism for people to
silence others with whom they disagree." - this was a major concern on
the ML, so codifying that this usage will not be accepted in the CoC
itself is a step in the right direction. - The Go Code encourages everybody to follow the code in all spaces, but
limits explicit enforcement to Go spaces. - The Go Code is far more clear in defining prohibited behaviours.
I've already proposed this idea over at GitHub, but it strikes me that
the correct channel for discussion is PHP internals.
- Matt
-----Original Message-----
From: Matt Prelude [mailto:me@mprelu.de]
Sent: Saturday, January 23, 2016 11:31 PM
To: internals@lists.php.net
Subject: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of ConductHi all,
This is my first mail to the list so please let me know if I do anything wrong or
if there's a better channel by which to have this kind of discussion.I'd like to propose adoption of an alternative code of conduct, the Go
Code: https://golang.org/conductThe primary reasons for suggesting this code are:
- The Go Code focuses primarily on desired behaviours ('be patient', 'be
respectful') and only secondarily on 'avoiding destructive behaviours'.
+1
I think it's sorely missing some 'Please' in there on almost every line, but it's already a whole lot better.
I would also include the Golden Rule in there. It's remarkably helpful in my experience. (en.wikipedia.org/wiki/Golden_Rule)
- The Go Code explicitly notes that it "is not a mechanism for people to
silence others with whom they disagree." - this was a major concern on the
ML, so codifying that this usage will not be accepted in the CoC itself is a step
in the right direction.
+1
- The Go Code encourages everybody to follow the code in all spaces, but
limits explicit enforcement to Go spaces.
+1
- The Go Code is far more clear in defining prohibited behaviours.
It's clearer and a lot more narrower in scope, but still leaves some ambiguity... More on that below.
I've already proposed this idea over at GitHub, but it strikes me that the
correct channel for discussion is PHP internals.
The Go CoC is the best I've laid eyes on so far, although it still has me concerned about the punitive parts in it.
Even in that context, the good news is that if I understand it correctly, it's completely limited to specific public spaces, so that there's little likelihood of disagreements about the facts - only about their interpretation.
Which still has me worried - as it seems that some people's definition of 'bullying' and 'harassment' seem to be very liberally scoped. I can imagine 'demeaning' can also be very much open to interpretation.
One thing which isn't clear to me is whether this:
"If you conduct yourself in a way that is explicitly forbidden by the CoC, you will be warned and asked to stop. If you do not stop, you will be removed from our community spaces temporarily. Repeated, wilful breaches of the CoC will result in a permanent ban."
... applies to reports, or only to proactive moderation. In other words, whether the response to a report - anonymous or otherwise - can only result in a warning the first time around? Can one only get permabanned after numerous temporary bans and repeated 'offenses'?
Last - does anybody know whether this CoC ever got 'battle tested' thus far?
Thanks for your work!
Zeev
Hi Zeev,
Zeev Suraski wrote:
One thing which isn't clear to me is whether this:
"If you conduct yourself in a way that is explicitly forbidden by the CoC, you will be warned and asked to stop. If you do not stop, you will be removed from our community spaces temporarily. Repeated, wilful breaches of the CoC will result in a permanent ban."
... applies to reports, or only to proactive moderation. In other words, whether the response to a report - anonymous or otherwise - can only result in a warning the first time around? Can one only get permabanned after numerous temporary bans and repeated 'offenses'?
I don't think it specifically applies to reports or moderation, but
rather to what it says: "repeated, wilfull breaches". If the team is
aware that you've done something multiple times, then it's going to be
more harsh on you. I don't think whether each of those times was
reported separately, if at all, would mean anything.
Anyway, as to how many warnings people would get, and how quickly they
would be banned, if at all, would surely vary from case to case with
severity. We should assume whoever enforces this is somewhat reasonable.
Last - does anybody know whether this CoC ever got 'battle tested' thus far?
This is a question I'm wondering about as well. It all seems pretty
good, but I wonder if, for example, the lists of unwelcome behaviour and
discrimination characteristics are sufficiently complete.
Thanks.
Andrea Faulds
https://ajf.me/
Hi!
This is a question I'm wondering about as well. It all seems pretty
good, but I wonder if, for example, the lists of unwelcome behaviour and
discrimination characteristics are sufficiently complete.
They are not supposed to be complete. Again, we're not writing a penal
code. If somebody does something clearly destructive but not in the
laundry list, we'd have to deal with it and we'll find the way to. The
list is just to show what kind of behavior we see as unacceptable, not
to provide complete list with a presumption if it's not on the list, it
must be OK.
For "discrimination characteristics" it's even worse, as we'd be
pretending to have a complete list of human identity and background
groups, which we can not have, and each failure mode for it is worse
than the other - either we presume anything we omitted does not exist,
or is not important enough, or it's OK to discriminate against members
of that group. Also, nobody ever reads these lists anyway - checking
everything against the exact list of a dozen or so items is not a common
behavior, considerate person would behave in a way to be polite to
everybody without the list, and inconsiderate person would ignore it
anyway.
I think simple "we respect everybody regardless of personal and group
identity" would be enough. Just as when we say we'd be polite we do not
list offensive words we don't use, when we say we'd be fair we shouldn't
list ways in which we won't be unfair. And even if we do give examples,
we should not pretend to have "complete" list.
Stas Malyshev
smalyshev@gmail.com
-----Original Message-----
From: Stanislav Malyshev [mailto:smalyshev@gmail.com]
Sent: Sunday, January 24, 2016 7:51 AM
To: Andrea Faulds ajf@ajf.me; internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of ConductHi!
This is a question I'm wondering about as well. It all seems pretty
good, but I wonder if, for example, the lists of unwelcome behaviour
and discrimination characteristics are sufficiently complete.They are not supposed to be complete.
Actually, the way I read the golang CoC this isn't just a list of examples like the Contributor Covenant - but rather, the full list of issues that are considered to be forbidden. The penalties are supposed to apply only to people who break those:
" These actions are explicitly forbidden in Go spaces:"
...
" If you conduct yourself in a way that is explicitly forbidden by the CoC, you will be warned and asked to stop. If you do not stop, you will be removed from our community spaces temporarily. Repeated, wilful breaches of the CoC will result in a permanent ban."
As personally I think even the current list is too wide unless constrained by clear (and fairly limiting) definitions for what constitutes harassment, bullying and demeaning behaviors - I think it's critical that this list won't be extensible-at-will of whomever gets to be in charge of enforcing it.
Again, we're not writing a penal
code. If somebody does something clearly destructive but not in the laundry
list, we'd have to deal with it and we'll find the way to.
That's true, but I think that somewhat goes against the point of having a 'penalizing CoC'. The list of violation is supposed to be detailed and exhaustive.
As I said numerous times, I would much rather deal with the 99% and keep the 1% (which is probably even less than that) undefined. Defining these penalties complicates things substantially:
- Instead of picking people who are good mediators, we need to pick people that also have good investigative / judgmental skills. I would say that at least in my experience, it's uncommon to have these qualities in the same person.
- Potential penalties hovering above the otherwise positive CoC introduce negative vibes, which harm the positive vibes.
IMHO, those arguing we must support the 1% are doing so at the expense of the 99%. There's no way to optimize for 100% of the cases. Given that we've had zero cases of the 1% (so far nobody presented any case that would be considered a violation of the 'Unwelcome behavior' in the golang CoC had it been in effect in PHP).
For "discrimination characteristics" it's even worse, as we'd be pretending to
have a complete list of human identity and background groups, which we can
not have, and each failure mode for it is worse than the other - either we
presume anything we omitted does not exist, or is not important enough, or
it's OK to discriminate against members of that group.
As far as I can see this is more or less based on what's in the US law:
http://www.eeoc.gov/laws/types/
Again, here too, I think it is in fact supposed to be exhaustive, with the exception of 'similar personal characteristic'.
Would someone being a very bad coder, and consequently not getting source control access be considered discrimination?
Would someone not willing to cooperate with a member or supporter of a US/EU designated terrorist group (say ISIS) be considered discrimination?
It's a brave new world, these aren't theoretical situations. They can happen in real life.
Zeev
Hi!
That's true, but I think that somewhat goes against the point of
having a 'penalizing CoC'. The list of violation is supposed to be
detailed and exhaustive.
Well, this is part of the problem with "penal code". To create and
maintain one, there are teams of very highly paid professionals working
for years. That's how they reach "detailed and exhaustive", but even
then they have to update it constantly and spend years arguing about it.
We don't have any resources to do that, so I think we should not try the
"penal code" approach. Instead, we should take "reasonable person"
approach - if it is obvious something bad is going on, then something
bad is going on. If there is a disagreement about it, moderation team
comes in.
As far as I can see this is more or less based on what's in the US
law: http://www.eeoc.gov/laws/types/
Maybe. US law, however, is very much a product of both US history and
current US political constellation, and taking this as the sacred text
looks both imprudent and somewhat narrow-minded. US law also exists in a
vast ecosystem of case law, legal practices, governmental regulations,
etc. which complement it - none of which we have or need. So we should
not borrow from it needlessly.
Again, here too, I think it is in fact supposed to be exhaustive,
with the exception of 'similar personal characteristic'. Would
That's a contradiction :) You can not be both "exhaustive" and add an
out clause of "also whatever we like to add in the future", but you have
to. And that's the fundamental problem with the laundry list approach.
That's why I do not like it. Because it grows too large and still is
never complete.
control access be considered discrimination? Would someone not
willing to cooperate with a member or supporter of a US/EU designated
terrorist group (say ISIS) be considered discrimination?
Good question. There's a potential for a lot of rule lawyering and
controversy about such things, and I think the right way to handle it is
not to try and write down every special case.
--
Stas Malyshev
smalyshev@gmail.com
-----Original Message-----
From: Andrea Faulds [mailto:ajf@ajf.me]
Sent: Sunday, January 24, 2016 7:38 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of ConductHi Zeev,
Zeev Suraski wrote:
One thing which isn't clear to me is whether this:
"If you conduct yourself in a way that is explicitly forbidden by the CoC, you
will be warned and asked to stop. If you do not stop, you will be removed
from our community spaces temporarily. Repeated, wilful breaches of the
CoC will result in a permanent ban."
... applies to reports, or only to proactive moderation. In other words,
whether the response to a report - anonymous or otherwise - can only result
in a warning the first time around? Can one only get permabanned after
numerous temporary bans and repeated 'offenses'?I don't think it specifically applies to reports or moderation, but rather to
what it says: "repeated, wilfull breaches". If the team is aware that you've
done something multiple times, then it's going to be more harsh on you. I
don't think whether each of those times was reported separately, if at all,
would mean anything.
I think it needs to be clarified because at least to me it's currently unclear. I'm happy with your interpretation.
Anyway, as to how many warnings people would get, and how quickly they
would be banned, if at all, would surely vary from case to case with severity.
We should assume whoever enforces this is somewhat reasonable.
I've said it before and I'll say it again.
My experience with other people interpreting the intent of RFCs (including ones I've written) has been downright horrible. That happened more than once. There were common ingredients in all of these cases:
- The original intent behind the RFC was lost, and the only thing that remained was the RFC text that was voted on.
- The text itself wasn't sufficiently robust (often an understatement), and assumed that it will be executed with the intent behind it as a part of the context.
In other words, my 'reasonable' could be very different from your 'reasonable', or from someone else's 'reasonable'. I'm reluctant to keep things vague where they should be clear. We can't be clear about the penalties, but not be clear about the situation in which they'd be applied - and the steps that would precede imposing them.
Last - does anybody know whether this CoC ever got 'battle tested' thus
far?This is a question I'm wondering about as well. It all seems pretty good, but I
wonder if, for example, the lists of unwelcome behaviour and discrimination
characteristics are sufficiently complete.
As I pointed out, I think it's too wide already.
Harassment and Bullying have been used by people on this list to describe situations which, in my opinion, not only shouldn’t constitute Harassment/Bullying, but are actually not even remotely close to being that.
'Demeaning' is also a term which is very vague, and could mean different things to different people, even more so than Harassment and Bullying.
If we were to accept these as a part of a CoC, there should be very clear cut definitions for them.
FWIW, as someone that's about to turn 40 in ~3 weeks, I find this definition of Harassment pretty harassing:
"Harassment is unwelcome conduct that is based on race, color, religion, sex (including pregnancy), national origin, age (40 or older), disability or genetic information."
:)
Zeev
Hi!
As I promised, in the spirit of constructive cooperation I've written an
example of how I would like our CoC to look:
https://github.com/smalyshev/php-community-health/blob/new-coc/RFC.rst
I do not see it as a final result but rather a draft that would provide
a direction and (if people here agree it's a good direction) will be
amended and refined as needed. The rest of the RFC text, beyond the CoC,
is the same, the patch only deals with CoC itself.
Would be glad to hear what everybody thinks of it.
Stas Malyshev
smalyshev@gmail.com
Hi!
if people here agree it's a good direction
You've watered down the text about bad behaviour in general and in
particular the bits explicitly listing bad behaviour surrounding
discussion of RFCs; I do not like that direction.
A significant number of technical RFC discussions have been less
productive than they should be, due to people repeatedly sending
emails against an RFC, that repeat what they have already said, which
is not a productive use of anyone's time, and makes people (including
myself) not want to put forward ideas, or to participate in the
discussions.
Also, you probably ought to put your own name as the author names on a
document when making large changes, instead of leaving other people's
at the top.
cheers
Dan
A significant number of technical RFC discussions have been less
productive than they should be, due to people repeatedly sending
emails against an RFC, that repeat what they have already said, which
is not a productive use of anyone's time, and makes people (including
myself) not want to put forward ideas, or to participate in the
discussions.
Or repeatedly sending emails for an RFC. ;-)
That is, if one thinks others should make their disagreement known only once, perhaps one should make one's own agreement known only once.
--
Paul M. Jones
pmjones88@gmail.com
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
Hi!
You've watered down the text about bad behaviour in general and in
particular the bits explicitly listing bad behaviour surrounding
discussion of RFCs; I do not like that direction.
I purposefully removed some examples of bad behavior, restricting it to
minimal list showing in broad lines what we won't accept. This is not
random - that's the whole point, telling what we want to see, and
spending only as much time on what we do not want to see as necessary
to give reasonable person an idea what they are not supposed to do,
without turning the thing into a penal code.
As for discussion of RFCs specifically, I think it should be guided by
the same rules as any other discussion on the project, and thus needs no
specific treatment, at least within the bounds of CoC. If we want
specific RFC-targeted advice, we can have it in the docs where we
describe how to make an RFC.
A significant number of technical RFC discussions have been less
productive than they should be, due to people repeatedly sending
emails against an RFC, that repeat what they have already said, which
And if you think CoC can or should prevent this, then we have radically
different views on what CoC is supposed to be. To me, CoC has two tasks:
-
Nudge people in the direction of better cooperation by showing them
how we expect them to behave (this is much more powerful thing than one
may think) and by establishing environment which would attract people
willing to cooperate nicely. -
Provide tools to deal with rare exceptional events which may
seriously disrupt or destroy cooperation in the project.
For me, if people would use CoC to count how many times they sent a
message on the list and then start arguing about that instead of the
actual matter, then we made things worse, not better. The thought that
somebody can be banned from discussion solely because they sent extra
email per hour, or repeated an argument, makes me cringe. We certainly
do not need anything like that here.
It looks like you want CoC to make discussions somehow more structured
or closed to how your ideal of the discussion looks like. If that is the
case, then indeed we have very different ideas of what CoC is for, and I
think most CoCs we have seen so far are nothing like that and never
intended to do that - i.e. regulate the content of non-abusive
non-conflict discussions.
Also, you probably ought to put your own name as the author names on a
document when making large changes, instead of leaving other people's
at the top.
As I said, I did not touch almost anything beyond CoC part. This is
nowhere near finished document, it's just a draft, so whatever name is
there does not matter now. When (if) we get to something finalized, then
we'd put names as appropriate.
--
Stas Malyshev
smalyshev@gmail.com
For me, if people would use CoC to count how many times they sent a
message on the list and then start arguing about that instead of the
actual matter, then we made things worse, not better. The thought that
somebody can be banned from discussion solely because they sent extra
email per hour, or repeated an argument, makes me cringe. We certainly
do not need anything like that here.
As someone who acknowledges that they perhaps send duplicate messages
when something irritates them, I think I can associate with that
statement. Slightly in defence, I would say that this is where the
debate between 'forum' and 'mail list' probably comes into play as to be
honest, I forget sometimes what has been said and am often replying to
the current quotes rather than reviewing the whole thread. Having the
whole thread on a forum would do nothing to solve that problem as with a
long debate you still only see a few messages but at least on my local
email archive I can scan back and now am to see just what I did say
before. That people fail to follow the etiquette set down to help make
the list more readable is probably a good example of why rules will get
broken anyway? I am now monitoring just what I have posted to a
thread, something which can't be done so easily on-line?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
-----Original Message-----
From: Dan Ackroyd [mailto:danack@basereality.com]
Sent: Monday, January 25, 2016 12:48 AM
To: Stanislav Malyshev smalyshev@gmail.com
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of ConductA significant number of technical RFC discussions have been less productive
than they should be, due to people repeatedly sending emails against an
RFC, that repeat what they have already said, which is not a productive use
of anyone's time, and makes people (including
myself) not want to put forward ideas, or to participate in the discussions.
Arguing against an RFC is at least as legitimate as arguing for it; Arguably, even more so - given our bias for status quo.
Put another word - the assumption (at least on the technical side) that the current situation is good, and there needs to be a very robust case enjoying widspread support in order to change it.
The nature of divisive RFCs - RFCs that garner strong support from both people in favor of them and against them - is that one camp is unable to convince the other for prolonged periods of time. That typically results in both camps raising the same reasons, both in favor and against, and 'continuously improving' their case. That's completely legitimate. It may be tiring - it's in fact almost definitely tiring, but there's no way around it - certainly not via a CoC that would censor one side or the other from championing what they believe in.
The only solution to the divisive RFC syndrome IMHO - that 'immunize' internals from having toxic discussions - is to radically bump up the pass threshold for RFCs.
Zeev
-----Original Message-----
From: Dan Ackroyd [mailto:danack@basereality.com]
Sent: Monday, January 25, 2016 12:48 AM
To: Stanislav Malyshev smalyshev@gmail.com
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of ConductArguing against an RFC is at least as legitimate as arguing for it;
Arguably, even more so - given our bias for status quo.
Put another word - the assumption (at least on the technical side) that
the current situation is good, and there needs to be a very robust case
enjoying widspread support in order to change it.
Not to nitpick, but if you're biased against status quo, what you need is
arguments that remove that bias - not arguments that strengthen it.
Your assumption that the status quo is good is a problem if it is a bias.
It is not a good thing, on the contrary, it actively prohibits you from
considering better alternatives to the status quo.
Regards
Peter
--
<hype>
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
</hype
-----Original Message-----
From: Peter Lind [mailto:peter.e.lind@gmail.com]
Sent: Monday, January 25, 2016 1:47 PM
To: Zeev Suraski zeev@zend.com
Cc: Dan Ackroyd danack@basereality.com; internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of ConductOn 25 January 2016 at 12:43, Zeev Suraski <zeev@zend.com
mailto:zeev@zend.com > wrote:-----Original Message-----
From: Dan Ackroyd [mailto:danack@basereality.com
mailto:danack@basereality.com ]
Sent: Monday, January 25, 2016 12:48 AM
To: Stanislav Malyshev <smalyshev@gmail.com
mailto:smalyshev@gmail.com >
Cc: internals@lists.php.net mailto:internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of
ConductArguing against an RFC is at least as legitimate as arguing for it;
Arguably, even more so - given our bias for status quo.
Put another word - the assumption (at least on the technical side)
that the current situation is good, and there needs to be a very robust case
enjoying widspread support in order to change it.Not to nitpick, but if you're biased against status quo, what you need is
arguments that remove that bias - not arguments that strengthen it.
I'm not talking about any person in particular - but the project as a whole. PHP is a very successful and widely used language, so our starting point with every discussion (at least technical one) should be that the status quo is not only acceptable, it's actually fine. It doesn't mean we can't do better and improve it - but it does mean that the onus of convincing the public that the proposal has merit is on the shoulders of the one making it. An important part of that discussion is that people who think the proposal is lacking, superfluous or outright bad, should argue their case.
While I'm very much in favor of encouraging people to think how they can improve on RFCs instead of just 'shooting them down', sometimes that's not possible or practical:
- Some ideas are just bad.
- Some ideas maybe generally good, but not good enough to be worth adding.
- Some people are better at finding what's wrong with a given proposal than they are at improving it. Often times, others (either the original authors or others) are motivated to think harder and come up with solutions to those issues when they're brought up.
Regardless, I believe Dan was talking about situations where we had 'stalemate' - cases in which people on both opposite camps of a given proposal couldn't convince the others. Censoring one of the sides - arguably the opposing side in particular (given the inherent assumption above) - is inconceivable.
Your assumption that the status quo is good is a problem if it is a bias.
Bias may or may not be the correct term here, but yes, I think the status quo is good. PHP is doing very well.
It is not
a good thing, on the contrary, it actively prohibits you from considering
better alternatives to the status quo.
Not at all, it just means that changes to the status quo must be duly scrutinized. An inherent part of that is trying to poke holes at it, or go as much as arguing against it if people think it's bad.
Zeev
Hi,
Hi all,
This is my first mail to the list so please let me know if I do anything
wrong or if there's a better channel by which to have this kind of
discussion.I'd like to propose adoption of an alternative code of conduct, the Go Code:
https://golang.org/conductThe primary reasons for suggesting this code are:
- The Go Code focuses primarily on desired behaviours ('be patient', 'be
respectful') and only secondarily on 'avoiding destructive behaviours'.- The Go Code explicitly notes that it "is not a mechanism for people to
silence others with whom they disagree." - this was a major concern on the
ML, so codifying that this usage will not be accepted in the CoC itself is a
step in the right direction.- The Go Code encourages everybody to follow the code in all spaces, but
limits explicit enforcement to Go spaces.- The Go Code is far more clear in defining prohibited behaviours.
Reading this previously, I think it's an essential example that should
definitely be taken into account.
Paddy