Hi,
I've decided to re-propose the CoC RFC. There are many reasons for it,
but there are a few points I want to make.
I strongly believe that a Code of Conduct is required. The amount of
toxic behaviour on this list is in my opinion unacceptable. It drives
people away, it certainly did. It is also one of the reasons I am not
nearly as active as I used to be.
It also makes me reluctant to welcome and mentor new people wanting to
contribute. I have said "no" to two people in the last few days, mostly
because I am not sure whether I want them exposed to some of the things
being said on the list.
But I think this list, and hence this project, and language, can be
improved. A Code of Conduct alone is not enough. The focus for this
list, and wider community, should be on collaborating to make PHP even
better and faster than it already is. Collaboration works better in a
happy environment, where people work together instead of against
eachother.
The new 0.5 version of the RFC that is up at
https://wiki.php.net/rfc/adopt-code-of-conduct focusses more on working
together and mediation than on acting with an iron fist on when things
go awry, although these parts of the RFC are still included. In my
opinion, an CoC that is not enforced is nothing but some text on a piece
of paper—or in our case, a few bits on a disk. I have added a section,
Constructive Contributor Guidelines, in addition to the CoC. This
section definitely needs improving.
I would everybody invite you to help out improving this RFC, but please
take into account
https://wiki.php.net/rfc/adopt-code-of-conduct#constructive_collaboration_guidelines
I want this to work, and work together, to get this approved.
cheers,
Derick
Am 20.01.16 um 20:04 schrieb Derick Rethans:
Hi,
I've decided to re-propose the CoC RFC. There are many reasons for it,
but there are a few points I want to make.I strongly believe that a Code of Conduct is required. The amount of
toxic behaviour on this list is in my opinion unacceptable. It drives
people away, it certainly did. It is also one of the reasons I am not
nearly as active as I used to be.It also makes me reluctant to welcome and mentor new people wanting to
contribute. I have said "no" to two people in the last few days, mostly
because I am not sure whether I want them exposed to some of the things
being said on the list.But I think this list, and hence this project, and language, can be
improved. A Code of Conduct alone is not enough. The focus for this
list, and wider community, should be on collaborating to make PHP even
better and faster than it already is. Collaboration works better in a
happy environment, where people work together instead of against
eachother.The new 0.5 version of the RFC that is up at
https://wiki.php.net/rfc/adopt-code-of-conduct focusses more on working
together and mediation than on acting with an iron fist on when things
go awry, although these parts of the RFC are still included. In my
opinion, an CoC that is not enforced is nothing but some text on a piece
of paper—or in our case, a few bits on a disk. I have added a section,
Constructive Contributor Guidelines, in addition to the CoC. This
section definitely needs improving.I would everybody invite you to help out improving this RFC, but please
take into account
https://wiki.php.net/rfc/adopt-code-of-conduct#constructive_collaboration_guidelinesI want this to work, and work together, to get this approved.
cheers,
Derick
Thank you Derick for stepping up!
I would have done it myself but you've been faster ;)
Let's work this out all together!
Cheers
Andreas
--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl |
| mailto:andreas@heigl.org N 50°22'59.5" E 08°23'58" |
| http://andreas.heigl.org http://hei.gl/wiFKy7 |
+---------------------------------------------------------------------+
| http://hei.gl/root-ca |
+---------------------------------------------------------------------+
Hi,
I've decided to re-propose the CoC RFC.
Is it a violation of the RFC rules to skip step 1 ("Email internals@lists.php.net to measure reaction to your intended proposal") and go straight to step 3 ("Create the RFC") ?
https://wiki.php.net/rfc/howto
At the very least, it seems like an initial email needs to be sent before putting the RFC on the wiki.
--
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
On Jan 20, 2016, at 13:04, Derick Rethans derick@derickrethans.nl
wrote:Hi,
I've decided to re-propose the CoC RFC.
Is it a violation of the RFC rules to skip step 1 ("Email
internals@lists.php.net to measure reaction to your intended proposal")
and go straight to step 3 ("Create the RFC") ?https://wiki.php.net/rfc/howto
At the very least, it seems like an initial email needs to be sent before
putting the RFC on the wiki.
Step 1 and 2 are for newcomers, specifically step 1 is about measuring if a
new feature is going to be implemented by some contributor or by the
proposer or just an idea. Since the RFC is not about code and also just
re-opened and not new, they don't really apply imho.
--
Paul M. Jones
pmjones88@gmail.com
http://paul-m-jones.comModernizing Legacy Applications in PHP
https://leanpub.com/mlaphpSolving the N+1 Problem in PHP
https://leanpub.com/sn1php
Hi Paul,
Paul M. Jones wrote:
Hi,
I've decided to re-propose the CoC RFC.
Is it a violation of the RFC rules to skip step 1 ("Email internals@lists.php.net to measure reaction to your intended proposal") and go straight to step 3 ("Create the RFC") ?
https://wiki.php.net/rfc/howto
At the very least, it seems like an initial email needs to be sent before putting the RFC on the wiki.
The howto isn't really a set of rules, more guidelines on how to do an
RFC. The actual hard rules as such are contained in the voting and
release process RFCs, among others.
It's not uncommon for people to propose RFCs without a prior mailing
list dicussion.
Thanks.
Andrea Faulds
https://ajf.me/
On Jan 20, 2016, at 13:04, Derick Rethans derick@derickrethans.nl
wrote:Hi,
I've decided to re-propose the CoC RFC.
Is it a violation of the RFC rules to skip step 1 ("Email
internals@lists.php.net to measure reaction to your intended proposal")
and go straight to step 3 ("Create the RFC") ?https://wiki.php.net/rfc/howto
At the very least, it seems like an initial email needs to be sent before
putting the RFC on the wiki.
for the record that is a guideline, which was edited over the years by
multiple people (mostly for the better), but that was never voted and have
no binding.
for the official rules about the actual rules for an rfc see
https://wiki.php.net/rfc/voting which states:
"Proposal is formally initiated by creating an RFC on PHP wiki and
announcing it on the list."
(but in this case it is even more easier because this isn't a new rfc just
a draft rfc getting taken over by another volunteer after the original
proposer stepped down)
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Jan 20, 2016, at 13:04, Derick Rethans derick@derickrethans.nl
wrote:Hi,
I've decided to re-propose the CoC RFC.
Is it a violation of the RFC rules to skip step 1 ("Email
internals@lists.php.net to measure reaction to your intended proposal") and
go straight to step 3 ("Create the RFC") ?https://wiki.php.net/rfc/howto
At the very least, it seems like an initial email needs to be sent before
putting the RFC on the wiki.
It is as far as I can tell not a violation as it is a take over.
Hi,
In order to make suggestions to the wording of the RFCs, and included
Contributer Covenant and Guideslines easier, I've imported it into
GitHub:
https://github.com/derickr/php-code-of-conduct/blob/master/RFC.rst
If you have specific suggestions, they're more than welcome there
through Pull Requests and comments (and issues). Hopefully, it makes it
easier to track things down, and keep it managable.
cheers,
Derick
Hi!
In order to make suggestions to the wording of the RFCs, and included
Contributer Covenant and Guideslines easier, I've imported it into
GitHub:https://github.com/derickr/php-code-of-conduct/blob/master/RFC.rst
Great idea. Unfortunately, I don't see any way in Github to comment
per-line on the actual text, only on patches. I'll try to do that but I
wonder if there's a better way.
--
Stas Malyshev
smalyshev@gmail.com
Hi Stas,
Stanislav Malyshev wrote:
Hi!
In order to make suggestions to the wording of the RFCs, and included
Contributer Covenant and Guideslines easier, I've imported it into
GitHub:https://github.com/derickr/php-code-of-conduct/blob/master/RFC.rst
Great idea. Unfortunately, I don't see any way in Github to comment
per-line on the actual text, only on patches. I'll try to do that but I
wonder if there's a better way.
You can't do it on the /blob/ view, but if you click on the commit to
get to the /commit/ view, you can comment on that. :)
--
Andrea Faulds
https://ajf.me/
Hi!
You can't do it on the /blob/ view, but if you click on the commit to
get to the /commit/ view, you can comment on that. :)
Right. That's what I meant by "patches". But that only specific commit,
not the whole result, right?
--
Stas Malyshev
smalyshev@gmail.com
Hi Stas,
Stanislav Malyshev wrote:
Hi!
You can't do it on the /blob/ view, but if you click on the commit to
get to the /commit/ view, you can comment on that. :)Right. That's what I meant by "patches".
Ah, okay. I took that to mean pull requests.
But that only specific commit,
not the whole result, right?
Apparently not. Alas.
Thanks.
Andrea Faulds
https://ajf.me/
You can't do it on the /blob/ view, but if you click on the commit
to get to the /commit/ view, you can comment on that. :)Right. That's what I meant by "patches". But that only specific commit,
not the whole result, right?
Correct - seems you found it though :-)
cheers,
Derick
Hi,
I've decided to re-propose the CoC RFC. There are many reasons for it,
but there are a few points I want to make.cheers,
Derick--
Hello,
if you still insists on some CoC, maybe you could at least look into
something else than the "Contributor Covenant"?
For example, http://code-of-merit.org/ seems much more reasonable in
"getting the things done" than the Covenant.
Regards
Pavel Kouril
I've decided to re-propose the CoC RFC. There are many reasons for it,
but there are a few points I want to make.if you still insists on some CoC, maybe you could at least look into
something else than the "Contributor Covenant"?For example, http://code-of-merit.org/ seems much more reasonable in
"getting the things done" than the Covenant.
Sure - I would very much appreciate a list of things to look at. Would
you have time to suggest a list with C of C's? It is unlikely that one
will cover it all anyway. Something that (stolen the idea from twitter)
has a good list of positive core values is also in my opinion
important to have.
cheers,
Derick
I've decided to re-propose the CoC RFC. There are many reasons for it,
but there are a few points I want to make.if you still insists on some CoC, maybe you could at least look into
something else than the "Contributor Covenant"?For example, http://code-of-merit.org/ seems much more reasonable in
"getting the things done" than the Covenant.Sure - I would very much appreciate a list of things to look at. Would
you have time to suggest a list with C of C's? It is unlikely that one
will cover it all anyway. Something that (stolen the idea from twitter)
has a good list of positive core values is also in my opinion
important to have.cheers,
Derick
Hi Derick,
I noticed you were contacted by Randi Lee Harper [https://archive.is/b8RDW], the ironically abusive founder of the Online Abuse Prevention Initiative [https://archive.is/eqco9][http://archive.is/A1Azz] known for attacking and attempting to eject from projects/employment people she associates with groups she doesn’t approve of [http://archive.is/1A8SQ], wherein she suggested that you ignore the Code of Merit that Pavel recommended for consideration because she associates the author of said code with a group that—though entirely unrelated to his Open Source contributions—she finds undesirable and then proceeded to make general derogatory comments about him [again, https://archive.is/b8RDW].
(My deepest apologies for such a tremendous run-on sentence.)
I certainly hope this isn’t indicative of the spirit of this proposal. This exchange really seems to suggest the goal of these codes in general, and now possibly this one in particular, is what so many of us have feared: to exclude people with wrong ideas and associations, as defined by the in-group.
Kevin Smith
Hearsay Interactive <http://gohearsay.com/
Hi!
[http://archive.is/1A8SQ], wherein she suggested that you ignore the
And this is exactly what we want to prevent from happening here.
--
Stas Malyshev
smalyshev@gmail.com
Hi,
I noticed you were contacted by Randi Lee Harper [https://archive.is/b8RDW], the ironically abusive founder of the Online Abuse Prevention Initiative [https://archive.is/eqco9][http://archive.is/A1Azz] known for attacking and attempting to eject from projects/employment people she associates with groups she doesn’t approve of [http://archive.is/1A8SQ], wherein she suggested that you ignore the Code of Merit that Pavel recommended for consideration because she associates the author of said code with a group that—though entirely unrelated to his Open Source contributions—she finds undesirable and then proceeded to make general derogatory comments about him [again, https://archive.is/b8RDW].
Are you here to debate the proposed COC, or to mount personal attacks
on someone outside of the PHP community?
(My deepest apologies for such a tremendous run-on sentence.)
I certainly hope this isn’t indicative of the spirit of this proposal. This exchange really seems to suggest the goal of these codes in general, and now possibly this one in particular, is what so many of us have feared: to exclude people with wrong ideas and associations, as defined by the in-group.
Is that what the RFC actually states though? As it's a code of
conduct, it's directed at specific actions not whatever is running
through your, or my, head.
Paddy
Padraic,
Taking a step back, instead taking a knee-jerk reaction; I think Kevin
brought up a valid point. Is very clear that there are certain actors
that are pushing for a specific version of this code of conduct to use
it as a political tool.
This is it what concerns most people regarding this specific CoC; you
want to debate the CoC proposed, fine. Personally here are my issues
with it:
- Language is vague and open to interpretation
- There is no mechanism or ability for one to confront ones accuser
- The CoC seems to be more concern with punitive action rather than
establishing the values of the community.
Allan.
Pádraic Brady wrote:
Hi,
I noticed you were contacted by Randi Lee Harper
[https://archive.is/b8RDW], the ironically abusive founder of the
Online Abuse Prevention Initiative
[https://archive.is/eqco9][http://archive.is/A1Azz] known for
attacking and attempting to eject from projects/employment people she
associates with groups she doesn’t approve of
[http://archive.is/1A8SQ], wherein she suggested that you ignore the
Code of Merit that Pavel recommended for consideration because she
associates the author of said code with a group that—though entirely
unrelated to his Open Source contributions—she finds undesirable and
then proceeded to make general derogatory comments about him [again,
https://archive.is/b8RDW].Are you here to debate the proposed COC, or to mount personal attacks
on someone outside of the PHP community?(My deepest apologies for such a tremendous run-on sentence.)
I certainly hope this isn’t indicative of the spirit of this
proposal. This exchange really seems to suggest the goal of these
codes in general, and now possibly this one in particular, is what so
many of us have feared: to exclude people with wrong ideas and
associations, as defined by the in-group.Is that what the RFC actually states though? As it's a code of
conduct, it's directed at specific actions not whatever is running
through your, or my, head.Paddy
Taking a step back, instead taking a knee-jerk reaction; I think Kevin
brought up a valid point. Is very clear that there are certain actors
that are pushing for a specific version of this code of conduct to use
it as a political tool.
I am going to stop you right there. There is no agreement on the text of
the code of conduct, and rather, perhaps not even on the base which
might result in PHP's version of anything. Randi merely pointed out her
specific issues with an alternative Code of Conduct (which, funnily,
said it is actually not one). As I already wrote, I don't think it's
suitable: http://news.php.net/php.internals/90771
This is it what concerns most people regarding this specific CoC; you
want to debate the CoC proposed, fine. Personally here are my issues
with it:
- Language is vague and open to interpretation
- The CoC seems to be more concern with punitive action rather than
establishing the values of the community.
Picking up on these two first. Both points are probably valid, and I
have already asked for constructive feedback on it. Just stating these
two points is not feedback, it's just saying that you don't like it.
Suggest how to improve it, and I would be more than happy to listen to
the feedback. We might not agree though.
- There is no mechanism or ability for one to confront ones accuser
That is a tricky one. In my opinion, in the case of abuse as pointed out
in the draft CoC, I think this is fair, and necessary that we all for
reports of abuse in private, and with secrecy. Without it, an accusor is
likely immediately going to be lambasted by the perpetrator.
Having a private mediation board or process is for the same reasons that
companies allow annonymous feedback about managers, co-workers, peers
and leadership. Their HR basically would function as our proposed
Mediation Team. Without privacy, it is extremely unlikely people would
even bother putting in a complaint, afraid of a public outlash.
However, the accuser can through the Mediation Team of course reach the
complainant - but the identity should be guarded as private. The current
language in the RFC reads:
"Reasonable efforts should be taken to ensure the privacy of the
reporting party. The only two exceptions would be if the
incident was public or if the reporting party agrees to be
identified."
That is in the context only among the accusor, Mediation Team, and
accused. Not towards the community as a whole.
cheers,
Derick
- There is no mechanism or ability for one to confront ones accuser
That is a tricky one. In my opinion, in the case of abuse as pointed out
in the draft CoC, I think this is fair, and necessary that we all for
reports of abuse in private, and with secrecy. Without it, an accusor is
likely immediately going to be lambasted by the perpetrator.
Here we have the core of (yet another) problem: presumption of guilt. The "accused" is casually referred to as the "perpetrator." This is exactly why the accused needs to be able to confront the accuser.
The common reply here is to say "oops, sorry, I meant to say 'the accused'". I don't think that's true; it's a wink-and-a-nod, a recognition that one has revealed their true thoughts: all accusations are to be believed. Except, of course, the ones that are not to be believed, and those will (strangely enough) line up with the political beliefs of the enforcers. Because it is a political document, the Contributor Covenant is intended to work that way.
That is only one of the many reasons the Contributor Covenant, and all documents like it, should be removed in toto from any Code of Conduct discussion.
--
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,
On 21 January 2016 at 14:33, Allan MacGregor
amacgregor@allanmacgregor.com wrote:
Padraic,
Taking a step back, instead taking a knee-jerk reaction; I think Kevin
brought up a valid point. Is very clear that there are certain actors that
are pushing for a specific version of this code of conduct to use it as a
political tool.
The RFC has actual text, which can be read, examined and discussed.
There is no need whatsoever to drag in anything beyond unless directly
relevant to the text at hand. Personal attacks on people who support a
COC, or do not support a COC, aren't productive. If there is a
political plot to undermine whatever in PHP, then please do support
this by quoting from the RFC.
This is it what concerns most people regarding this specific CoC; you want
to debate the CoC proposed, fine. Personally here are my issues with it:
- Language is vague and open to interpretation
Propose specific text which also addresses harassment and the other
not vague words. I’m sure people will happily read and review it.
- There is no mechanism or ability for one to confront ones accuser
Any evidence being used against an individual will be made available
to them. In fact, it’s explicitly required. However, it’s also clear
that confidentiality will be adhered to. This is par for the course,
at least in my experience, of any such process. The COC is also not a
criminal proceeding – there is no legal court involved – so the
emphasis is on protecting the potential complainant from additional
targeted action.
- The CoC seems to be more concern with punitive action rather than
establishing the values of the community.
Derick added a second section of more relevance to collaborative
values. Also, I’m on record as believing that while punitive action
need not be the central theme in a COC, it has to clear somewhere that
it CAN be employed when absolutely necessary. Hopefully never! But I
left my crystal ball at home…so I can’t rule it out.
Paddy
--
Pádraic Brady
Hi,
On 21 January 2016 at 14:33, Allan MacGregor
amacgregor@allanmacgregor.com wrote:Padraic,
Taking a step back, instead taking a knee-jerk reaction; I think Kevin
brought up a valid point. Is very clear that there are certain actors that
are pushing for a specific version of this code of conduct to use it as a
political tool.The RFC has actual text, which can be read, examined and discussed.
There is no need whatsoever to drag in anything beyond unless directly
relevant to the text at hand. Personal attacks on people who support a
COC, or do not support a COC, aren't productive. If there is a
political plot to undermine whatever in PHP, then please do support
this by quoting from the RFC.
That's a nice try, but since the Contributor Covenant is a political document, the politics of those who favor it are fair game. Also, your attempt to characterize "quoting someone's own words" as "personal attacks" is noted.
--
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!
That's a nice try, but since the Contributor Covenant is a political
document, the politics of those who favor it are fair game. Also,
I don't think we need to discuss politics here, at least "politics of
those", i.e. personal views rather than merits of specific proposals. I
see no good that can come out of it. I think we know there are some
agents out there (not here on the list) that have interests outside of
the well-being of this community, and I think that's as far as we should
go in discussing them here, going further IMO won't help any.
Yes, the code - whatever its formula ends up being - is a political
document in its essence, as it aims to describe our goals, behavioral
patterns, social agreements and mores, etc. - which is ultimately what
politics is about. However, that does not mean we should bring in
political discussions not related to out community, I think it would not
help.
Stas Malyshev
smalyshev@gmail.com
Paul M. Jones wrote:
That's a nice try, but since the Contributor Covenant is a political document, the politics of those who favor it are fair game. Also, your attempt to characterize "quoting someone's own words" as "personal attacks" is noted.
Inherently, any discussion concerning interactions between people is
"political". Politics is not the exclusive domain of states, it's a
feature of any and every social group.
And unfortunately, any document which says that you can't discriminate
is political, any document which says harassment is wrong is political,
in fact anything which proscribes any behaviour of any kind is political.
Also, arguing against a code of conduct is, in itself, also political.
If you don't think a code of conduct is necessary, it's a political
statement, just as being in favour of one is.
So, basically, what I'm saying that complaining something involves
"politics" is fruitless, because of course it does. Instead, argue your
case for why the "politics" of it is - that is, the content - is bad. If
it happens to be written by people who disagree from your political
persuasion, that would be immaterial. The content is what is being
discussed and potentially adopted, not the author's personal views.
--
Andrea Faulds
https://ajf.me/
Hi,
Pádraic Brady mailto:padraic.brady@gmail.com
January 21, 2016 at 10:59 AM
Hi,On 21 January 2016 at 14:33, Allan MacGregor
amacgregor@allanmacgregor.com wrote:Padraic,
Taking a step back, instead taking a knee-jerk reaction; I think Kevin
brought up a valid point. Is very clear that there are certain actors that
are pushing for a specific version of this code of conduct to use it as a
political tool.The RFC has actual text, which can be read, examined and discussed.
There is no need whatsoever to drag in anything beyond unless directly
relevant to the text at hand. Personal attacks on people who support a
COC, or do not support a COC, aren't productive. If there is a
political plot to undermine whatever in PHP, then please do support
this by quoting from the RFC.
Let's discuss the CoC at hand. Is my opinion that the current text based
on the Contributors Covenant 1.3 is too broad on its scope and the
punitive actions. What do I mean too broad? well I think the CoC needs
to define what a project channel/space is; as well there should be a
clarification that contributors are entitled to their political views
and opinions outside of these channels.
With that in mind I'm attaching the following draft that extends the
definition of the second paragraph and attempts to define that the
official project channels are
https://gist.github.com/amacgregor/16c62908ff39f51604e2 in short:
We are committed to evaluating contributions within project channels
(such as reporting issues, posting feature requests, updating
documentation, submitting pull requests or patches, and other project
activities) without regard to the contributor's level of experience,
gender, gender identity and expression, sexual orientation, disability,
personal appearance, body size, race, ethnicity, age, religion,
nationality, politics, or activity outside of project channels.
The following are considered the official project channels:
- PHP Mailing list
- PHP Official IRC Channel
- PHP Official repositories
- PHP Official social media accounts
Based on paul's earlier post http://news.php.net/php.internals/90259
This is it what concerns most people regarding this specific CoC; you want
to debate the CoC proposed, fine. Personally here are my issues with it:
- Language is vague and open to interpretation
Propose specific text which also addresses harassment and the other
not vague words. I’m sure people will happily read and review it.
- There is no mechanism or ability for one to confront ones accuser
Any evidence being used against an individual will be made available
to them. In fact, it’s explicitly required. However, it’s also clear
that confidentiality will be adhered to. This is par for the course,
at least in my experience, of any such process. The COC is also not a
criminal proceeding – there is no legal court involved – so the
emphasis is on protecting the potential complainant from additional
targeted action.
That might be the case, but we are talking about applying sanctions with
real world repercussions and as such having a confrontation clause or at
least the right to cross examination and face my accuser.
– so the emphasis is on protecting the potential complainant from
additional targeted action.
If the emphasis is on fairness, equality and justice, then you have to
protect the rights of the accused and the accuser.
- The CoC seems to be more concern with punitive action rather than
establishing the values of the community.Derick added a second section of more relevance to collaborative
values. Also, I’m on record as believing that while punitive action
need not be the central theme in a COC, it has to clear somewhere that
it CAN be employed when absolutely necessary. Hopefully never! But I
left my crystal ball at home…so I can’t rule it out.Paddy
--
Pádraic Brady
Allan MacGregor mailto:amacgregor@allanmacgregor.com
January 21, 2016 at 9:33 AM
Padraic,Taking a step back, instead taking a knee-jerk reaction; I think Kevin
brought up a valid point. Is very clear that there are certain actors
that are pushing for a specific version of this code of conduct to use
it as a political tool.This is it what concerns most people regarding this specific CoC; you
want to debate the CoC proposed, fine. Personally here are my issues
with it:
- Language is vague and open to interpretation
- There is no mechanism or ability for one to confront ones accuser
- The CoC seems to be more concern with punitive action rather than
establishing the values of the community.Allan.
Pádraic Brady wrote:
Pádraic Brady mailto:padraic.brady@gmail.com
January 21, 2016 at 7:19 AM
Hi,I noticed you were contacted by Randi Lee Harper [https://archive.is/b8RDW], the ironically abusive founder of the Online Abuse Prevention Initiative [https://archive.is/eqco9][http://archive.is/A1Azz] known for attacking and attempting to eject from projects/employment people she associates with groups she doesn’t approve of [http://archive.is/1A8SQ], wherein she suggested that you ignore the Code of Merit that Pavel recommended for consideration because she associates the author of said code with a group that—though entirely unrelated to his Open Source contributions—she finds undesirable and then proceeded to make general derogatory comments about him [again, https://archive.is/b8RDW].
Are you here to debate the proposed COC, or to mount personal attacks
on someone outside of the PHP community?(My deepest apologies for such a tremendous run-on sentence.)
I certainly hope this isn’t indicative of the spirit of this proposal. This exchange really seems to suggest the goal of these codes in general, and now possibly this one in particular, is what so many of us have feared: to exclude people with wrong ideas and associations, as defined by the in-group.
Is that what the RFC actually states though? As it's a code of
conduct, it's directed at specific actions not whatever is running
through your, or my, head.Paddy
Kevin Smith mailto:kevin@gohearsay.com
January 20, 2016 at 11:37 PMHi Derick,
I noticed you were contacted by Randi Lee Harper
[https://archive.is/b8RDW], the ironically abusive founder of the
Online Abuse Prevention Initiative
[https://archive.is/eqco9][http://archive.is/A1Azz] known for
attacking and attempting to eject from projects/employment people she
associates with groups she doesn’t approve of
[http://archive.is/1A8SQ], wherein she suggested that you ignore the
Code of Merit that Pavel recommended for consideration because she
associates the author of said code with a group that—though entirely
unrelated to his Open Source contributions—she finds undesirable and
then proceeded to make general derogatory comments about him [again,
https://archive.is/b8RDW].(My deepest apologies for such a tremendous run-on sentence.)
I certainly hope this isn’t indicative of the spirit of this proposal.
This exchange really seems to suggest the goal of these codes in
general, and now possibly this one in particular, is what so many of
us have feared: to exclude people with wrong ideas and associations,
as defined by the in-group.Kevin Smith
Hearsay Interactive http://gohearsay.com/
Derick Rethans mailto:derick@php.net
January 20, 2016 at 4:20 PMSure - I would very much appreciate a list of things to look at. Would
you have time to suggest a list with C of C's? It is unlikely that one
will cover it all anyway. Something that (stolen the idea from twitter)
has a good list of positive core values is also in my opinion
important to have.cheers,
Derick
--
Allan MacGregor
coderoncode.com <http://coderoncode.com
I've decided to re-propose the CoC RFC. There are many reasons for it,
but there are a few points I want to make.if you still insists on some CoC, maybe you could at least look into
something else than the "Contributor Covenant"?For example, http://code-of-merit.org/ seems much more reasonable in
"getting the things done" than the Covenant.Sure - I would very much appreciate a list of things to look at. Would
you have time to suggest a list with C of C's? It is unlikely that one
will cover it all anyway. Something that (stolen the idea from twitter)
has a good list of positive core values is also in my opinion
important to have.cheers,
Derick
Hi,
unfortunately, I don't have time for that (or at least not now). :(
The other thing is, I honestly don't believe you even need a CoC - and
if you really DO need it, it should be as short as possible, basically
something like "write code/rfcs, politely discuss it and don't discuss
anything not related to project on project forums/mailing lists/etc."
should be totally enough. The longer the CoC gets, the more "clutter"
it will have - as you can see in the Covenant.
(This is why I find the Code of Merit much better than Covenant, even
though it is IMHO still too long - and the fact it doesn't have
approximately 1/3 or 1/4 of the text dedicated to listing abusive
behavior and the general equality stuff, like Covenant does. And that
it doesn't try to control people outside of the project.)
Regards
PK
I've decided to re-propose the CoC RFC. There are many reasons for
it, but there are a few points I want to make.if you still insists on some CoC, maybe you could at least look into
something else than the "Contributor Covenant"?For example, http://code-of-merit.org/ seems much more reasonable in
"getting the things done" than the Covenant.
I had a look at this, and I think it is not suitable. It is almost the
exact opposite of promoting collaborative behaviour, and instead only
focusses on the "if you done nothing before, you have no voice". There
is also no chance the PHP project will have have a benevolent dictator
(or group of people). And it only focusses on the technical aspects of a
community, but even covering a set of guidelines to improve
collaboration.
cheers,
Derick
Hi,
For example, http://code-of-merit.org/ seems much more reasonable in
"getting the things done" than the Covenant.
I reviewed this last night, and it hasn’t fared any better after a
night’s sleep. The Code of Merit essentially creates an armour clad
rejection of any non-technical topic. It makes this very clear by
explicitly stating that such topics must be discussed elsewhere. It
also explicitly states that “disruption of the project will not be
tolerated”. It doesn’t define disruption, of course. It doesn’t even
define a mediation process. I doesn’t actually mention any undesired
interpersonal conduct at all.
It’s effectively the total opposite of the currently proposed RFC, and
then some.
Paddy
The Code of Merit essentially creates an armour clad
rejection of any non-technical topic.
Is really that bad, this is an open source project. We are talking about
a programming language not a socio-political movement? Or did I missed
the memo?
When it comes down to PHP itself the main concern should be the language
and the development of the project.
Pádraic Brady wrote:
The Code of Merit essentially creates an armour clad
rejection of any non-technical topic.
Hi Allan,
Allan MacGregor wrote:
The Code of Merit essentially creates an armour clad
rejection of any non-technical topic.
Is really that bad, this is an open source project. We are talking about
a programming language not a socio-political movement? Or did I missed
the memo?
An open-source project is not merely a bundle of code, but also a
community that maintains it. As with any social group created by humans,
you will always have to discuss things related to the group itself as well.
When it comes down to PHP itself the main concern should be the language
and the development of the project.
Indeed, and towards that end, it is sometimes necessary to have meta
discussions. Projects are, after all, composed of people, not binary blobs.
If we fail to successfully manage a community, then the project will die
or be taken up by another group. So far we seem to have not done
absolutely terribly, or there wouldn't be a discussion here. We didn't
reach this point by never, ever talking about non-technical matters.
Thanks.
Andrea Faulds
https://ajf.me/
-----Original Message-----
From: Derick Rethans [mailto:derick@derickrethans.nl]
Sent: Wednesday, January 20, 2016 9:04 PM
To: PHP Developers Mailing List internals@lists.php.net
Subject: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of ConductHi,
I've decided to re-propose the CoC RFC. There are many reasons for it, but
there are a few points I want to make.
I want to point three key concerns that are unrelated to the contents of the updated RFC before addressing the RFC itself (in short). Note that I'm not blaming or otherwise holding you in any negative light in any way, but rather, stating my opinion on the context of the RFC.
First, on process.
I continue to hold that this proposal does not belong under the umbrella of the RFC process, given that the RFC process was never meant to deal with such cases. It was meant to deal with technical and administrative items. I have no idea whether or not this can win 2/3 of the votes, but regardless, it should pass a much higher bar for acceptance as an essential from-scratch 'constitution' for the PHP project. Having a controversial constitution from the get go is unacceptable IMHO.
Second, on drama.
I think that the situation where someone withdraws an RFC and another person all-too-expectedly takes over needs to stop. It's one thing to turn to someone else and have them lead from now. It's an entirely different thing to withdraw and have someone else take over. I think that if someone withdraws an RFC (as opposed to amending it or adding additional co-authors) - it should have the same ramifications as a failed vote. Withdrawing an RFC should not be a dramatic instrument. Yes, I realize the Voting RFC doesn't state that. I'm stating my opinion.
Third, on undue pressure.
Certain people have either implied or outright said that not having a CoC will make them reconsider actively contributing to PHP. This is undue pressure IMHO, avoiding the use of bigger words.
I also want to quickly address the essence of the updated RFC in short, and in particular, it's stated goal:
I strongly believe that a Code of Conduct is required. The amount of toxic
behaviour on this list is in my opinion unacceptable. It drives people away, it
certainly did. It is also one of the reasons I am not nearly as active as I used to
be.
Much of what I wrote in my message to Anthony, that can be titled "What could possibly go wrong?", still holds with the updated draft (the message is available here: internals@lists.php.net/msg82913.html" rel="nofollow" target="_blank">www.mail-archive.com/internals@lists.php.net/msg82913.html).
There's one very notable exception - there is no ambiguity in any way about what you're trying to address - which is fix 'toxic internals'. Notably, this is a substantial shift (and arguably a 180 degrees turn) from what Anthony said this RFC is supposed to address:
"There are two prime reasons people may avoid internals (at least related to this discussion).
- Don't want to deal with the aggressive tone of the list 2. Don't want to expose themselves to targeted aggression/negativity
The first is not in scope of this RFC. We may or we may not want to take steps in the future to "fix" that, but that's not in scope here."
For me, it validates that my worries about the widespread confusion were indeed completely justified. But much worse, it means that with the author's stated goal of this RFC addressing the 'Toxic Internals' issue, the risks associated with this RFC are no longer theoretical. They're real, and we'd be slipping down that slippery slope sooner rather than later.
I'm not going to repeat arguments I've made half a dozen times as to why having a judicial system must be avoided, and why we must deal exclusively with desired behaviors and not the 'exception handling' of bad behaviors. I made my case in the best possible way I can and people who are interested in it can read it in my previous replies on the topic. Equally important - many others expressed similar views. Thus far, the only response is a laconic 'without penalties it's useless', even though we've brought numerous supporting arguments as why this is simply not true.
I will repeat that I'm very much in favor of a CoC that includes our positive core values, and that includes a mediation team in case people are feeling offended and that can intervene also w/o complaint - but that does not have any sort of special powers - but is instead exclusively based on good will of all parties. Even if certain people don't think that's good enough, I don't believe that anybody would argue that it's BAD - the way many think the current CoC proposal is. This is precisely why this is the right place to start.
Thanks,
Zeev
Hi,
Up front, I agree the objective of the COC needs to be clearly stated.
There is confusion, whether it's here or externally by observers, as
to whether this is intended to fix mailing list toxicity (I assume,
for now, not) or intended to state the projects intentions should
there be a complaint concerning conduct as specifically listed in the
COC text per the RFC. It serves neither side when this confusion gets
muddled into argument for, against or in-between.
I'm not going to repeat arguments I've made half a dozen times as to why having a judicial system must be avoided, and why we must deal exclusively with desired behaviors and not the 'exception handling' of bad behaviors. I made my case in the best possible way I can and people who are interested in it can read it in my previous replies on the topic. Equally important - many others expressed similar views. Thus far, the only response is a laconic 'without penalties it's useless', even though we've brought numerous supporting arguments as why this is simply not true.
I will repeat that I'm very much in favor of a CoC that includes our positive core values, and that includes a mediation team in case people are feeling offended and that can intervene also w/o complaint - but that does not have any sort of special powers - but is instead exclusively based on good will of all parties. Even if certain people don't think that's good enough, I don't believe that anybody would argue that it's BAD - the way many think the current CoC proposal is. This is precisely why this is the right place to start.
Thanks,
Zeev
At a basic level, what exactly is a code of conduct where the only
consequence is mediation, where both parties are assumed to have good
will, and where the outcome is ??????????. That's the a problem from
my perspective. What is the outcome? Does mediation continue
indefinitely without results? While the mediation is ongoing for the
long haul, will be there be any remediation set to protect a
theoretical victim? What is Plan B? Part of the COC is to explicitly
limit ad-hoc reactions should things go completely down the gutter by
defining something upfront. By extension, any uncertainty of what
would happen should Person A complain may act as a deterrent to making
such a complaint. It could be anticipated that long drawn out
procedures with an unknown ending are in and of themselves stressful
(and to both parties to boot).
Sincere apologies if this is covered elsewhere.
Paddy
-----Original Message-----
From: Pádraic Brady [mailto:padraic.brady@gmail.com]
Sent: Thursday, January 21, 2016 1:43 AM
To: Zeev Suraski zeev@zend.com
Cc: Derick Rethans derick@derickrethans.nl; PHP Developers Mailing List
internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of ConductHi,
Up front, I agree the objective of the COC needs to be clearly stated.
There is confusion, whether it's here or externally by observers, as to
whether this is intended to fix mailing list toxicity (I assume, for now, not) or
intended to state the projects intentions should there be a complaint
concerning conduct as specifically listed in the COC text per the RFC. It serves
neither side when this confusion gets muddled into argument for, against or
in-between.
I think the fact that this RFC was (and still is) perceived to be a solution for the toxic internals problem - actually served the proponents of this RFC very well. On one hand, this is what people at large care about. On the other - the proponents can tell the those who oppose that it's not at all what the RFC is about, and that their worries about this becoming a tool for a behavioral/thought police are completely baseless.
Note that despite the fact that Derick - who's now the RFC author - clearly said that the reason he's reviving the RFC is because internals is toxic - you're still assuming that the RFC isn't intended to 'fix mailing list toxicity'.
Can we get any more confused than that?
At a basic level, what exactly is a code of conduct where the only
consequence is mediation, where both parties are assumed to have good
will, and where the outcome is ??????????.
My take? A successful one. One that we can all rally behind, as opposed to a controversial one that is creating much angst. Please see my response to Andrea.
That's the a problem from my
perspective. What is the outcome? Does mediation continue indefinitely
without results?
No, in the vast majority - and I do mean VAST majority, mediation works and results would be quick. When people are told that they should cool off, they typically do. I know I would. Even more so if that mediation team could point me to a certain desired behavior I'm not quite following at that time, and do so respectfully and not judgmentally.
While the mediation is ongoing for the long haul, will be
there be any remediation set to protect a theoretical victim? What is Plan B?
I don't think we can go on discussing two completely different issues - safety and 'toxicity', while jumping in between them as if they're the same thing. The way the current RFC author sets of the scope is much wider than safety issues, and the use of the word 'victim' and 'remediation' are not really relevant to it - at least in the vast majority of incidents we're likely to experience
Part of the COC is to explicitly limit ad-hoc reactions should things go
completely down the gutter by defining something upfront. By extension,
any uncertainty of what would happen should Person A complain may act as
a deterrent to making such a complaint. It could be anticipated that long
drawn out procedures with an unknown ending are in and of themselves
stressful (and to both parties to boot).
There's just no way to undo the damage that the threat of penalties does when the goal is trying to foster positive behavior. Any education person - and hopefully most parents - will tell you that. Our brains respond completely differently to demands and threats versus encouragement and guidance.
There's no absolute winning formula, and there's no one size fits all. Yes, in an extreme, uncommon case - the fact we're focusing on desired behavior and not on 'deterrence' - might cause a certain individual to feel they can do a certain something and get away with it (something, that if safety issues was what we're dealing with, may very well be illegal and carry criminal penalties). Is it worth to design our whole system around that extremely infrequent situation AT THE EXPENSE of how we deal with the normal day to day situations? I know my answer.
Zeev
Hi,
I think the fact that this RFC was (and still is) perceived to be a solution for the toxic internals problem - actually served the proponents of this RFC very well. On one hand, this is what people at large care about. On the other - the proponents can tell the those who oppose that it's not at all what the RFC is about, and that their worries about this becoming a tool for a behavioral/thought police are completely baseless.
Note that despite the fact that Derick - who's now the RFC author - clearly said that the reason he's reviving the RFC is because internals is toxic - you're still assuming that the RFC isn't intended to 'fix mailing list toxicity'.
Can we get any more confused than that?
We can but try to be more confused ;). I was indeed though – my bad.
The revised RFC has two parts combined and I glossed completely over
the second:
-
The Code of Conduct (i.e. Contributor Covenant 1.3)
-
Constructive Collaboration Guidelines (i.e. somewhat “toxicity” related)
At a basic level, what exactly is a code of conduct where the only
consequence is mediation, where both parties are assumed to have good
will, and where the outcome is ??????????.My take? A successful one. One that we can all rally behind, as opposed to a controversial one that is creating much angst. Please see my response to Andrea.
That's the a problem from my
perspective. What is the outcome? Does mediation continue indefinitely
without results?No, in the vast majority - and I do mean VAST majority, mediation works and results would be quick. When people are told that they should cool off, they typically do. I know I would. Even more so if that mediation team could point me to a certain desired behavior I'm not quite following at that time, and do so respectfully and not judgmentally.
Agreed.
While the mediation is ongoing for the long haul, will be
there be any remediation set to protect a theoretical victim? What is Plan B?I don't think we can go on discussing two completely different issues - safety and 'toxicity', while jumping in between them as if they're the same thing. The way the current RFC author sets of the scope is much wider than safety issues, and the use of the word 'victim' and 'remediation' are not really relevant to it - at least in the vast majority of incidents we're likely to experience
Apologies, that wasn’t my intent – I wasn’t referring to the
“toxicity” issue. Solely referring there to anything under the
Contributor Covenant section of the RFC. The words “victim”, etc do
apply there in the context of harassment and such.
Part of the COC is to explicitly limit ad-hoc reactions should things go
completely down the gutter by defining something upfront. By extension,
any uncertainty of what would happen should Person A complain may act as
a deterrent to making such a complaint. It could be anticipated that long
drawn out procedures with an unknown ending are in and of themselves
stressful (and to both parties to boot).There's just no way to undo the damage that the threat of penalties does when the goal is trying to foster positive behavior. Any education person - and hopefully most parents - will tell you that. Our brains respond completely differently to demands and threats versus encouragement and guidance.
There's no absolute winning formula, and there's no one size fits all. Yes, in an extreme, uncommon case - the fact we're focusing on desired behavior and not on 'deterrence' - might cause a certain individual to feel they can do a certain something and get away with it (something, that if safety issues was what we're dealing with, may very well be illegal and carry criminal penalties). Is it worth to design our whole system around that extremely infrequent situation AT THE EXPENSE of how we deal with the normal day to day situations? I know my answer.
It doesn’t need to revolve entirely around it, but it should somewhere
acknowledge it. Honestly, I don’t care if it’s one line in a footnote
in pt2 font size, so long as it’s there.
Also, loosely connected and off on a tangent perhaps, it’s important
that we don’t just expect legal consequences to solve everything at
the extreme end of the spectrum. While that avenue can certainly
exist, depending on local laws, I imagine the cost would be
prohibitive (for not outright criminal behaviour) and I really don’t
see that working well across international borders. I can only speak
to local practice and solicitor costs here on one small island, of
course.
Paddy
--
Pádraic Brady
Hi!
First, on process.
Tangentially related, by pure coincidence I was given today a link to an
IETF RFC describing their view on consensus:
https://tools.ietf.org/html/rfc7282
While their procedures are substantially different from ours, and for a
good reason, I think learning from their experience and their take on
what consensus means and how one would get there would be educational. I
know for me it was.
Stas Malyshev
smalyshev@gmail.com
Hi Zeev,
Zeev Suraski wrote:
I want to point three key concerns that are unrelated to the contents of the updated RFC before addressing the RFC itself (in short). Note that I'm not blaming or otherwise holding you in any negative light in any way, but rather, stating my opinion on the context of the RFC.
First, on process.
I continue to hold that this proposal does not belong under the umbrella of the RFC process, given that the RFC process was never meant to deal with such cases. It was meant to deal with technical and administrative items. I have no idea whether or not this can win 2/3 of the votes, but regardless, it should pass a much higher bar for acceptance as an essential from-scratch 'constitution' for the PHP project. Having a controversial constitution from the get go is unacceptable IMHO.
I wouldn't say the idea of a code of conduct is really a constitution
per se (it's not setting down the foundation and goals of the PHP
project, merely rules for misconduct), it's more like an administrative
document. That being said, you may have a point with it not being what
RFCs were really intended for. But we don't really have an alternative
process for this currently established, so an RFC is the best we can do.
Second, on drama.
I think that the situation where someone withdraws an RFC and another person all-too-expectedly takes over needs to stop. It's one thing to turn to someone else and have them lead from now. It's an entirely different thing to withdraw and have someone else take over. I think that if someone withdraws an RFC (as opposed to amending it or adding additional co-authors) - it should have the same ramifications as a failed vote. Withdrawing an RFC should not be a dramatic instrument. Yes, I realize the Voting RFC doesn't state that. I'm stating my opinion.
We work in the open and follow the spirit of open-source. Anyone can
copy and modify any other RFC if they so please. If we don't allow
people to resurrect other RFCs, then it gives the original author more
control than perhaps they should have. Consider that during the Scalar
Type Declarations dicussions, you revived an earlier version of my RFC,
because you wanted to keep that approach alive. Likewise, when I left
due to personal issues, Anthony revived my RFC in a new form. Sara was
also going to revive my RFC if I remember rightly. Were we all wrong?
RFC revival is essentially like forking, and that's always allowed in
open-source.
Third, on undue pressure.
Certain people have either implied or outright said that not having a CoC will make them reconsider actively contributing to PHP. This is undue pressure IMHO, avoiding the use of bigger words.
It might leave others feeling pressured, but it's not their fault if
those contributors feel unsafe without a code of conduct. Nor is the
flip-side true: a certain person said they fear getting in trouble for
their political views if the CoC passes, and if they wanted to leave as
a result, so be it. Nobody is under any obligation to contribute to PHP,
they can freely choose not to contribute if they wish, and that is their
right.
I think it would be worse if you were not allowed to make such
statements. It's better that people be aware of consequences than be
surprised later.
I also want to quickly address the essence of the updated RFC in short, and in particular, it's stated goal:
I strongly believe that a Code of Conduct is required. The amount of toxic
behaviour on this list is in my opinion unacceptable. It drives people away, it
certainly did. It is also one of the reasons I am not nearly as active as I used to
be.Much of what I wrote in my message to Anthony, that can be titled "What could possibly go wrong?", still holds with the updated draft (the message is available here: internals@lists.php.net/msg82913.html" rel="nofollow" target="_blank">www.mail-archive.com/internals@lists.php.net/msg82913.html).
There's one very notable exception - there is no ambiguity in any way about what you're trying to address - which is fix 'toxic internals'. Notably, this is a substantial shift (and arguably a 180 degrees turn) from what Anthony said this RFC is supposed to address:
"There are two prime reasons people may avoid internals (at least related to this discussion).
- Don't want to deal with the aggressive tone of the list 2. Don't want to expose themselves to targeted aggression/negativity
The first is not in scope of this RFC. We may or we may not want to take steps in the future to "fix" that, but that's not in scope here."For me, it validates that my worries about the widespread confusion were indeed completely justified. But much worse, it means that with the author's stated goal of this RFC addressing the 'Toxic Internals' issue, the risks associated with this RFC are no longer theoretical. They're real, and we'd be slipping down that slippery slope sooner rather than later.
Personally, I don't see how expanding from covering serious misbehaviour
(harassment etc.) to covering more generally
non-conducive-to-civil-discussion actions would make things more or less
open to potential abuse. Generally, opinions are not the problem, but
rather the way people go about expressing them.
I'm not going to repeat arguments I've made half a dozen times as to why having a judicial system must be avoided, and why we must deal exclusively with desired behaviors and not the 'exception handling' of bad behaviors. I made my case in the best possible way I can and people who are interested in it can read it in my previous replies on the topic. Equally important - many others expressed similar views. Thus far, the only response is a laconic 'without penalties it's useless', even though we've brought numerous supporting arguments as why this is simply not true.
Even if you believe that it's not a problem, that doesn't change the
opinion of people who do think that an unenforced code of conduct is
problematic.
I will repeat that I'm very much in favor of a CoC that includes our positive core values, and that includes a mediation team in case people are feeling offended and that can intervene also w/o complaint - but that does not have any sort of special powers - but is instead exclusively based on good will of all parties. Even if certain people don't think that's good enough, I don't believe that anybody would argue that it's BAD - the way many think the current CoC proposal is. This is precisely why this is the right place to start.
A set of positive values is all well and good, but that won't fix
anything when people nonetheless act outside the rules, which is what a
code of conduct sets out to deal with. Or, basically, I think it's sort
of derailing, though I realise that is not what you intend. A set of
positive values doesn't constitute a "code".
That said, laying down what our values are might be a worthwhile
project, it should just be in a separate discussion. Having a slightly
more definitive idea of what PHP and its community is and it stands for
would be nice.
Thanks.
--
Andrea Faulds
https://ajf.me/
Hi!
It might leave others feeling pressured, but it's not their fault if
those contributors feel unsafe without a code of conduct. Nor is the
I don't want to be dismissive, but I do not see anything on the list
that should make anybody feel unsafe (unless of course I misunderstand
what you mean by "unsafe", in which case please correct me).
Uncomfortable - sure, exhausted and exasperated - oh yes, but unsafe?
I mean, everybody has the right to feel whatever they like, but I
don't see how we can accept any responsibility for those feelings if
they have no base in anything that actually happened? I feel like more
insight into this would definitely be useful - what concerns about
safety we have and CoC would fix?
flip-side true: a certain person said they fear getting in trouble for
their political views if the CoC passes, and if they wanted to leave as
a result, so be it. Nobody is under any obligation to contribute to PHP,
they can freely choose not to contribute if they wish, and that is their
right.
That is certainly true, in general. In particular, though, the argument
"do as I tell, or I'll take my toys and leave" is not a very
constructive approach, because it leaves no space for seeking compromise
- either you do exactly as you told to, fully submitting to whatever the
other person says to do, or no collaboration happens ever. While on some
(very small set of) questions it may be the way to go, in most areas I
don't think this is a fair way to do things.
I think it would be worse if you were not allowed to make such
statements. It's better that people be aware of consequences than be
surprised later.
I am a firm believer in freedom of expression, so "allowed" is not a
question, however some arguments definitely sound very manipulative, and
"do this, or I leave" is one of them. So it would be nice to avoid it if
at all possible. Especially when it comes to respected members of the
community whose contribution is valued - it is too easy to abuse that as
a means of just silencing anybody who disagrees.
Personally, I don't see how expanding from covering serious misbehavior
(harassment etc.) to covering more generally
non-conducive-to-civil-discussion actions would make things more or less
Very easily. Instead of discussing things on merits, people start
rule-laywering and offense-sniping each other. In fact, we see this
happening from time to time even now, when people who dislike RFC try to
argue against it on technicalities, and I think it does not improve
matters, but if we officially enshrine this as a policy, this would grow
tenfold. It is much easier to say "she is posting too often!" or "he
disagrees with me too much and I feel offended and threatened!" and try
to shut the opponent up than to address the matter of disagreement. So
we are creating motivation for destructive behavior. This needs to be
addressed.
Even if you believe that it's not a problem, that doesn't change the
opinion of people who do think that an unenforced code of conduct is
problematic.
Worse than not having any at all? If so, why exactly - what aspect or
behavior specifically is becoming worse?
--
Stas Malyshev
smalyshev@gmail.com
Hi Stas,
Stanislav Malyshev wrote:
Hi!
It might leave others feeling pressured, but it's not their fault if
those contributors feel unsafe without a code of conduct. Nor is theI don't want to be dismissive, but I do not see anything on the list
that should make anybody feel unsafe (unless of course I misunderstand
what you mean by "unsafe", in which case please correct me).
Uncomfortable - sure, exhausted and exasperated - oh yes, but unsafe?
I mean, everybody has the right to feel whatever they like, but I
don't see how we can accept any responsibility for those feelings if
they have no base in anything that actually happened? I feel like more
insight into this would definitely be useful - what concerns about
safety we have and CoC would fix?
Safety isn't usually something people have to worry about with the list,
I think. Usually we're civil.
That being said, the CoC discussion seems to have attracted attention
from other parts of the Internet, and at least I, personally, do not
feel entirely safe speaking out about it now because I fear becoming the
newest target of online harassment from right-wing groups. This
discussion is already being watched by them.
I can't really talk about other people's motives for not contributing,
however. Certainly safety isn't the only concern people might have.
flip-side true: a certain person said they fear getting in trouble for
their political views if the CoC passes, and if they wanted to leave as
a result, so be it. Nobody is under any obligation to contribute to PHP,
they can freely choose not to contribute if they wish, and that is their
right.That is certainly true, in general. In particular, though, the argument
"do as I tell, or I'll take my toys and leave" is not a very
constructive approach, because it leaves no space for seeking compromise
- either you do exactly as you told to, fully submitting to whatever the
other person says to do, or no collaboration happens ever. While on some
(very small set of) questions it may be the way to go, in most areas I
don't think this is a fair way to do things.
It's not a nice way to conduct negotiations, but I don't think this is a
deliberate attempt at forcing people to accept a code of conduct.
Rather, I think people who have said they might leave do so because they
have gotten sick of the "toxicity" of the list and are the code of
conduct being rejected because of it would be a last straw. I can't
claim to speak for them, though, so I'll stop talking about this.
It comes off as manipulative, but what can be done? Would it be better
to silently disappear after a code of conduct is rejected?
Personally, I don't see how expanding from covering serious misbehavior
(harassment etc.) to covering more generally
non-conducive-to-civil-discussion actions would make things more or lessVery easily. Instead of discussing things on merits, people start
rule-laywering and offense-sniping each other. In fact, we see this
happening from time to time even now, when people who dislike RFC try to
argue against it on technicalities, and I think it does not improve
matters, but if we officially enshrine this as a policy, this would grow
tenfold. It is much easier to say "she is posting too often!" or "he
disagrees with me too much and I feel offended and threatened!" and try
to shut the opponent up than to address the matter of disagreement. So
we are creating motivation for destructive behavior. This needs to be
addressed.
Ah, actually I can see what you're getting at. It does sometimes happen
that people complain about how others are behaving in discussions,
others who disagree with them. But I think often those concerns are
quite valid nonetheless... surely it must be possible to design things
so that dealing with such behaviour doesn't give the opposing side an
unfortunate advantage. Perhaps if you were to temporarily ban someone
from the list, say, it would delay the RFC they were dicussing. It must
be possible to deal with people's behaviour separately from their
technical opinions. I worry if people can be immune from criticism
because they favour a particular side of a technical argument.
That's just a very quick thought though, don't take it as a concrete
proposal, it's more a musing.
Even if you believe that it's not a problem, that doesn't change the
opinion of people who do think that an unenforced code of conduct is
problematic.Worse than not having any at all?
It could be, it's arguable. If you have a set of rules but nothing is
done if they are violated, then someone who sees the set of rules and is
unaware they are unenforced might be given a false impression.
Thanks.
Andrea Faulds
https://ajf.me/
I wouldn't say the idea of a code of conduct is really a constitution per se (it's
not setting down the foundation and goals of the PHP project, merely rules
for misconduct)
Should somehow this RFC get ratified, it would be by far the closest thing that the PHP project will have for a constitution.
For what it's worth, I find the description 'rules for misconduct' extremely telling and fairly horrible way to describe a Code of Conduct, as I'm sure any people involved with education would agree.
That being said,
you may have a point with it not being what RFCs were really intended for.
Thanks for acknowledging the possibility - however remote - that the author of the RFC process he 'may have a point' about what the document he was the lead author for was or rather wasn't about :)
But we don't really have an alternative process for this currently established,
so an RFC is the best we can do.
Oh, but we do. As I'm sure many of us remember, PHP existed for 15 years before the RFC process, and it actually became the most popular language on the planet during that time. Yes, the RFC process made things go quicker and evolution faster - but given it was designed for technical decisions and administrative items - not constitutional ones - it cannot be used here.
Namely - decision by consensus. This is absolutely required in a topic as far-reaching as this, which is very clearly outside the scope of the RFC process.
RFC revival is essentially like forking, and that's always allowed in open-
source.
We have clear rules which disallow revival of RFCs which failed a vote for a duration of six months, unless they're very substantially modified, so revival isn't always allowed in open source.
Maybe I'm a cynic, but when I saw that the RFC was withdrawn, I was (almost) literally counting the minutes before someone came, in the electronic equivalent of a shining armor, to revive it. It's also clear that had Derick not done it, someone else would have.
Maybe I'm a cynic #2, but to me, it's an attempt to make a point in an undue manner. And I don't think that should be allowed. I think we all have bigger fish to fry right now though, so that's not something I'm going to actively argue on - especially as the current Voting RFC doesn't detail that. I'm merely stating my opinion.
Third, on undue pressure.
Certain people have either implied or outright said that not having a CoC
will make them reconsider actively contributing to PHP. This is undue
pressure IMHO, avoiding the use of bigger words.It might leave others feeling pressured
s/might/absolutely does.
, but it's not their fault if those
contributors feel unsafe without a code of conduct.
I'll state right here that I find it virtually impossible to believe that the abovementioned individuals feel unsafe because of the lack of a CoC. And before I'm under a torrent of attacks that I couldn't possibly know how people feel - I'm acknowledging that right now. I don't. But that's what I think, and I stand behind this guesstimate.
Nor is the flip-side true: a
certain person said they fear getting in trouble for their political views if the
CoC passes, and if they wanted to leave as a result, so be it.
But incidentally, nobody did - at least to the best of my knowledge - even though I wouldn't be surprised if some do. Which is precisely the difference between what can be described as a threat, and a true action->consequence.
Nobody is under
any obligation to contribute to PHP, they can freely choose not to contribute
if they wish, and that is their right.
Right. But I'll say it again - I think that threatening to quit the project if one doesn't get their way about something - anything - is undue pressure. That's my opinion, and I'm not pretending it's the law so obviously people are free to ignore it.
I think it would be worse if you were not allowed to make such statements.
It's better that people be aware of consequences than be surprised later.
I think it would be awful if people weren't allowed to make such statements. And at the same time, it's disappointing to me that people choose to make those statements.
So far, the only document around that is trying to claim jurisdiction about what people may or may not say is the CoC RFC (notice the fundamental difference between 'may', 'should' and 'encouraged to').
Personally, I don't see how expanding from covering serious misbehaviour
(harassment etc.) to covering more generally non-conducive-to-civil-
discussion actions would make things more or less open to potential abuse.
Generally, opinions are not the problem, but rather the way people go about
expressing them.
If I understand you correctly, you're saying that assuming we have a penalty - at the discretion of a given body - to temp-ban someone from the project and recommend a perma-ban, it doesn't matter whether they can do it only in response to a threat of violence that's clearly proven that was made by that individual, or, instead, someone thinking they heard this said individual calling them a moron while talking to his friend in a conference venue? And it's all because the judicial team would be comprised of people we can trust? Do you really not see a difference between that whole system kicking into gear around something that many of us don't think ever happened in the relevant venues we're dealing with (safety issues) - and that same system kicking into gear whenever someone feels that somebody else is 'being toxic'?
To me, that's equivalent to having the life in prison penalty available as a punishment for every crime, at the discretion of the judge. Judges are professional, right? We can trust them not to practically deprive someone of their life for a traffic violation, right? So why not have life in prison available as an option for any and all crimes? Why even have different punishments for different crimes?
The potential for mishaps (not just abuse) is DIRECTLY correlated to the scope and pervasiveness of the domain the law (in our case, the CoC RFC) deals with. If it's dealing with safety issues - that likelihood is RELATIVELY limited (but still, substantial). If it's for 'detoxicating internals', the potential for mishaps is mind-bogglingly explosive. It's not a matter of if - it's a matter of when and how frequently.
I'm not going to repeat arguments I've made half a dozen times as to why
having a judicial system must be avoided, and why we must deal exclusively
with desired behaviors and not the 'exception handling' of bad behaviors. I
made my case in the best possible way I can and people who are interested
in it can read it in my previous replies on the topic. Equally important - many
others expressed similar views. Thus far, the only response is a laconic
'without penalties it's useless', even though we've brought numerous
supporting arguments as why this is simply not true.Even if you believe that it's not a problem, that doesn't change the opinion of
people who do think that an unenforced code of conduct is problematic.
The word 'problematic' doesn't belong here. Nobody claimed that a CoC without penalties is 'problematic', in the sense that it's worse than not having one. In fact, everyone, yourself included, seem to agree that it's a good thing - with virtually no downsides. You're calling it 'problematic' - because in your opinion, it doesn't properly address what you think needs to be addressed. But 'problematic' is simply not the correct word here. 'Inadequate' or 'Insufficient' are. Replace the wrongly applied 'problematic' with 'insufficient', and it becomes clear that the fact there is consensus that stating our desired behavior is a Good Thing makes it precisely the right place to start. We can 'upgrade' from that into a judicial CoC at any given time, if it gains consensus.
A set of positive values is all well and good, but that won't fix anything when
people nonetheless act outside the rules, which is what a code of conduct
sets out to deal with.
That's simply not true. First, we don't have these rules to begin with, and for some reason, the one invariant in all of the discussion of the CoC is how it 'must be enforceable', while the values themselves are pretty much for hire. That's backwards. We should first be talking about these values.
Secondly, when there's an agreed-upon set of rules, you'd be surprised how it ABSOLUTELY DOES fix the vast majority of situations where people act outside the rules. I highly recommend watching a few episodes of Super Nanny, or otherwise taking some educational courses for parents. They're inspiring - and not just for parents. And from personal experience - they work remarkably well, almost like magic.
Or, basically, I think it's sort of derailing, though I realise
that is not what you intend. A set of positive values doesn't constitute a
"code".
Actually, that's almost exactly what it is. Not only do a set of positive values and desired behaviors constitute a code of conduct - it's almost the definition of what a code of conduct is. In fact, it is the RFC that we have on the table that is not a CoC, but rather, a law+judicial system (and an amateur one at that, with no offense meant - nobody here is a professional legislator to the best of my knowledge). I brought it up numerous times here already, but the Ten Commandments, the Hippocratic Oath and the Golden Rule - arguably three of the most influential CoCs that shaped humanity for the better, are all exactly that - a set of positive values and desired behaviors. No penalties. No judicial systems. No 'what happens if' (with one exception - one of the commandments actually tells people to respect their parents so that they would live longer - which incidentally is positive encouragement and not a negative one).
Please see en.wikipedia.org/wiki/Code_of_conduct
That said, laying down what our values are might be a worthwhile project
Might? It's orders of magnitude more important than anything we've discussed so far on this thread - in my humble opinion, of course.
, it
should just be in a separate discussion. Having a slightly more definitive idea
of what PHP and its community is and it stands for would be nice.
It should, and it should preface any sort of law & order RFC the kind of which we're currently dealing with. Unlike this RFC, I believe it actually can easily gain consensus.
Thanks,
Zeev
For what it's worth, I find the description 'rules for misconduct' extremely
telling and fairly horrible way to describe a Code of Conduct, as I'm sure any
people involved with education would agree.
Agreed.
But we don't really have an alternative process for this currently
established,
so an RFC is the best we can do.
Wow, you managed to dismiss +15 years of people working together, creating
something which changed the world, in just one sentence. Perplexing.
We have clear rules which disallow revival of RFCs which failed a vote for a
duration of six months, unless they're very substantially modified, so revival
isn't always allowed in open source.
I think Derick is abusing the RFC process here clearly. The necessary action
should be clear based on that.
Sascha
Hi,
Zeev Suraski wrote:
I wouldn't say the idea of a code of conduct is really a constitution per se (it's
not setting down the foundation and goals of the PHP project, merely rules
for misconduct)Should somehow this RFC get ratified, it would be by far the closest thing that the PHP project will have for a constitution.
For what it's worth, I find the description 'rules for misconduct' extremely telling and fairly horrible way to describe a Code of Conduct, as I'm sure any people involved with education would agree.
Why? Misconduct is simply the inversion of 'conduct', and a code of
conduct, necessarily, primarily deals with misconduct. Good conduct is
supposed to be what normally happens. It's the exceptions to that -
misconduct - that you need a code to manage.
But we don't really have an alternative process for this currently established,
so an RFC is the best we can do.Oh, but we do. As I'm sure many of us remember, PHP existed for 15 years before the RFC process, and it actually became the most popular language on the planet during that time. Yes, the RFC process made things go quicker and evolution faster - but given it was designed for technical decisions and administrative items - not constitutional ones - it cannot be used here.
Namely - decision by consensus. This is absolutely required in a topic as far-reaching as this, which is very clearly outside the scope of the RFC process.
What do you consider to constitute consensus? Absolute unanimity, or
large majority support?
RFC revival is essentially like forking, and that's always allowed in open-
source.We have clear rules which disallow revival of RFCs which failed a vote for a duration of six months, unless they're very substantially modified, so revival isn't always allowed in open source.
Yes, that's true, but withdrawing an RFC isn't failing a vote. It
doesn't say anything about whether the community is against the
proposal, it only means the person proposing it is no longer able and/or
willing to carry it forward personally.
Maybe I'm a cynic, but when I saw that the RFC was withdrawn, I was (almost) literally counting the minutes before someone came, in the electronic equivalent of a shining armor, to revive it. It's also clear that had Derick not done it, someone else would have.
Sure, because it's a proposal that a lot of people support. Again, think
back to the Scalar Type Declarations discussion. The moment I left,
Anthony picked up the tab. I never asked him to, and in fact I was
scared that me leaving would doom the project. Also, Stas picked up the
spaceship RFC, and I never asked him to do that.
It's pretty much democracy in action. If some popular proposal is
abandoned, inevitably someone in the community will want to pick it up.
I suppose it means people should just plan to properly hand things over
rather than quit, given how fairly inevitable someone else picks these
things up again, but nobody is acting in bad faith here.
Also, it's not actually inevitable that things are picked up. When I
quit in February 2015, some of my proposals died then and there. Nobody
rode in with shining armour on their glorious battle elePHPant to "save"
them.
Maybe I'm a cynic #2, but to me, it's an attempt to make a point in an undue manner.
It's not a terribly nice way to make a point, for sure, but I don't
think that's really the intent in most cases. After the uh, controversy,
that things like this RFC and the Scalar Types saga provoke, I couldn't
personally blame anyone for getting sick of it and being unable to go on.
And I don't think that should be allowed. I think we all have bigger
fish to fry right now though, so that's not something I'm going to
actively argue on - especially as the current Voting RFC doesn't detail
that. I'm merely stating my opinion.
Fair enough.
Third, on undue pressure.
Certain people have either implied or outright said that not having a CoC
will make them reconsider actively contributing to PHP. This is undue
pressure IMHO, avoiding the use of bigger words.It might leave others feeling pressured
s/might/absolutely does.
, but it's not their fault if those
contributors feel unsafe without a code of conduct.I'll state right here that I find it virtually impossible to believe that the abovementioned individuals feel unsafe because of the lack of a CoC.
Well, I, personally, do not feel entirely safe in this discussion.
Safety is subjective, sure, but nobody can say whether someone else
feels unsafe, only they themselves.
Seeing what has happened to countless people that have spoken up online
about harassment, and knowing that I contribute under my actual
real-life name, has made me self-censor to some extent. I decided not to
revive the CoC RFC myself for a reason. Seeing certain participants in
the code of conduct discussion openly retweet messages by leaders of
organised harassment campaigns, campaigns targeting people like me, is
absolutely terrifying.
Unlike some people, I have the misfortune of having been on the Internet
when I was very young. I've said enough silly things online that if
someone wants to make my life absolute hell, they definitely can.
Now, so far I've been okay. But maybe that's because I've only made
relatively mild criticisms of the code of conduct on this mailing list,
and been mostly quiet on the more public platform of Twitter. Maybe
that's because I've refrained from naming certain people during discussions.
My fear here does not come from the PHP mailing list. PHP internals, for
all its "toxic kindergarten"-ness, is mostly civil. We're not the Linux
Kernel Mailing List, and I think that's something we can all be proud
of. The broader PHP community, however, is not always quite so friendly.
The mailing list is not isolated from this: anyone can join at any time.
Indeed, the code of conduct discussion has already brought new members.
We don't exist in a vacuum.
--
Andrea Faulds
https://ajf.me/
Hi!
Why? Misconduct is simply the inversion of 'conduct', and a code of
conduct, necessarily, primarily deals with misconduct. Good conduct is
supposed to be what normally happens. It's the exceptions to that -
misconduct - that you need a code to manage.
I would disagree with that. If you look around at numerous examples of
codes from other projects provided here on the list so far, most of them
are much more than penal code. And that's not a coincidence - it works
much better with people if you start with what we're trying to do and
why, and then proceed to what, in the light of the above, we do not do
and not allow to be done. It's not something we invented right now - a
lot of people in many projects seem to agree this is the best way to do
things.
What do you consider to constitute consensus? Absolute unanimity, or
large majority support?
I'd like to repost this link: https://tools.ietf.org/html/rfc7282
While it does not exactly answer the question as such, I think it
makes it easier to get thinking about it and illuminates some issues
with what we do - e.g. 67% vote is hardly "consensus", and even 99% vote
sometimes may not be the same as consensus. Again, it's not a
solution, more food for thought.
I suppose it means people should just plan to properly hand things over
rather than quit, given how fairly inevitable someone else picks these
things up again, but nobody is acting in bad faith here.
Yes, I think people should propose handover, especially for RFCs that
clearly have more than one person supporting. I understand it is hard to
do in the middle of rage-quitting or exhausted-quitting, but I think it
is time to remind people of this option, maybe add to the RFC process.
It can be as simple as "please take over this RFC otherwise I will
withdraw it" instead of just withdrawing.
Seeing what has happened to countless people that have spoken up online
about harassment, and knowing that I contribute under my actual
real-life name, has made me self-censor to some extent. I decided not to
Well, this is a problem. It is a very serious problem. People lost their
jobs, careers, reputations and other things because of internet and
meatspace trolls. However, as far as I can see, it is not the problem
that our community has, and I think we can keep it this way. And that
relates of course to trolls of all political persuasions, colors and
shapes - of which, yes, there's no shortage of. Not providing food or
shelter to them is one of the thing we hope to achieve at least in the
spaces of this project.
revive the CoC RFC myself for a reason. Seeing certain participants in
the code of conduct discussion openly retweet messages by leaders of
organised harassment campaigns, campaigns targeting people like me, is
absolutely terrifying.
I would caution though about making guilt by association. Re-tweeting
something (often third-, fourth- and 9000th-hand) does not mean agreeing
with all the author of the tweet has ever said or done. I don't want to
go too deep into problems of Tweeter and such as a discussion medium
(TLDR: it is unbelievably bad), but one of the things we don't want to
get into is permanently labeling people because they once shared a link
to something written by somebody who also wrote something bad on
entirely different media, possibly years ago.
I think the principle of "assuming good faith"
(https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith) would be a
good idea here. Note this is not a permanent label either, it is
"assumption" for initial approach to the interaction.
We don't exist in a vacuum.
I agree. And this is why we should be careful in what we accept as a
commitment by the community - because it doesn't affect only us here
that discuss it, and not only our motivations, interests and actions
would be important. We know from our 20-year experience in PHP project
that people would try to use what we create in ways we never thought of,
some of them wonderful, some of them making us shudder.
Stas Malyshev
smalyshev@gmail.com
That's been in my queue for a while...
-----Original Message-----
From: Andrea Faulds [mailto:ajf@ajf.me]
Sent: Thursday, January 21, 2016 6:26 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of ConductHi,
Namely - decision by consensus. This is absolutely required in a topic as far-
reaching as this, which is very clearly outside the scope of the RFC process.What do you consider to constitute consensus? Absolute unanimity, or large
majority support?
I think consensus is comprised of two things:
-
Truly trying to come up with a resolution that is not controversial - i.e., where you have either no or virtually no people who think the resolution is downright BAD. Note the difference from thinking that it's not good or unhelpful, or people that are indifferent to it - but rather, people thinking it's bad. As long as you have a fair number of people who think the resolution is downright bad - it's outside the consensus IMHO - regardless of any particular majority bar. So it's not only the amount of people who are voting no, but also their level of opposition to the proposal. I think the amount of people who've expressed strong opposition to the principals laid out by Anthony as mandatory for an acceptable CoC (scope of applicability, teeth, etc.) are clear indicators for lack of consensus around a controversial proposal.
-
Once you have a proposal that doesn't have strong opposition - you still need an overwhelming majority to ratify it, to make sure people aren't only comfortable with the general idea but also with the details. I think it's pretty easy to spot consensus, and most of our decisions win what I would call consensus. Looking again at bit.ly/php7rfcs - I'd say an 85-90% bar would be reasonable.
As a flipside example, I suspect we should be able to agree on values and mediation principals with a majority that will be well above 90%, and without anybody arguing that it would be bad for the project. There'll probably still be people voting against it because they'd think it's not needed, a waste of time or whatnot - but you'd be very unlikely to find people actively campaigning against it. That's indicative of consensus.
My fear here does not come from the PHP mailing list. PHP internals, for all
its "toxic kindergarten"-ness, is mostly civil. We're not the Linux Kernel
Mailing List, and I think that's something we can all be proud of. The broader
PHP community, however, is not always quite so friendly.
I very much appreciate your words here. Although I'm personally not a subscriber to the idea that internals is a toxic kindergarten (although it can certainly become one at times) - I'm happy you're viewing internals as (mostly) civil.
Thanks,
Zeev
We have clear rules which disallow revival of RFCs which failed a vote for a duration of six months, unless they're very substantially modified, so revival isn't always allowed in open source.
As other people have noted, the RFC never went to vote, so it was
never rejected.
But even if it had been, the actual text is you're claiming as a clear rule is:
"it will not be allowed to bring up a rejected proposal up for another
vote, unless...The author(s) make substantial changes to the
proposal."
There is absolutely no rule against being allowed to discuss
something. The only rule is about putting stuff to a vote repeatedly.
aka please don't try to shut down conversations you don't like.
cheers
Dan
Dan,
Dan Ackroyd wrote:
We have clear rules which disallow revival of RFCs which failed a vote for a duration of six months, unless they're very substantially modified, so revival isn't always allowed in open source.
As other people have noted, the RFC never went to vote, so it was
never rejected.But even if it had been, the actual text is you're claiming as a clear rule is:
"it will not be allowed to bring up a rejected proposal up for another
vote, unless...The author(s) make substantial changes to the
proposal."There is absolutely no rule against being allowed to discuss
something. The only rule is about putting stuff to a vote repeatedly.
This is true, but Ze'ev acknowledged that already.
--
Andrea Faulds
https://ajf.me/
Hi!
I've decided to re-propose the CoC RFC. There are many reasons for it,
but there are a few points I want to make.I strongly believe that a Code of Conduct is required. The amount of
toxic behaviour on this list is in my opinion unacceptable. It drives
people away, it certainly did. It is also one of the reasons I am not
nearly as active as I used to be.
Thanks for continuing the discussion. I'd like however to point out that
one of the major points of contention, as I see it - that it is not at
all clear how having CoC prohibiting things like "the use of sexualized
language" and "trolling", would help with "toxic behavior". I want to be
very clear, because I feel this concern is not being understood, so I
will try to outline it as detailed as I can, please excuse the verbosity:
-
I do not think literally anybody wants to see trolling or sexual
language attacks, or harassment, etc. on the list. I think we all agree
this is unacceptable. -
I think most of the people here know that the list has been not the
friendliest place ever, and most of the people here would like to
improve that. -
I do not think we do have now or ever had a significant problem with
behaviors described by "Code of Conduct Text". I think the problem
described may be caused by other set of behaviors, not covered by "Code
of Conduct Text". -
Given that, it is not clear to me, and apparently some other folks
too, how banning those (as universally agreed) despicable behaviors is
going to lead to any improvement on the matter of "toxic". -
Since so many people somehow did not understand that, judging by
their comments, this does not mean anybody thinks it is OK to behave
that way (see 1). It means that it appears we are trying very hard to
fix not the same place that is claimed to be broken.
Now, it can be that both places are broken, or that the fix can be
applied as a preventive measure - and both are fine. But arguing "we
have problem X therefore let's apply fix for a different problem Y"
sounds strange to me.
I think clarifying that matter would help.
Also, there was a complaint that there has been too much critique and
not enough constructive proposals. I think there is some truth to that,
as it is much easier to find bugs than to develop things, and much more
people submit bug reports than fix them. This is natural, but this
certainly could use improvement. In that spirit, I would like to
reiterate the proposal of handling CoC matters that I personally think
would be the best. This is my personal approach, so please feel free to
amend, criticize and disagree.
- Make a values statement, along the lines of:
https://www.drupal.org/dcoc
https://www.djangoproject.com/conduct/
https://www.freebsd.org/internal/code-of-conduct.html
https://meta.wikimedia.org/wiki/Grants:Friendly_space_expectations
This document should emphasize behaviors we want to achieve and
reinforce, not be just a catalog of behaviors we hate.
In this document, as one paragraph, include "unacceptable behavior"
statement from current RFC, verbatim or suitably modified (that of
course does not preclude including other parts of it in other paragraphs).
"Constructive Collaboration Guidelines" probably should be part of this
document too - and be stated before the unacceptable part. I know it
sound like nitpicking but I think tone of the documents is important and
if we start with negatives (even by rejecting them) it sets different
tone than if we start with positive. It's one thing to welcome people to
your house with "Welcome, friend, feel at home!" and another with
"Please don't steal my wallet and don't kick my dog!"
-
Create a conflict resolution team whose stated purpose is to resolve
conflicts (note: not punish or exclude!) which impact the project and
impede or disrupt the collaboration. -
Separately from the document above, have a conflict resolution
policy, which describes how the CRT above is elected, how it resolves
issues, what are the confidentiality guidelines, what are processes for
creating bans & appeals, etc.
I know not everybody agrees, but I think it is much more beneficial to
have this in a separate document and if possible, as a separate RFC,
since discussion about it is substantially different from (1) and
partially from (2) - principal agreement on having such team is much
more important, IMO, than figuring out how long it can ban people for.
That would also make discussion a bit more manageable, as discussing at
the same time two different things: do we want CoC and the particular
details of CRT behavior we want. I think separating these discussion
would allow us to emphasize things we agree on and formalize them
quickly, and hash out the details without the concern that small
disagreements would derail the whole process.
If this looks good to anybody, I can take the time to actually arrange
the texts - though English not being my naive language, I am not the
best person for copy-writing. But I assume somebody could fix it up
afterwards :)
Stas Malyshev
smalyshev@gmail.com
Hi!
I've decided to re-propose the CoC RFC. There are many reasons for it,
but there are a few points I want to make.I strongly believe that a Code of Conduct is required. The amount of
toxic behaviour on this list is in my opinion unacceptable. It drives
people away, it certainly did. It is also one of the reasons I am not
nearly as active as I used to be.Thanks for continuing the discussion. I'd like however to point out that
one of the major points of contention, as I see it - that it is not at
all clear how having CoC prohibiting things like "the use of sexualized
language" and "trolling", would help with "toxic behavior". I want to be
very clear, because I feel this concern is not being understood, so I
will try to outline it as detailed as I can, please excuse the verbosity:
I do not think literally anybody wants to see trolling or sexual
language attacks, or harassment, etc. on the list. I think we all agree
this is unacceptable.I think most of the people here know that the list has been not the
friendliest place ever, and most of the people here would like to
improve that.I do not think we do have now or ever had a significant problem with
behaviors described by "Code of Conduct Text". I think the problem
described may be caused by other set of behaviors, not covered by "Code
of Conduct Text".Given that, it is not clear to me, and apparently some other folks
too, how banning those (as universally agreed) despicable behaviors is
going to lead to any improvement on the matter of "toxic".Since so many people somehow did not understand that, judging by
their comments, this does not mean anybody thinks it is OK to behave
that way (see 1). It means that it appears we are trying very hard to
fix not the same place that is claimed to be broken.
Now, it can be that both places are broken, or that the fix can be
applied as a preventive measure - and both are fine. But arguing "we
have problem X therefore let's apply fix for a different problem Y"
sounds strange to me.I think clarifying that matter would help.
I tend to agree with all the above. Adding a code of conduct that (I
hope!) everybody universally agrees with - whether it's the current
text, or one of the ones you listed below, or some mash up - is not
going to fix the toxic and unfriendly behaviour. In my opinion, it should act
as a general set of moral guidelines.
But at the same time I think it is also important to point out that we
will actively do things, and provide a process for dealing with
compliants, if things do go wrong. A Code of Conduct (can't bear to
call to call it CoC, sorry), should show that we are serious about
having a healty and welcoming project, where we won't tolerate any sort
of abusive behaviour. I am going to have a chat with the Drupal people
to see whether we could learn from the process, and that will likely
result in an updated text of the Contributor Covent.
So on top of that, I am suggesting to accept the Collaborative
Contributing Guidelines, to address to toxidity of the list, which
nicely ties in into:
Also, there was a complaint that there has been too much critique and
not enough constructive proposals. I think there is some truth to
that, as it is much easier to find bugs than to develop things, and
much more people submit bug reports than fix them. This is natural,
but this certainly could use improvement. In that spirit, I would like
to reiterate the proposal of handling CoC matters that I personally
think would be the best. This is my personal approach, so please feel
free to amend, criticize and disagree.
- Make a values statement, along the lines of:
https://www.drupal.org/dcoc
https://www.djangoproject.com/conduct/
https://www.freebsd.org/internal/code-of-conduct.html
https://meta.wikimedia.org/wiki/Grants:Friendly_space_expectationsThis document should emphasize behaviors we want to achieve and
reinforce, not be just a catalog of behaviors we hate.In this document, as one paragraph, include "unacceptable behavior"
statement from current RFC, verbatim or suitably modified (that of
course does not preclude including other parts of it in other paragraphs).
You mean the list of "Examples of unacceptable behaviour by participants
include", right?
"Constructive Collaboration Guidelines" probably should be part of this
document too - and be stated before the unacceptable part. I know it
sound like nitpicking but I think tone of the documents is important and
if we start with negatives (even by rejecting them) it sets different
tone than if we start with positive. It's one thing to welcome people to
your house with "Welcome, friend, feel at home!" and another with
"Please don't steal my wallet and don't kick my dog!"
I agree, the positives should come first.
Create a conflict resolution team whose stated purpose is to resolve
conflicts (note: not punish or exclude!) which impact the project and
impede or disrupt the collaboration.Separately from the document above, have a conflict resolution
policy, which describes how the CRT above is elected, how it resolves
issues, what are the confidentiality guidelines, what are processes for
creating bans & appeals, etc.I know not everybody agrees, but I think it is much more beneficial to
have this in a separate document and if possible, as a separate RFC,
since discussion about it is substantially different from (1) and
partially from (2) - principal agreement on having such team is much
more important, IMO, than figuring out how long it can ban people for.That would also make discussion a bit more manageable, as discussing at
the same time two different things: do we want CoC and the particular
details of CRT behavior we want. I think separating these discussion
would allow us to emphasize things we agree on and formalize them
quickly, and hash out the details without the concern that small
disagreements would derail the whole process.
I think it's okay to have two documents about it, but I believe they
inherently tie together. Having a Conflict Resolution Team without
having a set of agreed upon values is not particularly useful. And in my
opinion, having a set of agreed upon values without the klout to do
something about is neither.
So, I am proposing to keep it in the same document, with one vote, but
discuss it separately. Starting (obviously) with your 1 and 2 from
above, and including the secrecy and transparency parts of the current
draft. And once that's finished, we move onto the Conflict Resolution
Part of your point 3.
If this looks good to anybody, I can take the time to actually arrange
the texts - though English not being my naive language, I am not the
best person for copy-writing. But I assume somebody could fix it up
afterwards :)
Hey - I wrote about asses instead of meaning "assess" ;-) [1] English
needs fixing for me too.
cheers,
Derick
Hi,
Sorry, this turned out to be longer than I wanted.
First of all, thanks for all your comments, well wishes and suggestions.
I can't possibly reply to all of them individually, but I think the main
take aways are below. I deliberately left out names.
-
Putting a document to collaborate on on GitHub was a good idea.
After the initial announcement I've put the RFC as a whole on GitHub.
I have now renamed it to
https://github.com/derickr/php-values-and-mediation as that is more
what the whole process and document is about (I'll get back to that in
a moment). Several people have fixed my English, and contributed to
some improvements already. Thanks for that! -
Language is vague and open to interpretation
-
The CoC seems to be more concern with punitive action rather than
establishing the values of the community.Starting out with a "you can't do this or we'll kick you out"
(paraphrasing) before even saying what our values is likely
deterimental to getting to a better situation. -
There is no mechanism or ability for one to confront ones accuser
That's a valid point, but a tricky one. I think it all depends on what
the consequences would be for both the accuser, and the acused. I
will seek advice from other groups that have gone through this
process. -
There has been confusion, for whatever reason, on what the outcome of
mediation regarding either the Contributor Guidelines or Code of
Conduct should be.As an example from IRC this morning, regarding removing code from an
"harasser":<Derick> IRCUser: there was never the intention to ban code from people
that behave well inside the PHP internals community. The
personal opinion of these people outside of internals have
nothing to do with this. Now, if that certain contributor
would be harassing another contributor, then that falls in
the realm of the CoC and contributing guidelines. It would
still be very unlikely that code gets removed because of that.
But I do see that nothing further would come out. Code removal
is for when people commit stuff malisciously, or against the
will of the rest of internals. -
The current text of the Code of Conduct needs improvements.
It certainly does. I believe Antony put it up as a starting point. Several
of you have suggested other such documents to look at, such as the Drupal
project, and the Django project. -
Uncertainty on where our documents should have any influence.
There is a reasonable suggestion in
https://gist.github.com/amacgregor/16c62908ff39f51604e2 but I think it
can still be improved upon. -
A judicial system must be avoided
I think it's also a valid point, but IMO I would rather phrase that as
"The use of a judicial system must be avoided". -
People have suggested to decouple the Contributor Guidelines, values
statement, and Code of Conduct from the Community Mediation Team.With the main reason that it is too much to cover in one go.
In case I missed some, sorry. There was a lot of material to go through.
I do believe there is a broad consensus that it would be beneficial that
we try to make our project a happier and more collaborate space.
I know that right now it makes people weary to contribute, and at the
same time, some of us are getting old enough that we would like our kids
to start contributing too.
Picking up on the last point first, that there is too many different
parts being discussed at once. I can relate to that :-) I would
therefore suggest the following:
-
Split out the document into several parts, and discuss each part
separately, and in sequence. Once we're happy enough with each part,
we continue to the next one. I suggest as order:-
The goal of the documents, and our general values.
Maybe we can steal a document from somewhere else as a starting
point. -
Our contributor guidelines (ie. how to behave on the mailinglists etc)
These should focus on the positive things, but also provide negative
examples of "bad behaviour". -
The Code of Conduct
A more formal document that states what we specifically are against.
This could potentially start with the original Contributor Covenant
that was initially suggested, or perhaps based on the modified
version that was circulated in this thread. -
The Mediation Team: how to deal with complaints regarding
contributor guidelines (ie. X replies to every post in a
thread, Y attacks person Z instead of debating technical points).As an initial suggestion, this team is to "slap people on the wrist"
with persistent contributor guideline violations. No powers beyond a
temporary mailinglist timeout in the uttermost extreme cases. -
The Mediation team: how to deal with complaints regarding the Code
of Conduct.As this is a more serious document, and where violation has likely
much larger consequences towards specific people a stricter
approach on possible enforcement should be considered.
-
After we covered each phase, we'll do a mini vote (to gauge agreement), and
move on to the next stage. After the Code of Conduct section, we can do a
formal "RFC" vote on first three points. And we'll do the same at the end.
I hope that many of you want to collaborate on each document, and I will be
splitting out the current RFC on GitHub into five different parts, where I will
likely remove some of the content that's currently there.
At the end, I hope we have come to a set of documents that illustrates
our values, how we want to work together and resolve conflicts, that has
the empathy of people working together, but also the klout of dealing
with serious issues in a fair manner.
cheers,
Derick
Freshly adopted:
http://rubyonrails.org/conduct/
https://golang.org/conduct
I like both with a very good special mention for the Go one for its clarity
and completeness.
Cheers,
Freshly adopted:
http://rubyonrails.org/conduct/
https://golang.org/conductI like both with a very good special mention for the Go one for its clarity
and completeness.Cheers,
This caught my eye earlier as being relevant:
http://meta.stackoverflow.com/questions/315092/why-is-being-honest-getting-penalized-these-days
and SO's policy: http://stackoverflow.com/help/be-nice
~C
Freshly adopted:
Ruby (the language) is discussing the adoption of a Code of Conduct
right now, and several people in that thread issue what I think are
similar concerns about the wording in the covenant one:
https://bugs.ruby-lang.org/issues/12004
AFAICT Rails adopted exactly that one, not sure about slight changes.
FWIW, I like the Go one a lot better.
~Florian
Freshly adopted:
Ruby (the language) is discussing the adoption of a Code of Conduct
right now, and several people in that thread issue what I think are
similar concerns about the wording in the covenant one:https://bugs.ruby-lang.org/issues/12004
AFAICT Rails adopted exactly that one, not sure about slight changes.
FWIW, I like the Go one a lot better.
I do too. I think there is a lot we can borrow from that. I'll probably
use the weekend to draft the first bit of my suggested process: THe
values document. Expect things from other "codes" to come back into it.
cheers,
Derick
I just want to reiterate what I've said a few times before. I'm leaving the
points about why I think a Code of Conduct, in general, is a bad idea until
the end, in hopes that others will at least read my other points. I don't
think there is anything "new" in what I'm saying below either - I'm pretty
sure it's all been proposed or said at one time or another by at least one
other person.
1.) I think everyone already knows how to be an adult. The fact that
sometimes we don't act in a civil manner isn't because we don't have
something telling us what civil behavior entails. Putting it in writing
might make us feel good, but it isn't going to change how anyone behaves.
Putting it in writing is necessary only if you intended to have a way to
enforce it - which requires some form of punitive measures for those that
don't, as well as a way to determine if someone violated them.
2.) Instead of focusing on what is and is not proper behavior, and how to
punish someone that doesn't follow the rules, we should focus on how we can
help out one or more individual that feels they were harmed in some way by
one or more other individual. The only initial restriction on whether we
help them out is if they are both involved in the PHP community. This means
we don't have to define what is and isn't considered "harm" nor do we have
to define where such actions must take place. This is what many of us are
talking about in reference to conflict mediation. The best thing about this
approach is it's the COMMUNITY supporting the rest of the COMMUNITY. If I
feel Paul Jones' political views are causing me emotional harm, then I can
reach out to the mediation team to help us resolve that. That's it. Doesn't
matter where he was espousing his views, and it doesn't matter that they
had nothing to do with PHP. It also doesn't require that anyone besides the
conflict mediation team, Paul, and myself be involved. The team will
obviously be able to suggest that a particular conflict might be better
handled via other means as well.
3.) Finally, I think a Code of Conduct that includes punitive measures is a
bad idea. I won't go into details on why, as we've gone over them in
detail, but I'll sum it up as follows: a Code of Conduct that gives a small
group of people the ability to punish others is open to abuse. I'm not
saying that anyone proposing such a code of conduct has evil intentions, or
even that anyone on this list would purposely act in an evil way if a
member of the committee. In fact, the reason I feel such Codes of Conduct
is dangerous is that someone acting in what they feel IS a noble way can
easily do the opposite.
Freshly adopted:
Ruby (the language) is discussing the adoption of a Code of Conduct
right now, and several people in that thread issue what I think are
similar concerns about the wording in the covenant one:https://bugs.ruby-lang.org/issues/12004
AFAICT Rails adopted exactly that one, not sure about slight changes.
FWIW, I like the Go one a lot better.
I do too. I think there is a lot we can borrow from that. I'll probably
use the weekend to draft the first bit of my suggested process: THe
values document. Expect things from other "codes" to come back into it.cheers,
Derick--
--
-- Chase
chasepeeler@gmail.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello everyone !
It's my first mail here and before writing anything else I'd like to
say that I'm thankful to Anthony and Derick for carrying this RFC.
Now… I have one issue with this argument :
Chase Peeler a écrit le 22/01/2016 19:15 :
3.) Finally, I think a Code of Conduct that includes punitive
measures is a bad idea. I won't go into details on why, as we've
gone over them in detail, but I'll sum it up as follows: a Code of
Conduct that gives a small group of people the ability to punish
others is open to abuse. I'm not saying that anyone proposing such
a code of conduct has evil intentions, or even that anyone on this
list would purposely act in an evil way if a member of the
committee. In fact, the reason I feel such Codes of Conduct is
dangerous is that someone acting in what they feel IS a noble way
can easily do the opposite.
I think it falls in the « perfect solution » fallacy. We have the
current situation, which is already open to abuse (see the repeated
references towards « the toxicity of internals ») and because such
abuses can still happen with a Code of Conduct and the team in charge
of watching its application you consider that it is a bad idea.
Furthermore, the abuses that may be perpetuated by such a team are
already limited by the « Accountability » paragraph of the RFC :
« The PHP project voting body has the right to overturn any action
taken the Community Mediation Team by vote (50% + 1 required to
overturn). »
Respectfully yours,
Alda Marteau-Hardi
XMPP: alda@leetchee.fr | Web: http://aldarone.fr/
GPG: 0xC2F8A5C7
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJWonvuAAoJEDKPoMbC+KXHeTQH/RdpxlejsT9tg3u42lrIvpQs
GiJ2nK8sTJvTfu2Mz6JGpFTwcIzFrw3h2xy8vRInuHHn8nx1mdDJL2lb1AhnlXjm
bB2rZCAjj/I6Z5+YiAehRqm2fHoye+qEu72Q4Temea8bQGwHmQZXtVG+NIbH+lU/
nFTEUfAodtDTUfowXbDj3qQGnvyLYnmH0Uzvl9oEK8AkUpAqRzKCyA88O9hBhCwy
Sy6Pqu1YC7O+7ZuTb7x5Y6FG0c9dMFMIzDsayPGhavyt95AQY/GdDqFnAZNZhQAE
73ktZTBNf9AKB/0BfJ3KbFiEP39iZiEEgOhrXa/k2aJoXzl8C7iLJh9Nli/Kh/s=
=OA7I
-----END PGP SIGNATURE
On Fri, Jan 22, 2016 at 1:59 PM Alda Marteau-Hardi <
php-internals@leetchee.fr> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256Hello everyone !
It's my first mail here and before writing anything else I'd like to
say that I'm thankful to Anthony and Derick for carrying this RFC.Now… I have one issue with this argument :
Chase Peeler a écrit le 22/01/2016 19:15 :
3.) Finally, I think a Code of Conduct that includes punitive
measures is a bad idea. I won't go into details on why, as we've
gone over them in detail, but I'll sum it up as follows: a Code of
Conduct that gives a small group of people the ability to punish
others is open to abuse. I'm not saying that anyone proposing such
a code of conduct has evil intentions, or even that anyone on this
list would purposely act in an evil way if a member of the
committee. In fact, the reason I feel such Codes of Conduct is
dangerous is that someone acting in what they feel IS a noble way
can easily do the opposite.I think it falls in the « perfect solution » fallacy. We have the
current situation, which is already open to abuse (see the repeated
references towards « the toxicity of internals ») and because such
abuses can still happen with a Code of Conduct and the team in charge
of watching its application you consider that it is a bad idea.In my opinion, an imperfect system based on freedom is much preferred to
an imperfect system based on restrictions and centralized power.
Also, I'm not saying reject the Code of Conduct outright just because it
isn't perfect. I'm arguing that a Code of Conduct that includes the ability
for a small group to impose punishment on others is WORSE than no code of
conduct at all.
Furthermore, the abuses that may be perpetuated by such a team are
already limited by the « Accountability » paragraph of the RFC :« The PHP project voting body has the right to overturn any action
taken the Community Mediation Team by vote (50% + 1 required to
overturn). »I see a few issues with that.
First, the whole idea is contradictory to the other tenants involving
privacy. The draft even points out that people might abuse the appeals
process for this reasons. I think that leaves things open to, at best, an
unfair appeals process, and at worst, appeals getting squashed in the name
of "privacy." Don't get me wrong, I believe strongly in the right to face
ones accusers, so I'm not supporting the privacy clauses, just pointing out
the contradictory nature.
Second, the whole point that trying to put some sort of judicial process in
place still holds. In relative terms, the community is small. The community
of voting members is even smaller. Bias (conscious or subconscious) against
one of the two parties involved is still likely. The chances of certain
members voting opposite of how they feel they should in order to "prevent
drama" or keep things from getting "toxic" is also a real possibility.
Respectfully yours,
Alda Marteau-Hardi
XMPP: alda@leetchee.fr | Web: http://aldarone.fr/
GPG: 0xC2F8A5C7
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2iQEcBAEBCAAGBQJWonvuAAoJEDKPoMbC+KXHeTQH/RdpxlejsT9tg3u42lrIvpQs
GiJ2nK8sTJvTfu2Mz6JGpFTwcIzFrw3h2xy8vRInuHHn8nx1mdDJL2lb1AhnlXjm
bB2rZCAjj/I6Z5+YiAehRqm2fHoye+qEu72Q4Temea8bQGwHmQZXtVG+NIbH+lU/
nFTEUfAodtDTUfowXbDj3qQGnvyLYnmH0Uzvl9oEK8AkUpAqRzKCyA88O9hBhCwy
Sy6Pqu1YC7O+7ZuTb7x5Y6FG0c9dMFMIzDsayPGhavyt95AQY/GdDqFnAZNZhQAE
73ktZTBNf9AKB/0BfJ3KbFiEP39iZiEEgOhrXa/k2aJoXzl8C7iLJh9Nli/Kh/s=
=OA7I
-----END PGP SIGNATURE-------
--
-- Chase
chasepeeler@gmail.com
Chase,
1.) I think everyone already knows how to be an adult. The fact that
sometimes we don't act in a civil manner isn't because we don't have
something telling us what civil behavior entails. Putting it in writing
might make us feel good, but it isn't going to change how anyone behaves.
Putting it in writing is necessary only if you intended to have a way to
enforce it - which requires some form of punitive measures for those that
don't, as well as a way to determine if someone violated them.
I disagree with part of your assertion here.
Having a written down statement of expected behavior is useful from the standpoint that it makes it much easier for others to point at and say, “look, you’re out of line, knock it off”.
For example: where I live, it’s local regulation that in a public park, dogs must be on leashes. (Doesn’t matter how big, or small, or how friendly, or how well-behaved, all dogs must be on leashes at all times, except where otherwise specifically allowed, such as in dog parks.) Occasionally, some people forget (or ignore, or don’t know about) that restriction (or forget they’re not in a dog park). It’s a whole lot easier to call out the misguided/accidental/bad behavior when someone can point at the posted sign and say, “hey, please leash your dog; unleashed dogs aren’t allowed here,” because then it can’t be taken only as someone complaining just to complain; instead, it’s someone pointing out an actual, written, violation of the rules, backed up by a six foot tall sign.
Having the sign also serves the purpose of reminding everyone (good and bad citizens alike) what the rules are so they can be more confident in calling out bad actors. It helps prevent or improve either of these two scenarios: “Hmm… I think dogs must be leashed… but I can’t remember? Probably shouldn’t say anything just in case I’m wrong…”, or, “wow, that’s a pretty unfriendly person and their dog. I better get the number from that sign so I can call the parks department and report them."
Putting a code of conduct, or contributor guidelines, or whatever you want to call it in writing (and regularly posting them to the mailing list as a reminder) serves exactly the same purpose as that sign at the park: gently remind everyone what the rules are; provide something clearly in writing that everyone can look at and understand; and provide contact information for questions and complaints. Written guidelines absolutely will bring about a change in how people behave: it may not immediately deter bad actors, but it will empower the neutral and good actors in bringing about censure and rehabilitation of those not acting in the public interest.
-John
Chase,
1.) I think everyone already knows how to be an adult. The fact that
sometimes we don't act in a civil manner isn't because we don't have
something telling us what civil behavior entails. Putting it in writing
might make us feel good, but it isn't going to change how anyone behaves.
Putting it in writing is necessary only if you intended to have a way to
enforce it - which requires some form of punitive measures for those that
don't, as well as a way to determine if someone violated them.I disagree with part of your assertion here.
Having a written down statement of expected behavior is useful from the
standpoint that it makes it much easier for others to point at and say,
“look, you’re out of line, knock it off”.For example: where I live, it’s local regulation that in a public park,
dogs must be on leashes. (Doesn’t matter how big, or small, or how
friendly, or how well-behaved, all dogs must be on leashes at all
times, except where otherwise specifically allowed, such as in dog parks.)
Occasionally, some people forget (or ignore, or don’t know about) that
restriction (or forget they’re not in a dog park). It’s a whole lot easier
to call out the misguided/accidental/bad behavior when someone can point at
the posted sign and say, “hey, please leash your dog; unleashed dogs aren’t
allowed here,” because then it can’t be taken only as someone complaining
just to complain; instead, it’s someone pointing out an actual, written,
violation of the rules, backed up by a six foot tall sign.Having the sign also serves the purpose of reminding everyone (good and
bad citizens alike) what the rules are so they can be more confident in
calling out bad actors. It helps prevent or improve either of these two
scenarios: “Hmm… I think dogs must be leashed… but I can’t remember?
Probably shouldn’t say anything just in case I’m wrong…”, or, “wow, that’s
a pretty unfriendly person and their dog. I better get the number from that
sign so I can call the parks department and report them."Putting a code of conduct, or contributor guidelines, or whatever you want
to call it in writing (and regularly posting them to the mailing list as
a reminder) serves exactly the same purpose as that sign at the park:
gently remind everyone what the rules are; provide something clearly in
writing that everyone can look at and understand; and provide contact
information for questions and complaints. Written guidelines absolutely
will bring about a change in how people behave: it may not immediately
deter bad actors, but it will empower the neutral and good actors in
bringing about censure and rehabilitation of those not acting in the public
interest.-John
Eh, I personally see something like leashing your dog and how to act like
a civilized human being as different. That being said, my issues aren't
with codifying how we should behave. My issues are with creation of a
judicial body with the power to impose punishment on others based on that
code.
A code of conduct implemented for the reasons you listed is fine, and
focusing on whether such a code is actually necessary distracts us from the
bigger issues: 1.) Whether or not my proposal in #2 is good or not and 2.)
the problems listed in #3.
-- Chase
chasepeeler@gmail.com
Hi,
1.) I think everyone already knows how to be an adult. The fact that
sometimes we don't act in a civil manner isn't because we don't have
something telling us what civil behavior entails. Putting it in writing
might make us feel good, but it isn't going to change how anyone behaves.
Putting it in writing is necessary only if you intended to have a way to
enforce it - which requires some form of punitive measures for those that
don't, as well as a way to determine if someone violated them.
I agree. Which is why the COC only notes actions within the scope of
the project. Just because the COC may not alter behaviour in 100% of
cases, it does not follow that the project should sit idly by and do
absolutely nothing at all. Either we're a community of humans that
will close ranks to protect a fellow community member, or we're a
collection of code emitting machines with the empathic capability of a
brick. I'm sure that's a great place for machines, but it's not so
great for humans.
2.) Instead of focusing on what is and is not proper behavior, and how to
punish someone that doesn't follow the rules, we should focus on how we can
help out one or more individual that feels they were harmed in some way by
one or more other individual. The only initial restriction on whether we
help them out is if they are both involved in the PHP community. This means
we don't have to define what is and isn't considered "harm" nor do we have
to define where such actions must take place. This is what many of us are
talking about in reference to conflict mediation. The best thing about this
That's great, but it makes no sense. If we pick any extreme issue,
like harrasment, you cannot both refuse to take action against the
offender, and also state that the victim has the community's undying
support. Those would be contrary statements. You also cannot assume
that all parties in mediation will act in good faith and make no
provision for when they don't.
This is why a COC should define harms (or alternatively, goals to
prevent the same harms), and then also define what happens when the
COC is not obeyed. Mediation is a great step that should cover 99% of
all cases with ease, but it can never ever be a long drawn out affair
without concluding. Eventually, should mediation fail, something else
needs doing for the 1% of cases that mediation cannot resolve.
Defining that "something else" is the ultimate statement that the COC
will be actively enforced, i.e. that it has teeth when teeth are
called for.
3.) Finally, I think a Code of Conduct that includes punitive measures is a
bad idea. I won't go into details on why, as we've gone over them in
detail, but I'll sum it up as follows: a Code of Conduct that gives a small
group of people the ability to punish others is open to abuse. I'm not
saying that anyone proposing such a code of conduct has evil intentions, or
even that anyone on this list would purposely act in an evil way if a
member of the committee. In fact, the reason I feel such Codes of Conduct
is dangerous is that someone acting in what they feel IS a noble way can
easily do the opposite.
The current process is open to abuse...already. Anyone at anytime is
completely free to poke Internals with an email detailing a laundry
list of charges against anyone. The absence of a defined process
doesn't mean there's no process at all. It's also important to note
that the COC makes it clear that the proposed small team has very
limited abilities, with any additional action needing to be taken to
the entire project, and can be overruled in the same manner via the
appeals mechanism. All steps are also clearly tied to the existence of
evidence. This is significantly less open to abuse that the status
quo.
Paddy
--
Pádraic Brady
Hi Derick,
Derick Rethans wrote:
Freshly adopted:
Ruby (the language) is discussing the adoption of a Code of Conduct
right now, and several people in that thread issue what I think are
similar concerns about the wording in the covenant one:https://bugs.ruby-lang.org/issues/12004
AFAICT Rails adopted exactly that one, not sure about slight changes.
FWIW, I like the Go one a lot better.
I do too. I think there is a lot we can borrow from that. I'll probably
use the weekend to draft the first bit of my suggested process: THe
values document. Expect things from other "codes" to come back into it.
The Go one looks pretty great to me. It might not be such a bad idea if
we were to adopt it almost verbatim.
I'm concerned that the code of conduct RFC, since its introduction, has
ballooned in length and complexity, and I don't think it's really done
any good. I don't like the idea of having to read pages upon pages of
regulata to know what our values and rules are.
I also don't think we need to write anything new. Other people have done
that legwork for us, we are wasting our time if we try to create
something new. PHP is not radically different from other open-source
projects.
Go's one is not excessively long, gets to the point, and is reasonable.
It appears to cover everything we need: positive values, what is
unacceptable, a statement of why moderation is needed, and how to report
issue and how it will be handled.
I'm not sure yet, but if we were to adopt a code from another project
(which I think we should definitely do), Go's looks like a good choice.
Thanks!
Andrea Faulds
https://ajf.me/
The Go one looks pretty great to me. It might not be such a bad idea
if we were to adopt it almost verbatim.I also don't think we need to write anything new. Other people have
done that legwork for us, we are wasting our time if we try to create
something new. PHP is not radically different from other open-source
projects.Go's one is not excessively long, gets to the point, and is
reasonable. It appears to cover everything we need: positive values,
what is unacceptable, a statement of why moderation is needed, and how
to report issue and how it will be handled.
The structure of the Go CoC is good.... starting with explaining why
have one, and with the positive values emphasised before it gets into
the what is unwelcome behaviour and what to do about it.... the emphasis
is still on mediation, but it looks more positive from an outsiders
perspective.
While the wording could be a bit different in places, the overall
structure promotes the benefits and I'd like to see something similar
for PHP. As one of those outsiders looking in, and occasionally
considering contributing more, seeing something like that would make me
feel a lot more comfortable about being more proactive
--
Mark Baker
|. \ -3
|J/ PHP |
|| | __ |
|| |m| |m|
I LOVE PHP
Freshly adopted:
Ruby (the language) is discussing the adoption of a Code of Conduct
right now, and several people in that thread issue what I think are
similar concerns about the wording in the covenant one:https://bugs.ruby-lang.org/issues/12004
AFAICT Rails adopted exactly that one, not sure about slight changes.
FWIW, I like the Go one a lot better.
Postgres are also working on one: 5699131D.2040805@commandprompt.com" rel="nofollow" target="_blank">http://www.postgresql.org/message-id/5699131D.2040805@commandprompt.com
David
Hi,
There was a lot of traffic over the weekend, and several of you have
provided suggestions and rewordings of several documents through
https://github.com/derickr/php-community-health
I've adopted some, I have declined some (with reasons), and I've left
some unresolved.
As I wrote in my mail on Friday, I split up the documents in the
sections:
-
The goal of the documents, and our general values.
Should already be at
https://github.com/derickr/php-community-health/blame/master/RFC.rst#L18,
but improvements welcome -
Our contributor guidelines (ie. how to behave on the mailinglists etc)
Now at
https://github.com/derickr/php-community-health/blob/master/contributor-guidelines.rst -
The Code of Conduct
I have changed the text as adopted by Davey in
https://github.com/derickr/php-community-health/issues/14
I realize this is just one change, and I do want to look better at
the Go CoC that many of you have mentioned, but that's for after we
looked at point 2. -
The Mediation Team
-
Procedures
And I added one: "6. Examples" where we can collect thought experiments
and clarification that doesn't really fit into any of the others.
Perhaps the 'Shitty' PR case study would be great in there too (please
add a PR).
But first things first.
The first document that I think we can go through quite quickly,
includes the Collaborative Contributing Guidelines that I wrote before,
and in the same document includes the Mailinglist Posting Rules and
Mailing List Rules that we already had written down:
https://github.com/derickr/php-community-health/blob/master/contributor-guidelines.rst
This documents needs editing for duplication, and perhaps we should
remove
https://github.com/derickr/php-community-health/blob/master/contributor-guidelines.rst#mailing-list-posting-guidelines
in case it's not in scope?
I am going to give it a shot later, but comments and Pull Requests are
welcome of course.
Please leave the text of the Code of Conduct for the next phase.
cheers,
Derick