[VOTE] Contributor Guidelines, and Updates to Code of Conduct progress

10 years ago by Joe Watkins — view source — reply

unread

Morning Derick,

I know you're asking about another document right now, but I still find

the language of the CoC jarring.

This: "Coercing other members to vote for a particular option on an

RFC, or to change or withdraw an RFC".

That's too vague: https://twitter.com/krakjoe/status/685368852268593152

There is surely nothing wrong with that tweet, but it seems to violate

the CoC in current form. Others have done the same kind of thing for past
RFC's.

Once again, I want to bring attention to this paragraph:

"Project maintainers have the right and responsibility to remove, edit,

or reject comments, commits, code, wiki edits, issues, and other
contributions that are not aligned to this Code of Conduct, or to ban
temporarily or permanently any contributor for other behaviours that they
deem threatening, offensive, or harmful."

That would also seem obviously too vague. It doesn't make sense to try

to limit offence, elsewhere in these documents you try to espouse the
attitude that people will disagree, and "so what". I think it better to
stick with that line of reasoning, rather than giving people the idea that
simply being offended is a thing anyone else should care about.

In addition the word harmful is missing context, and should either be

clarified or removed, with offence.

All the rest of it is good, I think ...

Cheers

Joe

Hello!

Things have quieted down around the Code of Conduct and Contributor
Guidelines process, but I have not been sitting still. In the last week,
the following things happened:

I had a call with the Drupal Community Working Group - as suggested by
Larry Garfield. Stanislav was on the call as well.

Take aways:

Texts should be void from ambiguity.

Although their CWG dealt with plenty of cases, no punitive action
has occured as parties would often step back themselves. In most
cases, a gently reminder was all that was necessary.

We should be reluctant to limit the scope of the Code of Conduct and
Contributor Guidelines.

A Code of Conduct without any 'teeth' would not be beneficial.

We should start with suggesting/nominating people for the Mediation
Team before deciding on the procedures and guidelines that
they should mediate around. The underlaying reason is that if the
team is known upfront, there ought to be more understanding for the
general developer community. Or in other words, there should be no
reason that "I would only put my friends on it".

I do however have a few people in mind that I will reach out to
privately, to see whether they are interested. If you have any
suggestions for people that you consider reliable, considerate, and
empathic, please reach out to them yourself, or let me know and I
will.

The RFC text has seen a few updates as well.

@jessamynwest improved some of the text for "encouraged behaviour"

https://github.com/derickr/php-community-health/commit/134670974b000483c2a179a02fc05a6d2de85d97

@hnrysmth imported some new phrases from the Contributor Covenant
1.4 over

https://github.com/derickr/php-community-health/commit/8ca9fe70538b036a938acbafa5f5f27f91228602

@connerbw added a more general blurb about PHP and the commitment of
the PHP team to be inclusive

https://github.com/derickr/php-community-health/commit/e6c33f4b81975f2b2f27919e37c585322f829a1c

I combined the three bits of text around mailinglist posting
guidelines into the Contributor Guidelines

https://github.com/derickr/php-community-health/commit/7c55d1dd407524cdab593b885e6b3101bf590769

I feel that the "Contributor Guidelines" are now in a reasonable shape
to do a quick poll to gauge acceptability. As this is not a formal RFC
vote, it's simply done through an online poll:
http://twtpoll.com/y6hs4ndsfiki485

Voting is non-binding, and will end at Friday February 12th, at noon
UTC.

Feel free to reply here with suggestions, comments, etc.

cheers,
Derick

10 years ago by Derick Rethans — view source — reply

unread

Morning Derick,
I know you're asking about another document right now, but I still find
the language of the CoC jarring.
This: "Coercing other members to vote for a particular option on an
RFC, or to change or withdraw an RFC".

These texts have not been reworked, so I am not going to comment on it
as it's not constructive. I'll get back to you (plural) when we get
there.

cheers,
Derick

10 years ago by Zeev Suraski — view source — reply

unread

Feel free to reply here with suggestions, comments, etc.

I think this is a pretty good start and I can stand behind most of this text. I do have a number of issues/suggestions with it though (apologies for not doing this sooner - I was swamped in the last 3 weeks with travel & out of town visits):

"Debate the technical issues, and never attack a person's opinion. People will disagree, so be it."

I think this sentence is problematic. Not that I'm pro-attacks, but opinions - as ideas - should absolutely be up for scrutiny and debate. What I think we should say instead is this:

"Debate the ideas, never attack the person holding them."

Criticizing ideas is absolutely fine, and it's healthy. Ideas can be bad even if they don't have any 'technical issues' in them. It's the personal attacks we should avoid. And of course, the criticism should be to-the-point - but the proposed text already covers that.

We can consider adding another important part of the equation - "Don't consider critique of an idea you proposed as critique of you personally." As humans, we tend to do that, and we shouldn't.

"Suggest improvements to the RFC, don't just shoot it down."

