As I said before, I consider this very announcement from friday a violation of the code of conduct.
I don’t see how it does. There is noting in the announcement that harasses, demeans, or fails to provide a safe and welcoming environment for anyone.
It would be preferable for their to be a greater diversity on the various Rust teams. This is an unfortunate situation, and at least three people on the moderation team and one on the core team have written in this thread to agree that the situation is unfortunate and discuss what to do about it.
But I don’t think that appointing teams that have been selected from the pool of people available based on their existing involvement and desire to participate could be seen as a violation of the code of conduct. It is unfortunate that there are so few women and under-represented minorities involved in the project, and that needs to be fixed, but the governance structure for the project also needed to be expanded. The previous core team, which was the only governance structure in place prior to this change, was being spread too thin to be able to effectively handle both the technical decisions in a number of areas as well as community moderation issues. Expanding to several subteams, including a dedicated moderation subteam, has been a step forward; there are more steps forward to make, but I don’t think that this has been a step backwards.
I thought the core team is just for technical things? One or the other.
The core team is responsible for setting the overall direction and tone of the project, making cross-cutting decisions that affect several subteam areas, and forming new subteams as necessary. So yes, forming a new subteam for the purpose of community building would be something for the core team to handle.
Here again: I’d like to shortcut the discussion with you. We have different opinions and ideas here. Fair enough. The core team itself has damaged my projects. I’d like to hear their plan on healing that.
You seem to expect the core team to be able to fix this problem in an instant, or at least come up with a proposed fix, during the weekend after a major release. I think that that’s a bit unreasonable. Remember, for a large portion of the team, this is their day job; they need time off, time to be with their families. Demanding that a problem is immediately addressed on the weekend after a big release is a bit unreasonable.
And I don’t think it’s something that can be solved so simply. The selection of people on the subteams has been made based on current involvement and desire of the existing community. I have not heard that anyone who is both qualified and interested has been passed over. Expanding the reach of the community will take some dedicated, hard work. While the current lack of diversity on the various teams is unfortunate, it is fairly reflective of the current community; building up that community cannot be done overnight.
I think that demanding immediately dismantling the new subteams until the problem is solved would do more harm than good; the composition of the governance body has only been made more diverse in the introduction of the subteams, not less. Previously, there was only the core team, now with the sub-teams there is greater diversity of people involved in the project governance, even if it is still not enough.
I cannot think of any other immediate action that would help; that seems to be the only one you have suggested. If there were volunteers to join the teams, who were qualified and trusted, then appointing some new members may help, but I have not heard of any who are available at the moment.
Rather, to be more constructive, I think we should discuss what needs to happen to improve the situation in general, to improve the diversity of the pool of candidates to choose from.
There have been several good suggestions already; reaching out to organizations that already focus on these issues is a good one. What else can we in the broader community do? As a member of the community who is not on any of the core teams, what can I do to help make the community more welcoming, more encouraging, and get more participation from under-represented groups?
So far, I have started by giving a talk at the Rust Boston meetup that was targeted for complete beginners. I hope that introductions from the ground up may be helpful for people who are interested but haven’t yet made the plunge on their own; of course, there’s only so much that can be covered in a single talk, so I hope to be able to do more introductory talks on specific areas as well. I’m also thinking of doing a talk on contributing to Rust, how to make your first pull request, to make it easier for people to get more involved in the community. But none of that is specific outreach to underrepresented groups, just trying to lower the barrier to entry in general.
Since you seem to have some good experience with this, I’d love to hear what else would help to bring more people in. I’ve read your slides, but would love some more details on some of the examples, such as the"Active Outreach" bullet point.
I think that one of the other suggestions in this thread, creating a dedicated community building team, would be a good one. From what I’ve seen, the community building effort so far has been focused on providing forums, like IRC, Discourse, the technical governance of the project, and promotional materials shared on various social media like Twitter and news aggregators like Reddit and Hacker News. Other community building efforts have been local and organic, but not particularly tied to the core project. Right now, there is no part of the governance structure dedicated to supporting outreach efforts, teaching, meetups, and the like. I think that maybe adding a community subteam would help indicate that this is an important area of focus, and give a chance for those efforts to feel like an integral part of the project rather than separate, isolated, local efforts.
One other factor that should be considered is Mozilla’s hiring and management practices. As the main sponsor of the project, employer of the majority of the core team, and one of the only places that currently employs people full-time to work on Rust, how Mozilla decides on candidates to hire, and how it manages its employees and retains existing employees, has a strong impact on the makeup of the project. For better or worse, it’s a lot easier to be a top contributor, and thus eligible for the leadership teams, if you are paid to do so full time. I am not at Mozilla, and so I don’t know much about the hiring process and candidates, but some issues that tend to be endemic to both Silicon Valley culture and open source projects can skew the selection process in favor of young white men. Considering existing contribution to an open source project as a large factor can mean that only those who have the time to spend on projects outside of their job are able to be considered, as well as skewing it in favor of people who already feel comfortable in the community and making unsolicited contributions. And a high-pressure, work all hours at the expense of your life mindset that sometimes affects Silicon Valley culture (and the tech industry in general) can also further marginalize people who have families and lives outside of their job (and @skade, please do recall this when demanding immediate action on a weekend). I know that there have been some core contributors to Rust who are no longer involved in part due to the pressure involved; hopefully a more sustainable pace and level of pressure can be sustained, especially now that 1.0 is out. This is not something that the broader community can help with, nor anything that can be fixed immediately; and perhaps these issues have been addressed, I am not at Mozilla. But I think they should be kept in mind.
I’m hoping that this message has come off as constructively as possible. I think that this is a big issue that needs to be addressed, but I think it needs to be addressed thoughtfully and with patience.