I came to a similar conclusion 20 years ago, when I helped write the rules FreeBSD uses to elect their Core Team. At the time, the existing Core Team was comprised entirely of men who worked on the FreeBSD kernel, and a few who also spent some time in libraries and utilities. Plus Jordan K. Hubbard, who had become the unofficial Voice of FreeBSD mostly by way of stepping up to do so.
In re-writing the rules to elect the Core Team from the body of contributors, I was an ardent supporter of bringing in not just kernel developers, but also contributors from the documentation team, the "ports" team that brings more than 20,000 precompiled applications to FreeBSD, and other contributors like the ops teams that keeps the project infrastructure up and running.
I'm proud of what we managed to accomplish. 20 years and 10 elections later, the process is still working--with some inevitable adjustments. Along the way many open source projects, especially the large ones, have learned that some of the ideas of the 90s about "code talks, everything else walks" aren't sustainable in a large project. Once you've grown beyond a small handful of contributors, you are building a community as much as you are building software. Communities have to protect themselves from people who can't fully join the community, regardless of how much code they can crank out.
Codes of Conduct are important not of themselves, but because we value people more than we value code (or docs, or build scripts for applications, or whatever). That's a point I'm happy with all the time, every day. Technical Merit has it's place, but not above people.
Let me call out a few other names that were critical in moving FreeBSD n this direction: Poul-Henning Kamp started it and gave us a mandate to get it done; Warner Losh and Greg Lehey made the process worth all the fuss and bother. Open Source projects newer than Y2K often end up adopting a variant of the process we went through to govern themselves once they grow past the "handful of volunteers" stage and I'm thankful for all of it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I came to a similar conclusion 20 years ago, when I helped write the rules FreeBSD uses to elect their Core Team. At the time, the existing Core Team was comprised entirely of men who worked on the FreeBSD kernel, and a few who also spent some time in libraries and utilities. Plus Jordan K. Hubbard, who had become the unofficial Voice of FreeBSD mostly by way of stepping up to do so.
In re-writing the rules to elect the Core Team from the body of contributors, I was an ardent supporter of bringing in not just kernel developers, but also contributors from the documentation team, the "ports" team that brings more than 20,000 precompiled applications to FreeBSD, and other contributors like the ops teams that keeps the project infrastructure up and running.
I'm proud of what we managed to accomplish. 20 years and 10 elections later, the process is still working--with some inevitable adjustments. Along the way many open source projects, especially the large ones, have learned that some of the ideas of the 90s about "code talks, everything else walks" aren't sustainable in a large project. Once you've grown beyond a small handful of contributors, you are building a community as much as you are building software. Communities have to protect themselves from people who can't fully join the community, regardless of how much code they can crank out.
Codes of Conduct are important not of themselves, but because we value people more than we value code (or docs, or build scripts for applications, or whatever). That's a point I'm happy with all the time, every day. Technical Merit has it's place, but not above people.
Let me call out a few other names that were critical in moving FreeBSD n this direction: Poul-Henning Kamp started it and gave us a mandate to get it done; Warner Losh and Greg Lehey made the process worth all the fuss and bother. Open Source projects newer than Y2K often end up adopting a variant of the process we went through to govern themselves once they grow past the "handful of volunteers" stage and I'm thankful for all of it.