Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:109528 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 51662 invoked from network); 4 Apr 2020 13:18:15 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 4 Apr 2020 13:18:15 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9FF381804C2 for ; Sat, 4 Apr 2020 04:45:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 4 Apr 2020 04:45:24 -0700 (PDT) Received: by mail-lf1-f49.google.com with SMTP id j17so7965454lfe.7 for ; Sat, 04 Apr 2020 04:45:24 -0700 (PDT) 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=YK2RjFQ/ScQJcuwUeqLvwZ2N4Sivwx6mzCyoFjazrGg=; b=Np3ZAmTG1XF7qFQRSiLmPwSRuzbY7lVcOrNomUaizVaBgw0eKF7BgFl4BSPMFSw65k DNUSaOl+/jTQFdi38FbDzq6emMARCAqYXm0QejKGh0mH1cUc6JG6ee97rjMJ/b6JthOM 7oNYAIUVYG5BCWnZICsih0VnJI3oCDaneq2SZznSRxAIFD6GKgTXX7zxc2uY/403Qj47 Jy/LvarBDlqRnaOhA9AyRixxho/TzGglmQH/F9Zk0GVA7qVltN12PgD0qeM1fnfE8Zg6 ErOADtTBcDjuFEjti7Cyd/6fm/pV8N2qjkrYbxNMjgmxFZvCJfsn//WkypYqsXpT0y8E +Rlg== X-Gm-Message-State: AGi0PuZrYuwJg7f5/pZwUgGc2y57aH/Q9kMFKkfWEBGKEMlBaLp2CrjP znJsW6UmogplXRqyjGSA3gSdXaYib3pH6LVoKpY= X-Google-Smtp-Source: APiQypJ9iLaPTVP0gNF2DhkAk/IRHzgpoGu3v+Th3GhzZUtWQh21Dkij1hRSm14CDvTobEsP7IEPbnxerYUp4D9quWg= X-Received: by 2002:a19:e00b:: with SMTP id x11mr1580142lfg.147.1586000720151; Sat, 04 Apr 2020 04:45:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Sat, 4 Apr 2020 13:45:09 +0200 Message-ID: To: Chase Peeler Cc: Dan Ackroyd , PHP internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] Understanding RFC attitudes From: jakob@givoni.dk (Jakob Givoni) Great doc Dan, hope it can be linked from https://wiki.php.net/rfc/howto ! Cheers, Jakob On Fri, Apr 3, 2020 at 6:46 PM Chase Peeler wrote: > > On Fri, Apr 3, 2020 at 12:38 PM Dan Ackroyd wrote: > > > Hello Internals, > > > > The trade-offs that are good for a project like core PHP are quite > > different from the trade-offs from other projects. > > > > People are sometimes quite surprised by the attitude other people have > > on how best to maintain and improve PHP. > > > > I'm hoping that documenting my understanding of the attitudes that > > have been taken during RFC discussions, might avoid some of the > > surprise factor in discussions and so make the conversations be less > > confrontational. > > > > https://github.com/Danack/RfcCodex/blob/master/rfc_attitudes.md > > > > To be clear, this is only meant to help people understand other > > people's view-points. It is not a fixed set of attitudes that I think > > either are or should be followed. > > > > It's also not aimed at making everyone agree on all topics, but just > > to help set people's expectations on how any particular RFC might be > > received. > > > > cheers > > Dan > > Ack > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > I think this is a good idea. It appears to be a fair overview of various > topics. Personally, instead of organizing it into the two main areas that > you did, I think it would be better to maybe just list the various types of > arguments used for/against RFCs, and what the pro/con positions are. As it > is currently written, anything in the "less likely to pass" section might > be taken as something that should be avoided - even in cases where such > things do make sense. If, instead, we lay it out as "If you propose this, > these are the arguments you're going to get as objections, and here are > some of the justifications that have been used so far" someone might better > be able to determine if their RFC for such a topic is justifiable, and if > so, preempt some of the objections. > > -- > Chase Peeler > chasepeeler@gmail.com