Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104031 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 95965 invoked from network); 2 Feb 2019 20:21:27 -0000 Received: from unknown (HELO mail-qt1-f179.google.com) (209.85.160.179) by pb1.pair.com with SMTP; 2 Feb 2019 20:21:27 -0000 Received: by mail-qt1-f179.google.com with SMTP id l11so11371895qtp.0 for ; Sat, 02 Feb 2019 09:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gPunvzwc9HGxQv9yL6o9Eu3FNt+BCGQqPAEh+snV6jM=; b=SCY7KjV0zfXBh2qM5VPkLJspuJirwsL7bJI1LGIBNM0ZhlZAtRsUX0PZ+Z/qLKEEqF jPWMDz6mFPxRADiFU7Vs2s2PLI5Su/tN6Zt/UwbpnMd2c7CZhord5cGtG9VVLS+xlyAz 4YburhFDBNtabRLus75rgA7Z1kkBYADzt6KseXyE9LbBOalzNLQJaUScoe2vd41Awbg9 4OqY3qUmzjFbCrVdqZMXTUYiQDztAqUNE/oEaBjEaeo+0cQvpBlzxGTlJaTiEG12QsAo oULlN5HzMkW4plSe3NaP0XydQpSCqJU3nPwtP5Ks5QdYpO1+iRXO0VUiIocLWF5Be15B g8UQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gPunvzwc9HGxQv9yL6o9Eu3FNt+BCGQqPAEh+snV6jM=; b=QZVNNCF0tNJJb5G8VFnpSIeZ2kkKhTnr1dwUAjdepPq07zrxTr/ntPm9qXz49unBTp DmIG1QXGPfcJoRgE/rSjuLyBQtIhVYZnw9jKTVpOwnoOFWBHfnsXQCB8lhfohF7tRqqK xqpbzxpUIG5UQgGP7kDsdV8B+z+PnvLkCwFnMiyn0g9UujsicNi2EbeUQT0iZJN30Kgw fc5ceHoEh8Et8AfHNtfc+YUJprPcMEARX8MTosD9kEJVHSq8oXUeQWkLdRdCrWhSRKn7 4VkFOoq1XDjAwZSCmsh9HQpEBC/eGqJrvzocPKWj6891ayjA2cr1Q0AdmLMobRktBAaf WJOA== X-Gm-Message-State: AJcUukekRUZbxNZKq1Df4r+f15Z3Zz6ULqvu9Tsw5fGZwqBm76IYmP0j 9P8iyBkEpJNwigKgQ8KJXk82jEnylSRFza2Fkxk= X-Google-Smtp-Source: ALg8bN42u9U7uUL9FdBF4Ur6DVBrPGc91WLDvJSARyPTufqWRfHyHVFRPmWjXiXoHnL1mxQFBaG/J+2qCX9QSogmTtQ= X-Received: by 2002:a0c:f053:: with SMTP id b19mr41472077qvl.29.1549126912426; Sat, 02 Feb 2019 09:01:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Sat, 2 Feb 2019 18:01:41 +0100 Message-ID: To: Nikita Popov Cc: PHP internals Content-Type: multipart/alternative; boundary="00000000000053c7590580ec3791" Subject: Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process From: legale.legale@gmail.com (Legale Legage) --00000000000053c7590580ec3791 Content-Type: text/plain; charset="UTF-8" Hello, internals. I am with you recently. But as a person with a fresh look, let me insert my 5 penny coin. About half a year ago, I knew about the C language only that such a language exists. The reason I decided to contribute is curiosity. So I'm probably not as motivated as some of other internals. I want to say that even a small and fairly simple code change, which I proposed to push through the bureaucracy, was difficult. So If RFC process becomes more difficult this "road" will be closed for some sort of random people like me. I hope this doesn't happen. Best regards, Ruslan On Sat, 2 Feb 2019 at 17:24, Nikita Popov wrote: > Hi internals, > > After discussing the topic with a number of current and former > contributors, I feel that the workflow & voting RFC currently under > discussion is moving us in the wrong direction. I will not comment on the > rather questionable proposed changes to voting eligibility, as these are > already extensively discussed in the RFC thread. > > The remainder of the workflow & voting RFC is mostly concerned with > defining stricter rules and more rigid procedures for the RFC process. It > increases the amount of bureaucracy and overhead involved in the RFC > process, making the RFC processes even less suitable for smaller changes > than it already is. > > The proposal I would like to present in the following is not my own idea, > it has been suggested by Anthony Ferrara. Because I found the idea very > compelling, I'm presenting it to the list now. > > --- > > Instead of making the RFC process more complex and rigid, we should > simplify and streamline it. The RFC process is reduced to only two rules: > > 1. All primary RFC votes require a 2/3 majority, while secondary votes > resolving implementation details may use a simple majority. (This is > already proposed in the voting margins RFC, so discussion about this point > should be directed into the corresponding RFC thread.) > > 2. All RFCs must have a voting period of at least 14 days, announced in a > separate [VOTE] thread. > > --- > > That's it. More notable than the rules itself are probably the two main > omissions: > > 1. There is no required discussion period. However, if an RFC vote is > opened without leaving enough time for discussion, then voters can and > should vote the RFC down on the grounds of insufficient discussion. > > The motivation for not having a fixed discussion period (but a longer > minimum voting period) is that RFCs come in many different forms and sizes. > Some RFCs are long and complex (such as the recent typed properties RFC) > and require more time for an adequate discussion. Other RFCs are simple and > of limited scope (such as an extension function addition) and do not > require extensive discussion. > > While a two week discussion period should remain a good guideline for > language-related RFCs, it is up to the RFC author to decide when opening an > RFC vote is appropriate. This will depend both on the scope of the RFC > itself and the activity of the discussion. (It is an unfortunate fact that > many RFCs receive their first meaningful feedback during the voting > period.) > > 2. There is no moratorium period after an RFC vote fails. If you think that > you have made significant progress on an RFC and resolved the issues that > made the previous vote fail, you can give it another shot at any time, > without having to wait out some fixed period. > > A failed vote does not (necessarily) mean that a feature is not wanted. It > is quite common for significant changes to fail on first vote, due to > issues in the initial proposal. A failed vote should not be a > discouragement, but a motivation to address problems expressed during > discussion or voting. > > It should go without saying that if you restart a failed RFC vote without > making substantial changes to the RFC, the result is unlikely to change in > your favor, and that continued misbehavior might be seen as spam. > > --- > > Essentially, this is about making the RFC process more suitable for changes > small and large, and empowering both RFC authors and the voter base to make > decisions that are appropriate for each RFC. > > What do you think? > > Regards, > Nikita > --00000000000053c7590580ec3791--