I disagree that this is a Good Thing. There are most certainly bad RFCs, that cannot be made better (typically ones that stem from bad ideas, which absolutely do exist as per the previous point). These RFCs need to be shot down. Moreover, there are cases when the person who is talented at finding holes in things isn't necessarily talented at coming up with solutions. Finding holes (negative aspects) of RFCs is an exceptionally important task, and we don't want to silence people who find issues - only because they can't think of solutions for them.

What I think we should say instead:

"When you disagree with a certain proposal, try to think whether there are changes that can be made to the RFC that will enable you to support it. If you come up with such improvements, respectfully propose them to the RFC author to try and evolve the idea into a better one. Only resort towards arguing against the RFC if you think it's a bad idea and you can think of no ways to improve it. When disagreeing..."

s/Don't use hyperbole/Try avoiding hyperbole - both because hyperbole is difficult to define, and because people respond better to asking vs. demanding.
s/Do not post when you are angry/Try avoiding posting when you are angry - for similar reasons
I think the 'max 2 lines email signature' requirement is a bit archaic. Who cares? Do we expect people to change their signature especially for internals? Not important, but if we're nitpicking :)

Note that we have a serious issue with voting process on these topics, which is probably not much of an issue for this document (for which we should be able to garner a very strong majority, I believe, and you already said you consider the vote to be non-binding) - but will definitely be an issue for any CoC. But that's something we should discuss separately.

Thanks for working on this!

Zeev

10 years ago by Derick Rethans — view source — reply

unread

"Debate the technical issues, and never attack a person's opinion.
People will disagree, so be it."

I think this sentence is problematic. Not that I'm pro-attacks, but
opinions - as ideas - should absolutely be up for scrutiny and debate.
What I think we should say instead is this:

"Debate the ideas, never attack the person holding them."

Criticizing ideas is absolutely fine, and it's healthy. Ideas can be
bad even if they don't have any 'technical issues' in them. It's the
personal attacks we should avoid. And of course, the criticism should
be to-the-point - but the proposed text already covers that.

We can consider adding another important part of the equation - "Don't
consider critique of an idea you proposed as critique of you
personally." As humans, we tend to do that, and we shouldn't.

I've changed it to:

Debate the technical issues, and ideas behind them, but never attack the
person holding them. People will disagree, so be it.

"Suggest improvements to the RFC, don't just shoot it down."

I disagree that this is a Good Thing. There are most certainly bad
RFCs, that cannot be made better (typically ones that stem from bad
ideas, which absolutely do exist as per the previous point). These
RFCs need to be shot down. Moreover, there are cases when the person
who is talented at finding holes in things isn't necessarily talented
at coming up with solutions. Finding holes (negative aspects) of RFCs
is an exceptionally important task, and we don't want to silence
people who find issues - only because they can't think of solutions
for them.

What I think we should say instead:

"When you disagree with a certain proposal, try to think whether there
are changes that can be made to the RFC that will enable you to
support it. If you come up with such improvements, respectfully
propose them to the RFC author to try and evolve the idea into a
better one. Only resort towards arguing against the RFC if you think
it's a bad idea and you can think of no ways to improve it. When
disagreeing..."

I've added this bit.

s/Don't use hyperbole/Try avoiding hyperbole - both because
hyperbole is difficult to define, and because people respond better to
asking vs. demanding.

I've updated this to:

Try to avoid hyperbole to defend your arguments.

s/Do not post when you are angry/Try avoiding posting when you are
angry - for similar reasons

I'm leaving this one standing.

I think the 'max 2 lines email signature' requirement is a bit
archaic. Who cares? Do we expect people to change their signature
especially for internals? Not important, but if we're nitpicking :)

Heh - it's always been in there ! :þ

I've changed it to:

Please configure your email client to use a real name.
Please keep message signature short. Don't add legal disclaimers.

Note that we have a serious issue with voting process on these topics,
which is probably not much of an issue for this document (for which we
should be able to garner a very strong majority, I believe, and you
already said you consider the vote to be non-binding) - but will
definitely be an issue for any CoC. But that's something we should
discuss separately.

Yeah, this twtpoll thing was a mistake too. Mostly, because you can post
multiple times, and everybody can. I have now created a wiki vote at:

https://wiki.php.net/adopt-code-of-conduct/guidelines (Will reply to
original message too)

cheers,
Derick

10 years ago by David Zuelke — view source — reply

unread

"Debate the technical issues, and never attack a person's opinion.
People will disagree, so be it."

I think this sentence is problematic. Not that I'm pro-attacks, but
opinions - as ideas - should absolutely be up for scrutiny and debate.
What I think we should say instead is this:

"Debate the ideas, never attack the person holding them."

Criticizing ideas is absolutely fine, and it's healthy. Ideas can be
bad even if they don't have any 'technical issues' in them. It's the
personal attacks we should avoid. And of course, the criticism should
be to-the-point - but the proposed text already covers that.

