Re: [RFC] [Draft] Adopt Code of Conduct
| From: | Paul M. Jones | Date: | Wed, 06 Jan 2016 19:45:57 +0000 |
| Subject: | Re: [RFC] [Draft] Adopt Code of Conduct | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-90226@lists.php.net to get a copy of this message | ||
> On Jan 6, 2016, at 13:38, Ryan Pallas <derokorian@gmail.com> wrote:
>
>
>
> On Wed, Jan 6, 2016 at 12:28 PM, Paul M. Jones <pmjones88@gmail.com> wrote:
>
> > On Jan 6, 2016, at 13:13, Andrea Faulds <ajf@ajf.me> wrote:
> >
> > Furthermore, if people think the CoC enforcement team have been too heavy-handed with
> > their application of the code, the team can be replaced.
>
> Easiest way to avoid that is not to have a continuing team. Instead, randomly select of a
> response group on a per-incident basis should be sufficient. Nobody gets selected for a second
> incident until everyone has been selected once.
>
> How would I bring to attention of someone a situation, if there is no one picked to take those
> requests until after its been made?
An excellent point. My first thought is to appoint or elect a continuing "secretary"
(probably a better name for that) to receive requests, and then run the random-selection tool on
each incoming notice. The secretary position itself is not responsible for reviewing or resolving,
only receiving and assigning. This introduces some possibility of picking favored assignees to
particular responses, but even that might be automated by having a bot respond to emails to a
particular address.
Again, not in favor of a COC at all in the first place, as noted in the next quote:
>> Of course, even better than that is not to have a COC in the first place. The
>> conflict-resolution document is an infinitely better starting place.
>
> I agree, a conflict resolution document and team seems infinitely better. This team's job
> is to resolve things quietly and without further incident, however if action may be required - its
> an open vote (as previously suggested).
Right on.
--
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