>You wrote that the Steering Council's decision does not mean "no," but the steering council has not set a bar for acceptance, stated what evidence is actually needed, nor said when a final decision will be made. (...) Without these timelines and milestones in place, I would like to explain that the effect of the Steering Council's answer is a "no" in practice.

from the nogil author, and a comment from another:

>Leaving aside the INCREDIBLE effort Sam went thru, the discussion around it is disingenuous with constant goal post moving and frankly myopic.

Reminds me of some discussions in FOSS projects were rejection is masked through various similar tactics.

One example would be golang proposals (and even code contributions), especially generics which were shot down for the better part of a decade, with a similar "we're open to it, as long as we find a proposal that meets our impossible/shifting standards", only for the core team to make their own idiosyncratic implementation when they finally accepted the need. Not really a better one or immune to the concerns used to shot others down, more of a NIH affair.

A similar story was going on (with a popular, bound-for-inclusion non-core-team implementation shot down too) for the depedency management case.

It's not just golang either, many other good proposals languish and PRs get forgotten and left to code rot. Even for bug fixes with no downside.

I wish project steering committees who get to decide/veto would be more explicit about "no" or "yes", as opposed to wanting to appearing open when such proposals aren't going anywhere.