We can consider adding another important part of the equation - "Don't
consider critique of an idea you proposed as critique of you
personally." As humans, we tend to do that, and we shouldn't.

I've changed it to:

Debate the technical issues, and ideas behind them, but never attack the
person holding them. People will disagree, so be it.

I agree with Zeev here. It would be good to simplify this, and adding an explicit note about the inverse as well.

Something like:

"Debate issues and ideas, not the person holding them. Regardless of what side of a discussion you're on, realize that criticism of ideas or actions is distinct from criticism of a person."

David

10 years ago by Matt Prelude — view source — reply

unread

Hi,

I agree with Zeev here. It would be good to simplify this, and adding
an explicit note about the inverse as well. Something like: "Debate
issues and ideas, not the person holding them. Regardless of what side
of a discussion you're on, realize that criticism of ideas or actions
is distinct from criticism of a person." David

Just my $0.02:

https://github.com/derickr/php-community-health/pull/40

I feel like we could do with something on the other side too, suggesting
people not to act offended when people don't like their suggestions.

Matt.

10 years ago by Pierre Joye — view source — reply

unread

hi Zeev,

Feel free to reply here with suggestions, comments, etc.

I think this is a pretty good start and I can stand behind most of this text. I do have a number of issues/suggestions with it though (apologies for not doing this sooner - I was swamped in the last 3 weeks with travel & out of town visits):

"Debate the technical issues, and never attack a person's opinion. People will disagree, so be it."

I think this sentence is problematic. Not that I'm pro-attacks, but opinions - as ideas - should absolutely be up for scrutiny and debate. What I think we should say instead is this:

"Debate the ideas, never attack the person holding them."

Criticizing ideas is absolutely fine, and it's healthy. Ideas can be bad even if they don't have any 'technical issues' in them. It's the personal attacks we should avoid. And of course, the criticism should be to-the-point - but the proposed text already covers that.

We can consider adding another important part of the equation - "Don't consider critique of an idea you proposed as critique of you personally." As humans, we tend to do that, and we shouldn't.

I cannot agree more with you here.

"Suggest improvements to the RFC, don't just shoot it down."

I disagree that this is a Good Thing. There are most certainly bad RFCs, that cannot be made better (typically ones that stem from bad ideas, which absolutely do exist as per the previous point). These RFCs need to be shot down.

However this is very very disturbing. While you smooth it a little bit
later, this sounds to me like something I would really prefer not to
see. It is not necessary related to what can be covered by these
documents but a recent past shows me that the "shot down" part is more
than detestable.

It is perfectly fine to consider a RFC as bad and state it openly (as
in on the mailing list). But there is a clear line that should never
be crossed when it comes to "shoot down" a RFC or an idea. This line
has been crossed a few times (64bit patches or the STH RFC for
example). And this is something I like to be covered to some extend.

I am not against private discussions, by any mean, if they are
fundamentally technical or goes in a friendly manner to try to get a
1-1 in-depth discussion. But some of these private discussions were
more about putting unacceptable pressure to request the authors to
cancel their proposals. This is in my opinion not acceptable, not even
remotely acceptable and it has to stop. It is even more critical when
these pressures are applied by well known leaders. We can disagree on
ideas, even define them as very bad, but if we do it privately to
avoid public backlogs of what is being said (for obvious or less
obvious reasons) then it became a serious problem.

Moreover, there are cases when the person who is talented at finding holes in things isn't necessarily talented at coming up with solutions. Finding holes (negative aspects) of RFCs is an exceptionally important task, and we don't want to silence people who find issues - only because they can't think of solutions for them.

Yes that's why the discussion period exists.

Also one problem we have now with the RFCs is feedback not being taken
into account because it does not match the author ideas. It forces
competitive RFCs for the exact same subject instead of having
different proposals grouped in one and accepted/rejected. It also
prevents other ideas, maybe better ideas, to get in because many
simply do not want to go through the pain of creating competitive
RFCs.

What I think we should say instead:

"When you disagree with a certain proposal, try to think whether there are changes that can be made to the RFC that will enable you to support it. If you come up with such improvements, respectfully propose them to the RFC author to try and evolve the idea into a better one. Only resort towards arguing against the RFC if you think it's a bad idea and you can think of no ways to improve it. When disagreeing..."

With the hope that "propose them to the RFC author to try and evolve
the idea into a better one", even as options to the given RFC, get
accepted, but it is sadly very rarely the case.

Thanks,

Pierre

@pierrejoye | http://www.libgd.org

10 years ago by Rowan Collins — view source — reply

unread

Pierre Joye wrote on 09/02/2016 16:00:

Also one problem we have now with the RFCs is feedback not being taken
into account because it does not match the author ideas.

In a previous discussion, I backed the idea of encouraging all RFCs to
have multiple authorship. The idea that an RFC "belongs" to a single
sponsor can lead to defensive / competitive solutions, rather than
collaborative ones. The RFCs are hosted on a wiki, a platform literally
invented to foster ad hoc collaboration; they should be drafted,
re-drafted, edited, and re-shaped.

