Personally, I find any proposal that does not deal with clearly defining

voting eligibility not only questionable, but a non-starter, that has no

parallels in any other major Open Source projects. Why? While I think the question of voting eligibility is worth discussing

(though I also don't consider the problem pressing in any way and think

that our current pool of voters works quite well, even if it may not be

what people had in mind back then), it is, just like the question of voting

margins, a rather independent issue from the remainder of the process.

Kris's point made me think about this issue, and I may still need to do

some more thinking about whether the Workflow and Voting elements can be

separated. It may be that they can. However, I don't see how the Voting

element can be further separated into "voting eligibility" and "voting

threshold", and other surrounding elements like a quorum which we may want

to introduce. These are inherently interlinked. Moreover, there are

elements where even the substance of the given RFC has - or at least

should have - influence on the voting margins. Cases in point:

The PHP 6 vs PHP 7 naming RFC

The RFC to determine PHP 7's timeline

The PHP 5.6 EOL RFC

Any future RFC about timeline, naming, or other administrative,

non-policy-binding decision

These administrative decisions make no sense to require a 2/3 majority, but

rather - a simple majority of the eligible voters, as ultimately, it's down

to a matter of preference - without any long term (beyond a couple of

years) commitments.

The 2/3 majority was introduced to place a bias-towards-the-status-quo of

the language, and make sure we don't create long-term commitments based on

a temporary narrow majority. It simply does not apply in such cases.

Further, it's difficult to separate the question of "what requires a vote"

from a statement that "everything requires a 2/3 vote", although

technically not entirely impossible.

I'll do some more thinking about it and consider breaking the Workflow &

Voting into two different RFCs if I can find an elegant way to solve these

issues; But either way, focusing on the margins alone remains a

non-starter for me.

The problem with bundling together these changes is, if you will excuse the

political parallel, akin to bundling changes to copyright enforcement

together with a free trade agreement. Those two things have nothing to do

with each other (though of course interested parties will argue that they

are inseparable), but combining them into a single agreement makes it

feasible to pass changes that would not otherwise be considered acceptable.

At the same time, it also puts the overall agreement at the danger of

failing, due to parts that are not related to its core purpose.

As demonstrated above, they actually have a lot to do with each other, and

do have certain inter-dependencies. Thankfully, in our world, neither is a

series of books with countless chapters like free trade and copyright law

tend to be. I realize that there are some people here that want to simply

focus on the 2/3 margin issue and call it a day, but to me it remains a

very partial fix to a much bigger problem - that realistically, if we don't

tackle now while we've got people's attention - we'll likely never tackle.

The suggestion that the new RFC makes life more difficult, compared to the

current Voting RFC, is simply wrong. It is, in fact, very much the same -

except it's a lot more well defined in terms of 'what happens if' - which

in the years since the 2011 Voting RFC was enacted became a de-facto

wild-west. As quite likely the single largest user of the RFC process, I beg to

differ. I think your perspective here comes about, because your use of the

RFC process is limited to rare, but large (in the sense of important)

proposals. However, that's not the case for all or even most RFCs. It is

already the case that RFCs are cumbersome for smaller changes, and all

active contributors I know (apart from cmb maybe) will go out of their way

to avoid going through the RFC process if it is at all avoidable. It is

something of a social faux pas to tell another core contributor on a PR

that their change might benefit from an RFC, because that generally means

that the change will be dropped dead in the water instead. I think that we should encourage the use of RFCs for less significant

changes, because it is useful to have design considerations spelled out in

more detail than a two line commit message. Your proposal does not make

things much more complicated, and doesn't make the RFC process take much

more time. But it increases the marginal costs just enough to make RFCs

even more annoying than they already are. You edit your proposal a few

times at inopportune moments and bam, you have to wait one and a half

months before it can land. That's okay if you're trying to introduce a JIT

in PHP, but if you just want to add a function, that's the point where you

say "Why do I even bother with this?"

That's extremely fair feedback re the marginal cost of editing, and I think

going along what Larry proposed later on this thread would make a lot of

sense. It would balance your feedback with the need to avoid overburdening

the RFC authors, while at the same time providing RFC voters with the time

they need to analyze and discuss the merits of (and changes to) RFCs - as

well as preventing any sort of foul-play. Essentially, "whenever's there's

doubt, there is no doubt", but at the same time - if nobody raises doubts

(which they shouldn't for small changes) - things can proceed without

interruption. I'll try to embed it into the RFC.

I still think that the new workflow proposed would keep the burden roughly

the same as it is today (with the above fix factored in).

Zeev