Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:107131 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 91599 invoked from network); 16 Sep 2019 04:12:47 -0000 Received: from unknown (HELO php-smtp3.php.net) (208.43.231.12) by pb1.pair.com with SMTP; 16 Sep 2019 04:12:47 -0000 Received: from php-smtp3.php.net (localhost [127.0.0.1]) by php-smtp3.php.net (Postfix) with ESMTP id 3DCF32CBF5F for ; Sun, 15 Sep 2019 18:49:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp3.php.net X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Virus: No Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp3.php.net (Postfix) with ESMTPS for ; Sun, 15 Sep 2019 18:49:32 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id m143so214822ybf.10 for ; Sun, 15 Sep 2019 18:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=PZ93wyhNPwLnurMkQRYfy3u6dM4YpOu/73Emwxds0t0=; b=CeCYajHyF0nuQgvc9WugSdToSi8NUVOysDKxHjBpMdLMzk/f4i1xKoSNATtKPGSc/M NfNgPA6OQ83xGN8Un7MTLLRPyGSYBXLpjJVCXdDIPnjpvPRZkKWVQZUBPAVkuQhUGmA5 CcyyOk1Q0QJgBSEHthcFQNpqTIGOr5k7qf85N1E+7zXn2GtM+4KnZ6oOXwWSgNebTQ+p /4KZKtQY+Uwmjnsbx7K2JsZuX7IGN6h0B8DuFhaWTMUMZziOtfaqGnDGte5KWU5yg2iy rPSXeqBg1Ef118/OK3AgJEB/UOZtiq6Dob1rYkiWWQo2J5N3zcb9fe90nIZ+nxGtmi91 DyWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=PZ93wyhNPwLnurMkQRYfy3u6dM4YpOu/73Emwxds0t0=; b=eng4/PLpymX0TSNfC4Da/7CNuC3cZw9MHBDx8AfYSciqpHvF3GQuGkCO9VZzRznfxf m7DlZRxi9+kINRDMasmK1gQZfpEUw0d8uPwh7XZ5xH42i2eD+VTKhnQYX9ewqSoXlr3F rZ4BHLQob3SrLs/ND3Pm/nWmiBDnX9CZOeETkBVe0qJu8QYS2XhPlmkGe/DFap/INWah F9bLuDoJohc/M+yy59e480IW7fKcwS/AWlApWLcon17gCg3Iii2i5JCjdBcwj3SGALDa VWmrpf/ZchJvIvCWYMRysmalVDngJ9GuzPyv+v/ZsY04UkGFXNwWu1HuZcH3NFjyYe3f 5bvQ== X-Gm-Message-State: APjAAAW+O+CUvNU3LKjRgDvrmN2/ARFUZ0ADHS8wamOMV0/1bfIPsgHi uqD0R608SurSzRZziKy3EmofAsv/lYA= X-Google-Smtp-Source: APXvYqzUL56qamx3WyN/ngFPTFQ6qFbbCvzjWUTawl+IBwN1SK2PSYliKZsZ5ZrH/5fMBKNDS3orXA== X-Received: by 2002:a25:ca12:: with SMTP id a18mr75346ybg.24.1568598571968; Sun, 15 Sep 2019 18:49:31 -0700 (PDT) Received: from ?IPv6:2601:c0:c67f:e34e:3df7:cf85:c58b:e5f6? ([2601:c0:c67f:e34e:3df7:cf85:c58b:e5f6]) by smtp.gmail.com with ESMTPSA id a130sm7713583ywc.81.2019.09.15.18.49.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 15 Sep 2019 18:49:30 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0A835FA9-F8C2-413C-9E3D-10FEB5F5CDF1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-ID: <572E7B74-9D56-483F-94A6-F2955C63AA56@gmail.com> Date: Sun, 15 Sep 2019 21:49:29 -0400 To: PHP Internals List X-Mailer: Apple Mail (2.3445.104.11) X-Envelope-From: Subject: The RFC discussion process? From: mikeschinkel@gmail.com (Mike Schinkel) --Apple-Mail=_0A835FA9-F8C2-413C-9E3D-10FEB5F5CDF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I am relatively new to discussions on the list, and so I have tried to = understand the ethos of the community to stay within bounds that the = community generally considers acceptable. =20 However I am realizing those the bound of acceptability may be fluid at = times so I am asking explicitly for clarification. 1. What is acceptable to discuss in an RFC discussion thread? =20 Recently while discussing object initializers I was told "I think that's = only true because you've actually proposed a number of related but = different features," "This is an interesting additional proposal," and = "This again is an interesting proposal, but completely unrelated to = object initializer syntax." =20 But I was replying to a message where a frequent and I believe a = respected contributor wrote the following, also unrelated to the RFC: = "My strong preference over this feature would be named parameters, which = can provide the same abbreviated initializations, but works more = consistently with the language, e.g. for all of the use-cases I cited = above." I am not naming names because I am not trying to make this about those = people but instead to understand what is appropriate to discuss during = an RFC. So Is it is appropriate to discuss: 1. Alternatives to the RFC? 2. Enhancements to the RFC? 3. Modifications to the RFC? 4. Other features that are a pre-requisite for the RFC's feature? 5. Other features that would add value to the RFC's feature? 2. Are "amendments" acceptable for RFC discussions? I am thinking of Congress in the USA, Parliament in the UK, and other = political governing bodies. My understanding is that bills are = introduced and they have the possibility of being amended by other = members of the political body. =20 Comparing that to the RFC process it seems RFCs are like bills; is there = an amendment process, and if so how does it work? =46rom what I can to = amend an RFC requires getting the original submitter to modify it, which = if that is the process that is understandable. However, what seems strange is that I also understand there is a 6 month = moratorium on revisiting a topic that did not pass by RFC, but an RFC = could potentially not pass because of details in the RFC and not because = the overall idea is bad.=20 If I understand correctly, this means others cannot restart a topic for = 6 months because the person who first drafted the failed RFC did not or = would not incorporate aspects that might have allowed it to pass? 3. Why is there not more transparency for why RFCs pass or do not pass? Looking in from the outside I see is almost no transparency related to = reasons why RFCs pass vs. don't pass. When I visit the RFCs of past I = see lots of votes but almost no rationale why those votes passed or = failed. There are a few active members on the list, but many more people who = have a vote who I think rarely if ever comment on the list. So it seems = impossible to determine what the objections are from the people who vote = against an RFC. Which means it will be hard to address their concerns = as time goes on and other languages evolve because of userland demand to = add the features that PHP voted down. Unlike the US Supreme Court and I assume many other nation's supreme = courts, the people with an RFC vote are not required to write or join an = opinion as to the reason for or against an RFC.=20 This unfortunate state means the rationale for the PHP group voting for = or against an RFC is lost to the mists of time, except for the history = left by the few vocal people who have the free time to participate on = the list in discussions. Most of the people with a vote rarely opine on = the list, or that is the impression I am getting. ---------- Thanks in advance for reading and responding to these questions. And = based on the replies, I may have a few more follow up questions. -Mike= --Apple-Mail=_0A835FA9-F8C2-413C-9E3D-10FEB5F5CDF1--