> On Jul 20, 2021, at 9:39 AM, Rowan Tommins <[email protected]> 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
