Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115541 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 9368 invoked from network); 21 Jul 2021 10:24:01 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 21 Jul 2021 10:24:01 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id DFA821804DA for ; Wed, 21 Jul 2021 03:49:27 -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.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) (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 ; Wed, 21 Jul 2021 03:49:27 -0700 (PDT) Received: by mail-qt1-f181.google.com with SMTP id v14so1572209qtc.8 for ; Wed, 21 Jul 2021 03:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7o65fLDLKtuiTCGXRvTU24tk8aaoN+53QCAaHeRk25w=; b=iH66dieazVN0vUBLP/OeesLgxm+HFfLxMwo+CNfqouLgeBCpB/WKgE3xfj+zg7hZ2a qBXuZ+lXL9twb3rp6ft+nMZTmxl8FgWZ3o2Quaw4pr05/9oMrLL0mzqwWrQjYxJXWdZE PoUE3qh/8f8/oidT3e+yrj1XWbx4nFVH8StxUL1onp+zf24w6JOZha/3n228m1sOQR/P L8xKvb/wcY/TLCbSdJxnmDBF3Bf6GWmzPB3A2NVYCithTnNbpDxQwUOKP/LCSZubV8Oi tn6RukhAzo/JprRAILgSkp/qKJ1+uJO9eGHs/ZPM5W/OyNeNFO2Z3yEDOb1fYV5kcNs6 QtQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7o65fLDLKtuiTCGXRvTU24tk8aaoN+53QCAaHeRk25w=; b=cnJtfR3g/g0VGCrSg6aAizk8hQqIqsDiz5XkKllBbGd1J4EG42Lc1S39KZMQkzPtm7 vI58H92+z6si6SpI0UWsBPO3PMyFJlk9NBEdJ9DkxAtG3oKrxbGZ+SaSiG7xeMB4wjjD J+UlK7Q6VK+r6l9ZM7UxWVn3xhuS4wtyMc17kGH3G77zYWxWwwNHWbVVsaiPrIdynxgb UWIhz/nJ98j+J2RjWle5ebZxjMumFS1VCqJZa1eBt98ew1tX9bxDpeI6MBAN/9671+YO 6z/kdYgdF4N6Txr7nwWZId8s+nxLO1z46trAKY+hHNkV5wk/55f/0xEaWIh9CqqWv12D 2u7A== X-Gm-Message-State: AOAM532hWiZap0ywler8CxcKJip09F7JzsEYLM3kJQrKRynur0M0QiVj /qUYBLMUbiXSq4n2+BiSdZGPWQ== X-Google-Smtp-Source: ABdhPJzMMIF4J0vQ4zpPXR8poob86XDPAZWPc3N3nqv+xAhJ2ylhTSuSydUp5oPT/6GvOC93wDLi8w== X-Received: by 2002:ac8:7fd6:: with SMTP id b22mr29413548qtk.235.1626864561117; Wed, 21 Jul 2021 03:49:21 -0700 (PDT) Received: from [192.168.1.10] (c-24-98-254-8.hsd1.ga.comcast.net. [24.98.254.8]) by smtp.gmail.com with ESMTPSA id n14sm2240776qti.47.2021.07.21.03.49.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jul 2021 03:49:20 -0700 (PDT) Message-ID: <2D38400B-6CA7-4B4C-9156-D85BF9E07A94@newclarity.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_91811D6A-13C8-45A2-B921-E9901892CD65" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Wed, 21 Jul 2021 06:49:18 -0400 In-Reply-To: Cc: internals@lists.php.net To: Rowan Tommins References: <96487D08-8573-4308-A11C-3118113C03DA@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.7) Subject: Re: [PHP-DEV] Request for karma to vote on RFCs From: mike@newclarity.net (Mike Schinkel) --Apple-Mail=_91811D6A-13C8-45A2-B921-E9901892CD65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 20, 2021, at 9:39 AM, Rowan Tommins = wrote: >=20 > When decisions are just a matter of bikeshedding, or deciding what = "style" the language should have, there is a strong argument for general = democracy, and a strong voice for those who use the language. >=20 > But some decisions have more fundamental impact on the implementation = itself - highly technical features like JIT or Fibers, or conceptually = simple features with complex implementations like Intersection Types. = The concern is that the small number of people who understand those = consequences will be out-voted by people "voting with their heart" = because they like the idea of a feature. >=20 > Those core contributors are then expected to maintain the resulting = code, with little help from those who wanted the feature. Hence the = suggestion, not of an "elite", but of some sort of "meritocracy", where = that knowledge carries some weight. >=20 >=20 > Perhaps we need a more revolutionary re-organisation into two separate = voting groups: >=20 > * a very open community vote, to indicate a breadth of support for the = direction a change takes the language > * a group of Core Contributors, much smaller than the current voting = pool, who are equipped to judge the impact of the implementation This is an excellent observation, and encapsulates why some of the RFC = outcomes might feel a bit mismatched with what many people want and/or = what seems to make the most sense for PHP from a core maintenance = perspective.=20 > An RFC could require separate approval from both groups, regardless of = number of voters, like a parliament with two chambers. But I'm not sure having two houses that can both veto a a solution would = improve things. I think it would just make it worse.=20 If there was the Userland House and the Core Contributor Senate then = that would mean that things in your category of bike-shedding could = still be blocked by the Core Contributors even if 99% of userland = developers loved an idea. Instead maybe we should consider those known and respected because of = their continuous core contributions ("Core Contributors") have the = ability to veto an RFC if it treads into core territory? BTW, "membership" in Core Contributors would be managed informally = within the group of people. Once the initial group was recognized they = would handle adding new people to the group and/or ejecting existing = people completely among themselves and then one of them would announce = any updates to the list. Consider if Core Contributors are allowed to classify an RFC as a = "Core-related" concern, such as 1.) a core maintenance concern and/or = 2.) a future-compatibility concern? And if it is one of those two, = then Core Contributors could request a veto vote. I think we could = assume they would only do this in good faith because of the potential = for damage to their reputations if they were to operate in bad faith. When an RFC is being discussed a Core Contributor could simply stating = their belief it is Core-related and if two other Core Contributors = seconded that concern then the RFC would be susceptible to a potential = veto vote and the RFC author would be required to mark it as such. = Classifying as Core-related should happen during discussion period and = before the vote starts, and especially not after a main vote has passed. (However if it gets contentious then three (3) Core Contributors could = band together and simply update the RFC to be Core-related; their view = on this would be final. But I doubt that would ever be needed because = an author arguing against Core Contributors in this way would mean the = RFC would probably be voted down anyway.) Then for voting: 1. If an RFC is *not* Core-related then everyone gets to vote just as = before, but maybe voting access becomes more open and more democratic? 2. If an RFC *is* Core-related then the same vote occurs but if is = passes then three (3) Core Contributors can request to have a Core = Contributor-only vote which will require a 2/3rd majority to pass. If = this vote fails to gain 2/3rd majority approval of the Core Contributors = then the RFC is considered "Vetoed."=20 The benefits could potentially be: 1. Ensure even if a feature is desired by userland we could still guard = against approving features that would be a maintenance problem or that = could paint PHP into an evolutionary corner. 2. Lowering the bar for voting rights because voters couldn't do damage = to core-related concerns. =20 3. Possibly gain more participation from userland 4. An increase in userland satisfaction from either being allowed to = participate or for the broader community getting more features userland = developers want. 5. Very little change procedurally, except to formally recognize the = Core Contributors separately from others, and giving them the ability to = call for a veto vote after an RFCs that were previously tagged as = core-related passed. BTW, rather than calling it "bikeshedding" we might characterize it more = charitably as "style-based," where "style" refer to the realm of = userland developer-experience. What do you think? =20 Most specifically I would like to hear from those who know they would be = in the category of Core Contributors who would get a veto they currently = do not have on core-related concerns, but who would also potentially see = their vote on opinion-based RFCs diluted. -Mike= --Apple-Mail=_91811D6A-13C8-45A2-B921-E9901892CD65--