Re: Request for karma to vote on RFCs

> On Jul 20, 2021, at 9:39 AM, Rowan Tommins <rowan.collins@gmail.com> wrote: > > 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. > > 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. > > 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. > > > Perhaps we need a more revolutionary re-organisation into two separate voting groups: > > * 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. > 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. 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." 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. 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? 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