FAQ
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

Search Discussions

  • Joe Watkins at Feb 9, 2016 at 1:04 pm
    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


    On Tue, Feb 9, 2016 at 12:33 PM, Derick Rethans wrote:

    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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Derick Rethans at Feb 9, 2016 at 2:05 pm

    On Tue, 9 Feb 2016, Joe Watkins wrote:

    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
  • Zeev Suraski at Feb 9, 2016 at 1:09 pm
    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):


    1. "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.

    2. "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..."

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

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

    5. 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
  • Derick Rethans at Feb 9, 2016 at 2:33 pm

    On Tue, 9 Feb 2016, Zeev Suraski wrote:

    1. "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.

    2. "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.
    3. 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.

    4. s/Do not post when you are angry/Try avoiding posting when you are
    angry - for similar reasons
    I'm leaving this one standing.
    5. 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
  • Lester Caine at Feb 9, 2016 at 2:48 pm

    On 09/02/16 14:33, Derick Rethans wrote:
    5. 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.
    This also gets mixed up with the 'top-posting' debate, but the fact that
    many email clients today seem to ignore the 'sig' flag and duplicate
    everything below that simple marker is more of a problem when people
    HAVE had added legal crap possibly outside their control? (My council
    clients can't remove a 430 or 40line block of 'legal') This is more a
    matter of getting client software to behave nicely than necessarily
    deliberate actions by the sender? Add mobile devices into the equation
    and the problems of quoting explode?

    Now to find what I did on the other machine to select a different sig
    for some lists :)

    --
    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
  • David Zuelke at Feb 9, 2016 at 3:23 pm

    On 09.02.2016, at 15:33, Derick Rethans wrote:
    On Tue, 9 Feb 2016, Zeev Suraski wrote:

    1. "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
  • Matt Prelude at Feb 9, 2016 at 3:34 pm
    Hi,
    On 09/02/16 15:23, David Zuelke wrote:
    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.
  • Pierre Joye at Feb 9, 2016 at 4:00 pm
    hi Zeev,
    On Tue, Feb 9, 2016 at 8:08 PM, Zeev Suraski wrote:
    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):


    1. "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.
    2. "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
  • Rowan Collins at Feb 9, 2016 at 4:29 pm

    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]
  • Matt Prelude at Feb 9, 2016 at 1:56 pm
    Hi,
    On 09/02/16 12:33, Derick Rethans wrote:
    [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:

    1. "Make sure you know what you are talking about." - ambiguous and hostile
         wording, which really isn't going to change anything.
    2. "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.
    3. "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.
  • Rowan Collins at Feb 9, 2016 at 2:33 pm

    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]
  • Lester Caine at Feb 9, 2016 at 2:55 pm

    On 09/02/16 14:32, Rowan Collins wrote:
    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
  • Rowan Collins at Feb 9, 2016 at 3:03 pm

    Lester Caine wrote on 09/02/2016 14:55:
    On 09/02/16 14:32, Rowan Collins wrote:
    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]
  • Lester Caine at Feb 9, 2016 at 3:32 pm

    On 09/02/16 15:01, Rowan Collins wrote:
    Lester Caine wrote on 09/02/2016 14:55:
    On 09/02/16 14:32, Rowan Collins wrote:
    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
  • Rowan Collins at Feb 9, 2016 at 3:43 pm

    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]
  • Matt Prelude at Feb 9, 2016 at 3:11 pm
    Hi,
    On 09/02/16 14:32, Rowan Collins wrote:
    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.
  • Rowan Collins at Feb 9, 2016 at 3:26 pm

    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]
  • Matt Prelude at Feb 9, 2016 at 3:51 pm
    Hi Rowan,
    On 09/02/16 15:24, Rowan Collins wrote:
    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.
    On 09/02/16 15:24, Rowan Collins wrote:
    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.
    On 09/02/16 15:24, Rowan Collins wrote:
    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.
  • Rowan Collins at Feb 9, 2016 at 4:24 pm

    Matt Prelude wrote on 09/02/2016 15:51:
    On 09/02/16 15:24, Rowan Collins wrote:
    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]
  • Matt Prelude at Feb 9, 2016 at 4:26 pm
    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,
  • Rowan Collins at Feb 9, 2016 at 5:44 pm

    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:

    1) the right of the accused to know *what* they are accused of, which I
    agree is fundamental
    2) 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
    3) 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]
  • Rowan Collins at Feb 9, 2016 at 6:08 pm

    Matt Prelude wrote on 09/02/2016 17:56:
    Rowan
    On 09/02/16 17:42, Rowan Collins wrote:
    Without going into point by point discussion, I think you're
    conflating several things here:

    1) the right of the accused to know *what* they are accused of, which
    I agree is fundamental
    2) 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
    3) 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.
    I'm inclined to agree with you in cases where mediation works, there's
    no need for
    the public to scritinise this, although most useful forms of private
    mediation
    would require the accuser and accused both to be 'present' at some
    kind of 'sit
    down' (via email) to attempt to diffuse the situation.
    Agreed.

    My concern is more about the rare case where all attempts fail and a
    punishment is
    on the horizon.
    Indeed. A good process should include multiple stages of resolution;
    this also helps lessen the fear of "policing" somewhat, if it is easier
    to demonstrate that authority is to be used as a last resort, not a
    routine instrument of control.

    Regards,
    --
    Rowan Collins
    [IMSoP]
  • Sammy Kaye Powers at Feb 10, 2016 at 11:01 pm
    Thanks so much for taking this up Derick! :)

    The mission points could be reworked a bit.
    * Make everybody happier, especially those responsible for developing PHP itself.
    This has a slight insinuation that non-internals/new people are
    annoying to the core PHP team. Also, what makes one happy really
    varies from person to person so this should be more specific. This
    point should be moved to the bottom of the list and read:

    "To level the expectations of everyone involved in order to reduce
    unnecessary friction and improve the overall efficiency of the PHP
    internals community".
    * Help in making sure we all use our time more efficiently.
    How about: "To create an efficient and inviting collaboration
    environment" (This should be the first point)
    * Prevent you from making a fool of yourself in public.
    This one sounds angry. :) This would be better: "To lower the learning
    curve for new potential contributors by aggregating tribal knowledge"
    * Increase the general level of goodwill on planet Earth.
    That seems a bit out of scope. :) I'd just remove this point.
    * [..] It is better to be descriptive than to be concise.
    * Write as much as is necessary, but as little as you can get away with.
    These points seem to be contradictory. Perhaps we could further
    explain these two points to disambiguate them a bit? Or perhaps merge
    them together in the same point?
    * Do not hijack threads, by bringing up entirely new topics. Please create an entirely new thread copying anything you wish to quote into the new thread.
    * Don't hijack other peoples' threads. To post on a new topic, start a new message, don't reply and just change the subject.
    These points are redundant so we should remove one of them.

    Lastly the overall tone of the document could be bit more inviting,
    especially since I can see this document being the entry point for new
    contributors getting involved. Some of the sentences read like they
    were written in frustration. I can send a PR to make it a bit softer
    in spots if people agree on this point. :)

    Great work on this so far Derick! :)

    Thanks,
    Sammy Kaye Powers
    sammyk.me
  • Rowan Collins at Feb 11, 2016 at 1:05 pm

    Sammy Kaye Powers wrote on 10/02/2016 23:01:
    Thanks so much for taking this up Derick! :)

    The mission points could be reworked a bit.
    * Make everybody happier, especially those responsible for developing PHP itself.
    This has a slight insinuation that non-internals/new people are
    annoying to the core PHP team. Also, what makes one happy really
    varies from person to person so this should be more specific. This
    point should be moved to the bottom of the list and read:

    "To level the expectations of everyone involved in order to reduce
    unnecessary friction and improve the overall efficiency of the PHP
    internals community".
    This sounds too much like a business's PR-approved Mission Statement to
    me, "leverage the synergies of our contributors to deliver value while
    maintaining ... what was I talking about again?". I take your point
    about it sounding a bit exclusionary, but no reason it can't be kept
    snappy and informal:

    * "Make us all happier when we're working together to improve PHP."

    * Help in making sure we all use our time more efficiently.
    How about: "To create an efficient and inviting collaboration
    environment" (This should be the first point)
    This seems to de-emphasise the "efficiency", and couch it in unnecessary
    formalities. I'm not sure what's wrong with the current wording.

    * Prevent you from making a fool of yourself in public.
    This one sounds angry. :) This would be better: "To lower the learning
    curve for new potential contributors by aggregating tribal knowledge"
    I think it's supposed to be jokey. Maybe the "you" could be "us" to be a
    bit more humble? ("Prevent us making fools of ourselves in public.")

    * Increase the general level of goodwill on planet Earth.
    That seems a bit out of scope. :) I'd just remove this point.
    Again, I think you're taking it too seriously. This isn't intended to
    read like a contract. I take this point to mean "we're not just telling
    you to do these things because we like making up rules, we're trying to
    make everyone happier".

    Lastly the overall tone of the document could be bit more inviting,
    especially since I can see this document being the entry point for new
    contributors getting involved.
    The changes you've suggested above seem to me to completely contradict
    this one - you've suggested extremely formal and verbose wording to
    replace punchy, jokey, points. It maybe needs a bit more "us" rather
    than "you", but ultimately, it's a bunch of dos and don'ts, so there's
    only so far it can go in placating a nervous reader.

    Regards,
    --
    Rowan Collins
    [IMSoP]
  • Pádraic Brady at Feb 10, 2016 at 11:17 pm
    Hi!
    On 9 February 2016 at 13:56, Matt Prelude wrote:
    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
  • Levi Morrison at Feb 9, 2016 at 2:10 pm

    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?
  • Derick Rethans at Feb 9, 2016 at 2:40 pm

    On Tue, 9 Feb 2016, Levi Morrison wrote:

    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
  • Derick Rethans at Feb 9, 2016 at 2:35 pm
    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
  • David Zuelke at Feb 9, 2016 at 3:17 pm
    Thanks for the work, Derick. Looks good!

    (aaand I just top-replied :p)

    On 09.02.2016, at 13:33, Derick Rethans wrote:

    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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Paul M. Jones at Feb 11, 2016 at 5:16 pm
    Hi Derick,
    On Feb 9, 2016, at 06:33, Derick Rethans wrote:

    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
  • Rowan Collins at Feb 11, 2016 at 6:39 pm

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedFeb 9, '16 at 12:33p
activeFeb 11, '16 at 6:39p
posts32
users12
websitephp.net

People

Translate

site design / logo © 2021 Grokbase