This could actually form part of the guidelines: "Do not treat an RFC as
your personal property to be defended against the community; rather,
treat it as an offering of effort which the community will help you
shape". (I haven't spent long thinking about that wording - feel free to
improve it.)

Regards,

Rowan Collins
[IMSoP]

10 years ago by Matt Prelude — view source — reply

unread

Hi,

[snip]

Texts should be void from ambiguity.
I couldn't agree more. Ambiguity has a chilling effect on speech, and will
damage the quality of discourse on internals.

Having said that, I think that the CoC being proposed is too wordy, and
still
quite ambiguous, some examples of statements I think are problematic:

"Make sure you know what you are talking about." - ambiguous and hostile
wording, which really isn't going to change anything.
"It is better to be descriptive than to be concise" is in clear conflict
with "Write ... as little as you can get away with" and both address the
same point.
"never attack a person's opinion" - challenging opinions is very
important
in technical discussion.

I will submit a pull request later with some suggested amendments to improve
clarity and remove duplicates.

Although their CWG dealt with plenty of cases, no punitive action
has occured as parties would often step back themselves. In most
cases, a gently reminder was all that was necessary.

A Code of Conduct without any 'teeth' would not be beneficial.
These statements appear to be in direct conflict with each other.

If the Drupal CWG have not needed to impose punishments as a result of
their
CoC, and in the history of Internals you could count the bans on one hand,
then I really don't see why we need to go to the lengths of establishing
committees and punishment procedures.

I feel that the CoC has a much greater chance of achieving consensus if
we don't
try to impose a 'court of law' alongside it, especially considering that
most
proposals for a 'court' have been secretive and focused on privacy
rather than
on transparency (the opposite of all well-functioning legal systems).

We should be reluctant to limit the scope of the Code of Conduct and
Contributor Guidelines.
This is an ambiguous statement, do you mean scope of enforcement (i.e.
spaces
outside of PHP technical spaces) or something else? Would you mind
clarifying and
also providing a brief summary of what lead to this conclusion?

Again, I think that the CoC has a much greater chance of achieving
consensus if we
aren't trying to use it to police behavior outside of our spaces.

I feel that the "Contributor Guidelines" are now in a reasonable shape
to do a quick poll to gauge acceptability. As this is not a formal RFC
vote, it's simply done through an online poll:
http://twtpoll.com/y6hs4ndsfiki485
I've submitted a vote, not sure if I should as I don't have karma to
vote on RFCs.

I think this is a lot better (and more technically-focused) than the
Contributer
Covenant, so it's a step in the right direction, but I still think it
needs some
refining to be 'production-ready'.

Matt Prelude.

10 years ago by Rowan Collins — view source — reply

unread

Matt Prelude wrote on 09/02/2016 13:56:

If the Drupal CWG have not needed to impose punishments as a result of
their
CoC, and in the history of Internals you could count the bans on one
hand,
then I really don't see why we need to go to the lengths of establishing
committees and punishment procedures.

Having procedures for violation and not using them could still have
value. The most famous example of this is surely nuclear weapons, which
are frequently cited as a deterrent, not intended for actual use.

A less violent example in the UK would be the phrase which came up when
arranging a coalition government, "avoid embarrassing the Queen" - the
Queen has the constitutional right to appoint a Prime Minister, but
forcing her to do so would be a major failing of the normal processes.
Her constitutional value lies, paradoxically, in her not exercising any
of her constitutional powers, because it forces people to negotiate a
solution which doesn't require them.

In the context of a CoC, having some escalation procedures for if people
refuse to compromise sharpens the minds of those involved - they can't
just half-heartedly reply to a complaint and carry on as they were, but
have to at least engage with the issue raised. Thinking about it, the
same happens in many civil court cases - nobody would agree to an "out
of court settlement" if there was no court case to be avoided.

So insisting on having "teeth", but assuring people that they will
probably never be used, is a justifiable position, not a contradiction.

Regards,

Rowan Collins
[IMSoP]

10 years ago by Lester Caine — view source — reply

unread

nobody would agree to an "out of court settlement" if there was no court
case to be avoided.
That one is probably a bad example. How many cases are settled simply to
avoid exorbitant legal costs? Being right has nothing to do with the
results, or 'no admission of guilt' when it could help everybody if the
facts were established.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

10 years ago by Rowan Collins — view source — reply

unread

Lester Caine wrote on 09/02/2016 14:55:

nobody would agree to an "out of court settlement" if there was no court
case to be avoided.
That one is probably a bad example. How many cases are settled simply to
avoid exorbitant legal costs? Being right has nothing to do with the
results, or 'no admission of guilt' when it could help everybody if the
facts were established.

My e-mail originally began with a disclaimer that I wasn't 100% sure of
the validity of the idea, but I edited it out for brevity.

