Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:90515 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 72011 invoked from network); 11 Jan 2016 19:18:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Jan 2016 19:18:08 -0000 Authentication-Results: pb1.pair.com smtp.mail=chasepeeler@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=chasepeeler@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.174 as permitted sender) X-PHP-List-Original-Sender: chasepeeler@gmail.com X-Host-Fingerprint: 209.85.214.174 mail-ob0-f174.google.com Received: from [209.85.214.174] ([209.85.214.174:34380] helo=mail-ob0-f174.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CE/A5-40147-FEFF3965 for ; Mon, 11 Jan 2016 14:18:08 -0500 Received: by mail-ob0-f174.google.com with SMTP id vt7so6892686obb.1 for ; Mon, 11 Jan 2016 11:18:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=JUn2WvFKJlSF8Q5D0wPeG08SeYZFQ32OuYR3ZO1OgJU=; b=esJ6dJDF/GcBc11NVapTakMjxxOjA7m1IT8NZgcUZw6DXaNnAdQnCxExRy1zb49mmz 67SZb4jlcF/5Os3dLGZCIP29EdEt+bC5SAAxz05VoEXJOagKbKjtypnVpOh3RUymfkXT omODTc8DQJr8+HqtBY490IkGs+OQwfxNUzTnYud2CLYMlPnUzzuFrOqBWmMwJ/62c3ch 6AnOxuR39MZtIiGCmC9KY5Lk6ANcyOvbUgf+p5rsQM/wnOj90p7OkHIu+z5v3SiS0CwI VBmm+U6eLc9P+HffMitjnJAx2jH8U8zs0Y/WxLhq1l8v9xaU2SSlrMolvvKOOahKUc+U 0weQ== X-Received: by 10.182.254.34 with SMTP id af2mr97827869obd.60.1452539884321; Mon, 11 Jan 2016 11:18:04 -0800 (PST) MIME-Version: 1.0 References: <910b145571b2c3e98338d54c0dd6a981@mail.gmail.com> <0E9E4C89-1800-4000-BD5A-BC81F43BE2FE@gohearsay.com> <44142A2C-0E7C-4525-880F-7759CD8A502A@heroku.com> <5691D820.4080309@gmail.com> <56934116.70002@garfieldtech.com> In-Reply-To: Date: Mon, 11 Jan 2016 19:17:55 +0000 Message-ID: To: Pierre Joye , Brandon Savage Cc: Larry Garfield , PHP internals Content-Type: multipart/alternative; boundary=001a1134905ed3c046052913cb1e Subject: Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct From: chasepeeler@gmail.com (Chase Peeler) --001a1134905ed3c046052913cb1e Content-Type: text/plain; charset=UTF-8 On Mon, Jan 11, 2016 at 12:52 PM Pierre Joye wrote: > On Jan 11, 2016 8:47 PM, "Brandon Savage" > wrote: > > > > > > > > At the same time, though, if someone is being maliciously hostile what > > > great cover! A private email is not a PHP-Group managed resource, so > no > > > rules! Twitter, ha, no rules! Reddit? LOL like they enforce > anything. > > > If someone wanted to send a death threat to another developer about PHP > > > business, I would hope that, as a developer, they are at least smart > enough > > > then to do so using a chat program that is "out of scope" so that > they're > > > untouchable. (If they tried to send someone a death threat on list, we > > > should ban them for stupidity. :-) ) > > > > > > That's why the scope needs to cover "involves PHP business, regardless > of > > > medium" rather than "just on certain pieces of server infrastructure". > > > It's trivial to circumvent otherwise. Now, how do we define "involves > PHP > > > business" in a way that, for example, forbids someone from harassing a > gay > > > person about PHP business but doesn't penalize someone for > participating in > > > an anti-gay-marriage protest in their home town? That's the question > we > > > should be discussing: How that balance works to minimize that risk, and > > > avoid it being abused to Eich someone. (Yes, I just used Eich's name > as a > > > verb.) > > > > > > > > > > > Larry, > > > > This is a great point, and brings up an interesting potential compromise > > that might work well for solving this issue. > > > > If the issue is that someone might take an on-list discussion and harass > > someone off-list, why not limit the jurisdiction to individuals who have > > participated on-list in discussion or voted on the issue? > > > > For example, during the very heated discussion over static type hints, if > > someone who had discussed the issue on Internals had then gone out to > > Reddit and called Zeev a bunch of terrible things, that could be made > > actionable under this code of conduct, reportable to the mediation team. > > > > On the other hand, we have a lot of people with karma who don't always > vote > > and may not participate in a particular issue on-list. If two people who > > have karma have a run-in outside the discussion of an issue related to > PHP, > > they should have to be adults and hash that out themselves. > > > > And that to me is the crux of the issue. When it comes to making > > discussions on internals more civilized, governing a person's conduct *as > > it relates to their participation in the discussion* is about as far as > PHP > > should go. A person who is not a party to the discussion, who does not > > vote, but does have karma, who happens to tweet "I think X is a moron for > > proposing Y" is entitled to that opinion, *until they bring it here.* > > > > If, on the other hand, the goal of the CoC is not to make Internals a > > better place, but to govern what people in the community think, say and > do > > when they have no direct involvement with this group, that's another > matter > > entirely. And a much scarier one at that, don't you think? > > My main concerns or worries are exactly those. > > I fail to understand how one can think that the CoC could be about > censorship (which is basically what this comment says). > > The argument isn't that people are trying to censor the list. The argument is that such a policy will inherently lead to such actions, no matter how good the intentions might have been. > I also fail to understand how one can fail to accept that we already had > and have issues, despite numerous people having experienced it. > > I, for one, have never denied they exist. My point has been even if they do exist, this isn't the proper means of addressing them. > I remember a time where we use to say "if you cannot stand the heat, leave > the kitchen" and I was actually supporting this idea. The problem is is > that it went too far. And we have to admit our weakness first to be able to > create a somehow useful CoC. If we do not see us having problems, there is > no point to even discuss a document to solve non existant (for us) > problems. > > Again, whether problems exist or not is not relevant in my view. Whether or not the approach will solve such problems if they do exist, is what I care about. Even if they will, I also care about exploring what the unintended side effects may be. > As a side but important note, it is very disturbing to read so many of us > denying the very issues we have. Even if it is denied in a very diplomatic > way. I am convinced that this is the first problem we must solve to get a > CoC, to accept the very existence of these problems. > > Again, not denying their existence. I also haven't seen that many people that have denied their existence either. I've seen a few people asking for examples, and others stating that we can't determine what impact such an approach would have without knowing more about the incidents they are trying to solve for. I think both of those are very different from saying issues don't exist. > My apologizes if this is seen as arguing but I feel like it is the only > fundamental difference I can see between the two camps. > -- -- Chase chasepeeler@gmail.com --001a1134905ed3c046052913cb1e--