> On Jan 6, 2016, at 13:38, Ryan Pallas <derokor...@gmail.com> wrote: > > > > On Wed, Jan 6, 2016 at 12:28 PM, Paul M. Jones <pmjone...@gmail.com> wrote: > > > On Jan 6, 2016, at 13:13, Andrea Faulds <a...@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 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