Each of the examples I gave could be challenged in their practical
details, but my point was merely that they at least have some logical
basis, and are not inherently self-contradictory.

Regards,

Rowan Collins
[IMSoP]

10 years ago by Lester Caine — view source — reply

unread

Lester Caine wrote on 09/02/2016 14:55:

nobody would agree to an "out of court settlement" if there was no court
case to be avoided.
That one is probably a bad example. How many cases are settled simply to
avoid exorbitant legal costs? Being right has nothing to do with the
results, or 'no admission of guilt' when it could help everybody if the
facts were established.

My e-mail originally began with a disclaimer that I wasn't 100% sure of
the validity of the idea, but I edited it out for brevity.

Each of the examples I gave could be challenged in their practical
details, but my point was merely that they at least have some logical
basis, and are not inherently self-contradictory.

In the context of policing CoC 'infringements' then a threat of some
action should be enough to defuse the situation. There is no need to
'settle out of court', but my point was more one of the feeling these
days that "out of court settlement" is little to do with what is right
and more to do with what costs less without actually solving the
problem. The aim of any 'stick' should be to get at the truth rather
than pressure one party to settle for the others opinion ... with the
right amount of lubrication :( In an open source environment there is
very little lubrication available ...

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

10 years ago by Rowan Collins — view source — reply

unread

Lester Caine wrote on 09/02/2016 15:31:

In the context of policing CoC 'infringements' then a threat of some
action should be enough to defuse the situation.

Agreed.

There is no need to
'settle out of court', but my point was more one of the feeling these
days that "out of court settlement" is little to do with what is right
and more to do with what costs less without actually solving the
problem. The aim of any 'stick' should be to get at the truth rather
than pressure one party to settle for the others opinion ...

A fair point. If the process is perceived as biased, or intimidating for
one side or the other, it would have a chilling effect rather than a
calming one. In my mind, that makes defining due process even more
important, to reassure everyone that the intimidation is not intended.

Regards,

Rowan Collins
[IMSoP]

10 years ago by Matt Prelude — view source — reply

unread

Hi,

Having procedures for violation and not using them could still have
value. The most famous example of this is surely nuclear weapons,
which are frequently cited as a deterrent, not intended for actual use.

A less violent example in the UK would be the phrase which came up
when arranging a coalition government, "avoid embarrassing the Queen"

the Queen has the constitutional right to appoint a Prime Minister,
but forcing her to do so would be a major failing of the normal
processes. Her constitutional value lies, paradoxically, in her not
exercising any of her constitutional powers, because it forces people
to negotiate a solution which doesn't require them.

In the context of a CoC, having some escalation procedures for if
people refuse to compromise sharpens the minds of those involved -
they can't just half-heartedly reply to a complaint and carry on as
they were, but have to at least engage with the issue raised. Thinking
about it, the same happens in many civil court cases - nobody would
agree to an "out of court settlement" if there was no court case to be
avoided.

So insisting on having "teeth", but assuring people that they will
probably never be used, is a justifiable position, not a contradiction.

Regards,
Taking your nuclear weapons analogy a little further, we are now (as a
world) very concerned about making sure that the wrong people do not get
access to nuclear weapons. Whilst we cannot go back and un-invent the
nuclear weapon, we can avoid creating a punitive process which we have
to 'play politics' around to try to keep it under control.

I don't object to the idea that people who are clearly being
unconstructive can be blocked from the project. What I object to is
the proposal to make this an opaque 'secret court' where a few 'judges'
have the ability to make secret decisions based on secret reports and
secret evidence.

The community has always had the means to remove people from the process
which has, to my knowledge, been invoked in the past a small number of
times. Therefore, we already have the 'teeth' to enforce the CoC in
borderline cases, but what's being proposed is an inexplicable move from
visible and transparent 'teeth' to an opaque and closed process.

In case I was getting this all wrong, I made a pull request to remove
this secrecy from the process, which was promptly closed:

https://github.com/derickr/php-community-health/pull/37

I'd suggest that we stick with the teeth we already have, rather than
creating a new set based on an issue which has occurred a couple of times
in a decade, and always been adequately resolved.

Matt.

10 years ago by Rowan Collins — view source — reply

unread

Matt Prelude wrote on 09/02/2016 15:11:

Taking your nuclear weapons analogy a little further, we are now (as a
world) very concerned about making sure that the wrong people do not get
access to nuclear weapons. Whilst we cannot go back and un-invent the
nuclear weapon, we can avoid creating a punitive process which we have
to 'play politics' around to try to keep it under control.

As I said in my reply to Lester, my post was not intended to say "see,
it works really well for nuclear arms races, it must be a good thing",
but to reply specifically to a point you had made, namely that two
statements were "in direct conflict with each other". Whether or not it
is a Good Thing, having a process which is defined but never applied is
not a contradiction.

I don't object to the idea that people who are clearly being
unconstructive can be blocked from the project. What I object to is
the proposal to make this an opaque 'secret court' where a few 'judges'
have the ability to make secret decisions based on secret reports and
secret evidence.

Here, you are moving from principles to details. The principle Derick
has said so far is that there should be some process defined. That is all.

I'd suggest that we stick with the teeth we already have, rather than
creating a new set based on an issue which has occurred a couple of times
in a decade, and always been adequately resolved.

That's fine, and can be looked at when we get onto the details. The
final draft could simply state in words the status quo, so that everyone
is aware that that is where the authority lies.

That said, I am not convinced either
a) that the current process has any guarantee of transparency - who
exactly has the right to block people from the list, or revoke other
karma? what transparent process are they obliged to follow when doing so?
or b) that the current draft entail a "secret court" - the wording you
filed a PR to remove talks only about anonymity of witnesses (which,
admittedly, includes "accusers"), and makes no mention of "secret
decisions based on secret reports and secret evidence"

