Re: [RFC] [Draft] Adopt Code of Conduct

From: 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

« previous php.internals (#90226) next »