Monday, January 11, 2016

[Proposed] Elephpant Etiquette

Yes, I do believe PHP internals needs a guide to etiquette. But, no, not a code of conduct. Internals is a decades (plural) old cathedral-like meritocracy. There is no benevolent dictator. There is no functional oversight group. No rigorous process (like Go has) will work in the internals ecosystem.

Anthony's draft sets the stage, but I don't think it'll draw the crowds. For that, we need a moderate approach that emphasizes the definition of acceptable behavior while limiting the authoritative scope. Here's my second attempt at a custom-fit "code of conduct" roughly based on the one from Go:

Elephpant Etiquette (v1.1)

We, the international community of PHP contributors, affirm our need to maintain cordial online collaborative spaces and do adopt this etiquette as our guide in doing so.

(I) Collaborative Spaces

Our online collaborative spaces are the nerve center of PHP evolution. We all share these spaces and are all responsible for keeping them welcoming, friendly, and focused. We define these spaces as:
  • The PHP mailing lists
  • The PHP IRC channels
  • The PHP Twitter feed
  • The PHP Facebook page
  • The PHP Github accounts and the PHP SVN documentation repositories
  • The PHP.net documentation, including comments
  • The PHP bugs and feature request database
Anyone who contributes to any of these channels is a de facto contributor.

(II) Contributors' rights and responsibilities

As a PHP contributor, you have the right to:
  • Converse in our collaborative spaces without fear of harassment
  • Present your own thoughts and ideas
  • Submit changes to PHP, its extensions, and documentation
  • Walk away of your own volition
  • Become a community moderator through the vote of other contributors
As a contributor, you also represent PHP and are responsible for:
We encourage contributors to apply this etiquette outside our collaborative spaces.

(III) Community moderation

Our collaborative spaces are moderated. Community moderators are stewards of the community's interest in collaboration. They proactively encourage collaborators to adhere to our etiquette. They provide advice and guidance to individuals and mediate dispute between contributors. They listen without judging. They keep specific details in confidence.

Community moderators exist to resolve conflicts in the most harmonious possible manner. They enjoin contributors to corrective behaviors. They can recommend censure for repeated or egregious missteps of etiquette.

To reach a moderator, email moderators@php.net.

To add or remove a moderator requires a 4/5 majority vote by the deliberative body of electors holding voting karma. Contributors without voting karma may lobby karma holders, but there is no means for direct voting. All votes for community moderators are anonymous.

To become a moderator, email moderators@php.net. In your own words, describe why you want to moderate (this your purpose statement). Include a relevant bio illustrating your diplomatic prowess. Existing community moderators will help you polish your application into an RFC and shepherd it through the voting process.

Community moderators are themselves contributors, but are expected to model the etiquette without fail. Any contributor may petition to remove a moderator. To remove a moderator, email moderators@php.net with your petition. Existing moderators will help you shape your petition into an RFC and shepherd it through the voting process.

Moderators are facilitators and shepherds. Moderators do not cull applications or petitions.

Related Posts:

  • [Proposed] Elephpant EtiquetteYes, I do believe PHP internals needs a guide to etiquette. But, no, not a code of conduct. Internals is a decades (plural) old cathedral-like meritocracy. There is no benevolent dictator. There is no functional oversight gro… Read More
  • Using vim to replace string functions with their multi-byte equivalentThe PHP INI option mbstring.func_overload override certain string functions (like strpos, substr, etc.) with multi-byte aware implementations. This makes it super easy to migrate a legacy code base to UTF-8, but immediately r… Read More
  • Wielding PHP magic with the Callable Object PatternThe PHP magic method __invoke provides a powerful way to encapsulate functionality while separating state from results and errors. I'm no warlock. I eschew the magic methods PHP offers in favor of explicit method signatures.… Read More
  • Evoking all possible test failure modes in PHPUnitWhen you're writing your own PHPUnit test listener, you need a test case that evokes all the different PHPUnit test states. Here's you go: <?php class EvokesTest extends \PHPUnit_Framework_TestCase { public function t… Read More
  • PHP Contributor EtiquetteI was the first to publically +1 the Code of Conduct RFC. I'd love to see a policy that fosters diversity and inclusion, because damn the PHP crowd is startlingly similar. But, after hearing the arguments,… Read More

0 comments:

Post a Comment

Share your thoughts!