Hi Derick, > On Feb 9, 2016, at 06:33, Derick Rethans <der...@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 pmjone...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