Again, this is jumping ahead to the details of the implementation, which
Derrick has said will be discussed at a later date.

The principle at discussion right now, is that on the face of it, there
should be some definition of enforcement mechanism. If you consider the
status quo to include such an enforcement mechanism, and do not wish to
remove it, then you agree with that general principle.

Regards,

Rowan Collins
[IMSoP]

10 years ago by Matt Prelude — view source — reply

unread

Hi Rowan,

That said, I am not convinced either
a) that the current process has any guarantee of transparency - who
exactly has the right to block people from the list, or revoke other
karma? what transparent process are they obliged to follow when doing so?

Here, we agree.

Nowhere in the documents does it limit the extent to which evidence can be
truncated or redacted in the name of 'privacy'.

Nowhere in the documents does it guarantee the accused a right to face the
evidence which has been brought against him/her.

Nowhere in the documents does it specify a standard of evidence, or explain
legitimate defences against accusations.

or b) that the current draft entail a "secret court" - the wording you
filed a PR to remove talks only about anonymity of witnesses (which,
admittedly, includes "accusers"), and makes no mention of "secret
decisions based on secret reports and secret evidence"

These speculations are from the prior discussion of the RFC when it was
proposed by Anthony. The Contributor Covenant (which is the basis of the
Code of Conduct document) is designed to protect the identity of the
accuser, rather than the right of the accused to face the evidence against
him/her. I see these priorities as backwards.

The current wording of the 'Code of Conduct' contains the following text:

"Maintainers are obligated to maintain confidentiality with regard to both
the reporter of an incident, and the accused, and expect all parties to
assist in ensuring this."

In addition, the 'Mediation' document contains the following:

"Reasonable efforts should be taken to ensure the privacy of the reporting
party. The only two exceptions are if the incident was public or if the
reporting party agrees to be identified."

In common law (probably the most functional legal system on the planet), a
core right of the accused is to 'face his accuser', i.e. to see exactly
what he is being accused of and by whom. I would be very reluctant to
support any process which does not respect this core legal right.

Without the right to face the accuser, the accusation, or a guarantee that
all supporting AND contradictory evidence and testimony will be published,
this is a 'secret court' proposal.

Again, this is jumping ahead to the details of the implementation,
which Derrick has said will be discussed at a later date.

The principle at discussion right now, is that on the face of it,
there should be some definition of enforcement mechanism. If you
consider the status quo to include such an enforcement mechanism, and
do not wish to remove it, then you agree with that general principle.

With respect, I don't think that disagreeing that there is any need for a
new enforcement process is 'agreeing with' the new RFC.

Matt.

10 years ago by Rowan Collins — view source — reply

unread

Matt Prelude wrote on 09/02/2016 15:51:

That said, I am not convinced either
a) that the current process has any guarantee of transparency - who
exactly has the right to block people from the list, or revoke other
karma? what transparent process are they obliged to follow when doing
so?

Here, we agree.

Nowhere in the documents ...

We're talking cross-purposes here. By "current process", I don't mean
the current draft document, I mean your claim that "we already have the
'teeth' to enforce the CoC in borderline cases" - i.e. that there is
already some process, which the proposed document would replace.

With respect, I don't think that disagreeing that there is any need for a
new enforcement process is 'agreeing with' the new RFC.

This thread is not about agreeing with the full Code of Conduct, only
the top-level guidelines here:
https://wiki.php.net/adopt-code-of-conduct/guidelines

While not quite a straw man, the details you are looking into here are
not the current focus of attention.

So, rather than putting words in your mouth, I will ask the question
directly: you say above that you do not agree that there is a need for a
new enforcement process, but do you agree that there is a need for the
old enforcement process to be recognised as such?

Regards,

Rowan Collins
[IMSoP]

10 years ago by Matt Prelude — view source — reply

unread

Hi,

So, rather than putting words in your mouth, I will ask the question
directly: you say above that you do not agree that there is a need for
a new enforcement process, but do you agree that there is a need for
the old enforcement process to be recognised as such?

Yes, have no issue with codifying the process as long as it remains
public & transparent.

Regards,

