2 ms·

I assume that if a maintainer explicitly said "I won't accept it because you are X" from that list, then that would violate the Code of Merit anyways, if they d

I assume that if a maintainer explicitly said "I won't accept it because you are X" from that list, then that would violate the Code of Merit anyways, if they don't say that, then everyone can look at the commit to decide if it stands on its own. The only proof that matters is the exact written proof as it is. If all of the other maintainers decide the commit is good, then the commit goes in anyways. Then we can avoid having an HR department for every open source project.

geofft 8y ago
OK, I think I understand something major now. The Code of Merit, ZeroMQ's C4.1 "must accept" process, etc. are all designed around the goal of, how do we accept pull requests/patches that are good. The Contributor Covenant and similar CoCs are designed around the goal of, how do we produce a vibrant community. 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/ 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-war-story-how-feminism-helped-me-solve-one-of-file-systems-oldest-conundrums/ 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.

geofft 8y ago

OK, I think I understand something major now. The Code of Merit, ZeroMQ's C4.1 "must accept" process, etc. are all designed around the goal of, how do we accept pull requests/patches that are good. The Contributor Covenant and similar CoCs are designed around the goal of, how do we produce a vibrant community. 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/ 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-war-story-how-feminism-helped-me-solve-one-of-file-systems-oldest-conundrums/ 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.