Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:88911 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 60872 invoked from network); 21 Oct 2015 17:38:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Oct 2015 17:38:41 -0000 Authentication-Results: pb1.pair.com smtp.mail=danack@basereality.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=danack@basereality.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain basereality.com from 209.85.160.169 cause and error) X-PHP-List-Original-Sender: danack@basereality.com X-Host-Fingerprint: 209.85.160.169 mail-yk0-f169.google.com Received: from [209.85.160.169] ([209.85.160.169:35107] helo=mail-yk0-f169.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D4/11-55035-F9DC7265 for ; Wed, 21 Oct 2015 13:38:40 -0400 Received: by ykaz22 with SMTP id z22so57242851yka.2 for ; Wed, 21 Oct 2015 10:38:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WTzzQbFZeUMN+ORHPcAZTR2ElcMzHfhyEkZDfMtn1Y0=; b=RUxdaReYVX8VgiFHzHIfT3vCBsye2AzxDJ/kb5iHbj+2o6BYNEfR9evQEO36ac88yB KC+ZvFVGQEffWrsFV6VY5gJEpaRLIIM5CUwG8aGzHFOXPOFZlgBp1kzTWFzhxLC6m8o5 TnQp3GPstMMT+u1z58Gq2ZyDFGgGLVtOtwvQASti4YzRNTljN6NHBpcMtghgJQkKrI9s iahX4ThaFJqKC00nYSqIeD3jgqziX5ZuVAYey4h46fY2Y1DeLQAJxNfz+28tfN0L0J3t vNEwi4hcFO65v5R3vQgma6EQiecNL4mCvIEnn12w9Yir9WNVaII9XVwj69KXg0KiPEQ8 xreQ== X-Gm-Message-State: ALoCoQn6lglpkGgpSOmTu8T9sbQX2Mo3J2bUUQSgu8TYouajZbv/BXfd1xx8nKZj/3+gaaoVACwK MIME-Version: 1.0 X-Received: by 10.129.79.204 with SMTP id d195mr7226928ywb.159.1445449116141; Wed, 21 Oct 2015 10:38:36 -0700 (PDT) Received: by 10.37.76.137 with HTTP; Wed, 21 Oct 2015 10:38:36 -0700 (PDT) X-Originating-IP: [78.145.254.11] In-Reply-To: <20151021161740.GA23933@3006.local> References: <20151020173602.GA92318@3006.local> <20151021161740.GA23933@3006.local> Date: Wed, 21 Oct 2015 17:38:36 +0000 Message-ID: To: Sean DuBois Cc: "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] [RFC] [VOTE] Class Constant Visibility From: danack@basereality.com (Dan Ackroyd) On 21 October 2015 at 16:17, Sean DuBois wrote: > > I will update the RFC. Who decides if/when we should restart voting? "The PHP RFC rules is more what you'd call "guidelines" than actual rules" as there are no set decision makers or rules enforcers. The rules set down for this scenario are, in theory, pretty clear: > Based on the result of the votes and the discussion there are three possi= ble outcomes: > > A serious issue with your RFC needs to be addressed: update the status of= your RFC > page and its section on https://wiki.php.net/RFC to =E2=80=9CUnder Discus= sion=E2=80=9D and continue > again from step 5. But in practice what is a 'serious issue' is not defined. I think it is almost always right to restart a vote for anything other than the most minor change as: i) It avoids setting a precedent where an RFC is changed substantially while under vote. ii) It avoids anyone being able to complain that either what was implemented was not what they voted for, or for people to be able to ask that the 'missing' behaviour be implemented as a bug-fix. And yes, in this case the RFC restarting the vote could be considered overk= ill. I can't see anyone actually changing their mind due to the text being clarified, and so the result of the vote will be overwhelming support, again. But following the rules scrupulously when the outcome is clear, makes it harder for people to bend the rules when the outcome isn't as clear. cheers Dan