10 years ago by Rowan Collins — view source — reply

unread

Matt Prelude wrote on 09/02/2016 15:51:

Without the right to face the accuser, the accusation, or a guarantee
that
all supporting AND contradictory evidence and testimony will be
published,
this is a 'secret court' proposal.

Without going into point by point discussion, I think you're conflating
several things here:

the right of the accused to know what they are accused of, which I
agree is fundamental
the right of the accused to know who is doing the accusing, which
may be implied by (1), but may also be in conflict with other rights the
accuser holds, and have to be balanced against them
the right of the public to scrutinise the entire process, including
all submissions by both parties

In particular, private mediation between two parties - granting (1) and
(2), but withholding (3) - is sometimes the most constructive approach,
at least until that mediation breaks down.

Regards,

Rowan Collins
[IMSoP]

10 years ago by padraic.brady@gmail.com — view source — reply

unread

Hi!

I feel that the CoC has a much greater chance of achieving consensus if we
don't
try to impose a 'court of law' alongside it, especially considering that
most
proposals for a 'court' have been secretive and focused on privacy rather
than
on transparency (the opposite of all well-functioning legal systems).

Just to provide a counterpoint to one argument herein - the focus on
privacy is literally transcribed into law for employee->employer
relationships throughout a lot of EU law. I can't comment on any other
laws. There's a certain collision of opinions as to whether the COC
for an open source project must perfectly emulate a legal system or a
project->participant (employer->employee style) system of discipline.
The latter is obviously more accurate in terms of describing the
nature of an open source project. Indeed, many of us are already in
this scenario beyond the walls of this project.

On that basis, the actual legal recommendation under my local laws
(for whatever they're worth) is NOT to open disciplinary procedures to
public examination, insofar as it can be realistically avoided.
Indeed, publicly stating conclusions as fact is likely a potential
landmine. The RFC calls for certain amounts of publicity as a
requirement to apply the most extreme of punishments only.

The "court of law" argument regularly stated in the wild is simply
non-applicable here. It's aspirational, which is to the good, but not
a legal requirement in any nation that I've ever heard of. Quite the
opposite! The PHP project is NOT a court. It SHOULD be focused on
privacy and confidentiality. Taken to complete extremes, not being
private and preserving confidentiality (particularly of the potential
victim) would actually open an employer to liability when taken to a
real court because they've utterly failed at that point to implement
an effective policy leaving them culpable.

I am not a lawyer of course - so chuck a couple of handfuls of salt
around ;). I do think it's an accurate assessment of where a COC
should go to remain on a safe course for all concerned.

Paddy

10 years ago by Levi Morrison — view source — reply

unread

Voting is non-binding, and will end at Friday February 12th, at noon
UTC.

What does this mean in this context? We're voting but nothing will
actually change?

10 years ago by Derick Rethans — view source — reply

unread

Voting is non-binding, and will end at Friday February 12th, at noon
UTC.

What does this mean in this context? We're voting but nothing will
actually change?

Just want to see how close this text is to being done, so that we can
move over to the code of conduct text as outlined in the process I wrote
about at http://news.php.net/php.internals/90828

cheers,
Derick

10 years ago by Derick Rethans — view source — reply

unread

Hi,

I feel that the "Contributor Guidelines" are now in a reasonable shape
to do a quick poll to gauge acceptability. As this is not a formal RFC
vote, it's simply done through an online poll:

<snip>

note - the voting thing is now on the WIKI at:
https://wiki.php.net/adopt-code-of-conduct/guidelines

cheers,
Derick

10 years ago by David Zuelke — view source — reply

unread

Thanks for the work, Derick. Looks good!

(aaand I just top-replied :p)

Hello!

Things have quieted down around the Code of Conduct and Contributor
Guidelines process, but I have not been sitting still. In the last week,
the following things happened:

I had a call with the Drupal Community Working Group - as suggested by
Larry Garfield. Stanislav was on the call as well.

Take aways:

Texts should be void from ambiguity.

Although their CWG dealt with plenty of cases, no punitive action
has occured as parties would often step back themselves. In most
cases, a gently reminder was all that was necessary.

We should be reluctant to limit the scope of the Code of Conduct and
Contributor Guidelines.

A Code of Conduct without any 'teeth' would not be beneficial.

We should start with suggesting/nominating people for the Mediation
Team before deciding on the procedures and guidelines that
they should mediate around. The underlaying reason is that if the
team is known upfront, there ought to be more understanding for the
general developer community. Or in other words, there should be no
reason that "I would only put my friends on it".

I do however have a few people in mind that I will reach out to
privately, to see whether they are interested. If you have any
suggestions for people that you consider reliable, considerate, and
empathic, please reach out to them yourself, or let me know and I
will.

The RFC text has seen a few updates as well.

@jessamynwest improved some of the text for "encouraged behaviour"
https://github.com/derickr/php-community-health/commit/134670974b000483c2a179a02fc05a6d2de85d97

