# [VOTE] Contributor Guidelines, and Updates to Code of Conduct progress - Thread: https://externals.io/message/91143 - Original archive: https://news-web.php.net/php.internals/91143 - Started by Derick Rethans on 2016-02-09T12:33:48+00:00 - Messages: 31 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/91143.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #91143 — Derick Rethans — 2016-02-09T12:33:48+00:00 URL: https://externals.io/message/91143#91143 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 --- ## #91144 — Joe Watkins — 2016-02-09T13:04:45+00:00 URL: https://externals.io/message/91143#91144 · In reply to: #91143 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 --- ## #91145 — Zeev Suraski — 2016-02-09T13:08:58+00:00 URL: https://externals.io/message/91143#91145 · In reply to: #91143 > 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 --- ## #91146 — Matt Prelude — 2016-02-09T13:56:27+00:00 URL: https://externals.io/message/91143#91146 · In reply to: #91143 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: 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. --- ## #91147 — Derick Rethans — 2016-02-09T14:05:07+00:00 URL: https://externals.io/message/91143#91147 · In reply to: #91144 > 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 --- ## #91148 — Levi Morrison — 2016-02-09T14:10:33+00:00 URL: https://externals.io/message/91143#91148 · In reply to: #91143 > 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? --- ## #91150 — Rowan Collins — 2016-02-09T14:32:05+00:00 URL: https://externals.io/message/91143#91150 · In reply to: #91146 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] --- ## #91149 — Derick Rethans — 2016-02-09T14:33:10+00:00 URL: https://externals.io/message/91143#91149 · In reply to: #91145 > 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 --- ## #91151 — Derick Rethans — 2016-02-09T14:35:09+00:00 URL: https://externals.io/message/91143#91151 · In reply to: #91143 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: note - the voting thing is now on the WIKI at: https://wiki.php.net/adopt-code-of-conduct/guidelines cheers, Derick --- ## #91152 — Derick Rethans — 2016-02-09T14:40:47+00:00 URL: https://externals.io/message/91143#91152 · In reply to: #91148 > > […] > > 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 --- ## #91155 — Lester Caine — 2016-02-09T14:55:29+00:00 URL: https://externals.io/message/91143#91155 · In reply to: #91150 > 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 --- ## #91156 — Rowan Collins — 2016-02-09T15:01:51+00:00 URL: https://externals.io/message/91143#91156 · In reply to: #91155 Lester Caine wrote on 09/02/2016 14:55: > > > […] > 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] --- ## #91157 — Matt Prelude — 2016-02-09T15:11:49+00:00 URL: https://externals.io/message/91143#91157 · In reply to: #91150 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. --- ## #91158 — David Zuelke — 2016-02-09T15:17:09+00:00 URL: https://externals.io/message/91143#91158 · In reply to: #91143 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 --- ## #91159 — David Zuelke — 2016-02-09T15:23:06+00:00 URL: https://externals.io/message/91143#91159 · In reply to: #91149 > > > > > […] > > 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 --- ## #91160 — Rowan Collins — 2016-02-09T15:24:42+00:00 URL: https://externals.io/message/91143#91160 · In reply to: #91157 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] --- ## #91162 — Lester Caine — 2016-02-09T15:31:55+00:00 URL: https://externals.io/message/91143#91162 · In reply to: #91156 > Lester Caine wrote on 09/02/2016 14:55: > > […] > > 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 --- ## #91163 — Matt Prelude — 2016-02-09T15:34:34+00:00 URL: https://externals.io/message/91143#91163 · In reply to: #91159 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. --- ## #91166 — Rowan Collins — 2016-02-09T15:42:24+00:00 URL: https://externals.io/message/91143#91166 · In reply to: #91162 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] --- ## #91168 — Matt Prelude — 2016-02-09T15:51:06+00:00 URL: https://externals.io/message/91143#91168 · In reply to: #91160 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. --- ## #91170 — Pierre Joye — 2016-02-09T16:00:00+00:00 URL: https://externals.io/message/91143#91170 · In reply to: #91145 hi Zeev, > > […] > > 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 --- ## #91171 — Rowan Collins — 2016-02-09T16:22:47+00:00 URL: https://externals.io/message/91143#91171 · In reply to: #91168 Matt Prelude wrote on 09/02/2016 15:51: > > > […] > > 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] --- ## #91172 — Matt Prelude — 2016-02-09T16:26:06+00:00 URL: https://externals.io/message/91143#91172 · In reply to: #91171 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, --- ## #91173 — Rowan Collins — 2016-02-09T16:28:19+00:00 URL: https://externals.io/message/91143#91173 · In reply to: #91170 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] --- ## #91176 — Rowan Collins — 2016-02-09T17:42:52+00:00 URL: https://externals.io/message/91143#91176 · In reply to: #91168 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] --- Next page: https://externals.io/message/91143.md?page=2