Re: [VOTE] Contributor Guidelines, and Updates to Code of Conduct progress
| From: | Paul M. Jones | Date: | Thu, 11 Feb 2016 17:16:22 +0000 |
| Subject: | Re: [VOTE] Contributor Guidelines, and Updates to Code of Conduct progress | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-91210@lists.php.net to get a copy of this message | ||
Hi Derick,
> On Feb 9, 2016, at 06:33, Derick Rethans <derick@php.net> 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