@hnrysmth imported some new phrases from the Contributor Covenant
1.4 over
https://github.com/derickr/php-community-health/commit/8ca9fe70538b036a938acbafa5f5f27f91228602

@connerbw added a more general blurb about PHP and the commitment of
the PHP team to be inclusive
https://github.com/derickr/php-community-health/commit/e6c33f4b81975f2b2f27919e37c585322f829a1c

I combined the three bits of text around mailinglist posting
guidelines into the Contributor Guidelines
https://github.com/derickr/php-community-health/commit/7c55d1dd407524cdab593b885e6b3101bf590769

I feel that the "Contributor Guidelines" are now in a reasonable shape
to do a quick poll to gauge acceptability. As this is not a formal RFC
vote, it's simply done through an online poll:
http://twtpoll.com/y6hs4ndsfiki485

Voting is non-binding, and will end at Friday February 12th, at noon
UTC.

Feel free to reply here with suggestions, comments, etc.

cheers,
Derick

10 years ago by Paul M. Jones — view source — reply

unread

Hi Derick,

Hello!

Things have quieted down around the Code of Conduct and Contributor
Guidelines process

For my part, at least, things are in "hibernation" until the wiki is updated with the new draft. Meanwhile:

I had a call with the Drupal Community Working Group - as suggested by
Larry Garfield. Stanislav was on the call as well.

Is there a transcript or recording of the call? I'm very interested to know what transpired.

We should be reluctant to limit the scope of the Code of Conduct and
Contributor Guidelines.

What is the reasoning behind this?

A Code of Conduct without any 'teeth' would not be beneficial.

Why was that?

We should start with suggesting/nominating people for the Mediation
Team before deciding on the procedures and guidelines that
they should mediate around. The underlaying reason is that if the
team is known upfront, there ought to be more understanding for the
general developer community. Or in other words, there should be no
reason that "I would only put my friends on it".

I think that presumes the people making up the Team will be present for all time thereafter, and never replaced. Indeed, it reinforces the idea that the political persuasions of the Team members will be the determiner of how the Code is enforced, if one is ever adopted. Since we cannot know in advance who will be in place after the first Team, I opine the rules should not be Team-member-dependent.

I do however have a few people in mind that I will reach out to
privately, to see whether they are interested. If you have any
suggestions for people that you consider reliable, considerate, and
empathic, please reach out to them yourself, or let me know and I
will.

I'm reliable, considerate, and empathic toward accused persons. Does that count?

I combined the three bits of text around mailinglist posting
guidelines into the Contributor Guidelines
https://github.com/derickr/php-community-health/commit/7c55d1dd407524cdab593b885e6b3101bf590769

I feel that the "Contributor Guidelines" are now in a reasonable shape
to do a quick poll to gauge acceptability. As this is not a formal RFC
vote, it's simply done through an online poll:

(The poll was later moved to the wiki at https://wiki.php.net/adopt-code-of-conduct/guidelines.)

While the narrative itself is rather generic, there are several problems with the Guidelines. Others have mentioned some of them in various replies to this thread.

For me, the biggest problem is that the Guidelines presume that every RFC can be made into something useful and/or desirable. There is no allowance made for declining an RFC as unworkable or unacceptable from the beginning, politely or otherwise; for example, something that is against the "vision" (however interpreted) of PHP in the first place. Some things are best rejected out-of-hand at their beginning. Some may not see that as "constructive"; but then, what is "constructive" depends on what you construct. Derick, can you imagine there might ever be a time when an RFC should be turned down on its face? If so, in which cases do you think that would apply? If not, why not?

Second, the Guidelines lack definitions. They say, "Debate the technical issues, and ideas behind them, but never attack the person holding them." Derick, what does "attack" mean in this context? In lieu of a definition, do we have an actual example from PHP-Internals that shows an "attack" in that sense? If there is, it should be linked. If there is not, then why do we think "attacks" of this kind are a problem to be addressed?

Finally, these are Guidelines, but for whom? Is their violation actionable? If so, by whom, and in what circumstances? If not, then the Guidelines should say so.

I have other issues, but those will do for now.

--
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

10 years ago by Rowan Collins — view source — reply

unread

Paul M. Jones wrote on 11/02/2016 17:16:

Finally, these are Guidelines, but for whom? Is their violation actionable? If so, by whom, and in what circumstances? If not, then the Guidelines should say so.

My understanding (admittedly I've only skim-read the text) was that this
document was advisory, not enforced - it's the general goals that a full
Code of Conduct would define in excruciating detail. But yes, that
should be made explicit, with reference to the Code of Conduct as the
full rules and procedures (should such a Code be agreed).

[VOTE] Contributor Guidelines, and Updates to Code of Conduct progress View as Markdown

Thanks,

Regards,

Regards,

-- Lester Caine - G8HFL

Regards,

-- Lester Caine - G8HFL

Regards,

Regards,

Regards,

Regards,

Regards,

Regards,

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL