These are different goals, and the former is sufficient if you don't necessarily want a community (e.g. it's a corporate code drop) or you see some reason why people will produce patches regardless. But it's the wrong priority for major open-source projects created by decentralized, often volunteer teams. Those projects need active bug reporting, design review, thinking about future goals, feedback on existing designs, shared visions, etc. A process that simply lets you accept correct patches, should they somehow show up, won't get you there.

This is the process that Rust core team member Aaron Turon calls "pluralism and positive-sum thinking" https://aturon.github.io/2018/06/02/listening-part-2/ , and former Linux kernel contributor Valerie Aurora calls, interestingly, "feminist" https://blog.valerieaurora.org/2014/10/03/operating-systems-... . But whatever you call it, it's very different from a process that just answers "is this patch being reviewed with sound reasoning." Such a process would have soundly rejected v1 of the patches implementing all the things requested in those articles and likely discouraged contributors (again, for sound reasons, not out of bigotry), and not produced technically better and more meritorious work.