This is why merit based evaluation is the only sane hiring practice. I'd love to see legal protection for companies that can provide evidence they strictly adhered to the merit based hires.Maybe something like that could work if we ever figure out how to consistently and accurately measure productivity. Assuming that productivity is in fact how you intend to measure "merit".
.
Also, from your link...
The project creators, lead developers, core team, constitute the managing members of the project and have final say in every decision of the project, technical or otherwise, including overruling previous decisions. There are no limitations to this decisional power.
Well, at least you're honest about being a dictatorship. :) OTOH, just saying doesn't make it so. Hostile forks are a thing, license changes without copyright assignment are not a thing, etc.
All members have the same opportunities to seek any challenge they want within the project.
Congratulations, you're biased in favor of people with more outgoing and assertive personalities. ;)
Authority or position in the project will be proportional to the accrued contribution. Seniority must be earned.
Proportional requires that contributions be quantifiable. I'm not aware of any accurate, objective way to do that. (If there was, it would also be a solution to the "how to measure productivity" problem.)
Software is evolutive: the better implementations must supersede lesser implementations. Technical advantage is the primary evaluation metric.
What does "technical advantage" include? Switching costs imposed on users? The level of skill required from contributors? IDE-computable code metrics?
This is a space for technical prowess; topics outside of the project will not be tolerated.
Non technical conflicts will be discussed in a separate space. Disruption of the project will not be allowed.
These sound like an excellent way to let the trees blind you to the forest.
Individual characteristics, including but not limited to, body, sex, sexual preference, race, language, religion, nationality, or political preferences are irrelevant in the scope of the project and will not be taken into account concerning your value or that of your contribution to the project.
So, there's no such thing as "reasonable accommodations"?
There is no room for ambiguity: Ambiguity will be met with questioning; further ambiguity will be met with silence. It is the responsibility of the originator to provide requested context.
Wow, working only on clearly-defined problems must be nice. What happens when the ambiguity is part of the problem space?