Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104000 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 27498 invoked from network); 1 Feb 2019 22:23:42 -0000 Received: from unknown (HELO outbound1.mail.transip.nl) (149.210.149.72) by pb1.pair.com with SMTP; 1 Feb 2019 22:23:42 -0000 Received: from submission7.mail.transip.nl (submission7.mail.transip.nl [149.210.149.40]) by outbound1.mail.transip.nl (Postfix) with ESMTP id 43rmjQ0CWZzT4Vc for ; Fri, 1 Feb 2019 20:03:54 +0100 (CET) Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by submission7.mail.transip.nl (Postfix) with ESMTPA id 43rmjH74vqz1Q6Gg for ; Fri, 1 Feb 2019 20:03:47 +0100 (CET) Received: by mail-wm1-f49.google.com with SMTP id y185so5212451wmd.1 for ; Fri, 01 Feb 2019 11:03:47 -0800 (PST) X-Gm-Message-State: AHQUAuaHz3/FYo0B5mIT4NUtLi5FQ7jAb1ueWRDIU9Xo2veBGjRhph8p sT+nbDhwKVvdyXlOeZaXYyKfXWmULAZzpRVu1BQ= X-Google-Smtp-Source: AHgI3IYqPcuibtbnylCYioZSTN8EW4WzTGj7i1F7beH8Pz1eTHwh3qkH4FjNkDr5JI9ifJZqazGa4I51MWCUtHt8DTs= X-Received: by 2002:a1c:9692:: with SMTP id y140mr3730604wmd.67.1549047825130; Fri, 01 Feb 2019 11:03:45 -0800 (PST) MIME-Version: 1.0 References: <03f401d4b96b$18b9dc60$4a2d9520$@php.net> In-Reply-To: <03f401d4b96b$18b9dc60$4a2d9520$@php.net> Date: Fri, 1 Feb 2019 19:03:36 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Zeev Suraski Cc: PHP internals Content-Type: multipart/alternative; boundary="0000000000005b6c530580d9cd27" X-Scanned-By: ClueGetter at submission7.mail.transip.nl DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=transip-a; d=pmmaga.net; t=1549047829; h=from:subject:to:cc: references:in-reply-to:date:mime-version:content-type; bh=1lJmC1zhLWLddHQ2Z7jWvgP1j7mQJ6tCB2aWy0bmh74=; b=eWDRZ4yl03qbqMZ8RU8B26aICD2SKShqoA+a0u0TLTkBp4eZvKBnFXwEq4d4YAASBQQSKK diq3gbj34y8Ihc3NpgfLl+bJ7RaTouMHEoZtlp9goHXj9gy7xgaoAyPE1tYPK584W7LeCM TLfikrHQ154qat0LvV6RiY8na57upUJzEoYHnBXVoRVPQvM5qdu8s0PqVGYzfi4s8vt8cq YCIYqfIx1gHEG1FNuwi536I/b1QHstvFc90Dz3dPo0haZuN6xsp5oY/nj8zmVRxh0RHHxb z9SGrYVwJiAK31AIwxDhHI2EJLHKPxdWehkz6ss8QN/pmRFRDlMsRmcxLspplg== X-Report-Abuse-To: abuse@transip.nl Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update) From: mail@pmmaga.net (=?UTF-8?Q?Pedro_Magalh=C3=A3es?=) --0000000000005b6c530580d9cd27 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Regarding the definitions of what constitutes a Change, a Packaging Decision and an Implementation Decision, I think it does a better job than the current voting RFC but IMHO it still is over-complicated. Trying to specify which changes are which just for the sake of allowing some things to pass with a slim majority seems a wasted effort to me. As "proven" by the currently open issues, it also misses a categorization for administrative changes. Stating only which changes require a RFC and which don't would be much simpler. Also, that last part about performance degradation will also lead to unnecessary discussion if it isn't more clearly defined (is it just the bench.php? mediawiki test suite?). On the section about Changing the RFC, again a distinction is made between extending the period for 1 or 2 weeks depending on what you subjectively consider "substantial". For the sake of simplicity, I'd suggest it to be always 1 week. About No Discussion/Voting Periods, I think it would be simpler to just extend the voting period to a minimum of 2 weeks. For anyone interested on the subject, they would have 4 weeks to find out about it (2 for discussion and 2 for voting). Maybe some people actually have more time to contribute/participate in discussion during their holidays. As stated before, The Eligible Voters section fails to mention its reason to be. Lately, RFCs get around 20 to 40 votes, why do we have to reduce the list of potential voters? To me, it seems arbitrarily hostile to newcomers while overly protective of people that have long lost interest. In other words, someone who has made their last contribution 10 years ago keeps their vote while someone who fixed a bug every 2 weeks for the last year isn't eligible. Also, the proposed measurements are subject to be "gamed" (not squashing your commits, changes to license headers, etc..). And for other members of the project the same problem poses, how do you measure docs contributions? And maintaining the servers? And PECL extension maintainers? About FIG, it is an organization which has its own membership rules that are subject to change at any time at its own discretion. While I truly believe that it would be very important to provide a way to allow the users to express their voice, doing that via an external organization doesn't seem acceptable. Keep in mind that the current voting RFC keeps the decision of which community members can vote in PHP's side. To cater to an even larger audience, there could be a section on RFCs where anyone could cast their vote so that the RFC author can also take it into consideration but keeping it non-binding. (Or perhaps giving it a predefined weight - 1, 3, 5 votes?) Regards, Pedro On Thu, Jan 31, 2019 at 1:44 PM Zeev Suraski wrote: > Without further ado, an RFC that=E2=80=99s attempting to comprehensively = solve > many of the issues that have plagued our RFC process since it was hastily > introduced in 2011: > > > > https://wiki.php.net/rfc/voting2019 > > > > Emphasis on =E2=80=98attempting=E2=80=99. I=E2=80=99m sure there are sti= ll a lot of holes in it > that should be plugged before we vote on it, but instead of waiting > indefinitely =E2=80=93 I=E2=80=99d like us to start discussing it. > > > > Comments and suggestions welcome. > > > > Zeev > > > > > > --0000000000005b6c530580d9cd27--