Diversity on the governance teams


#63

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.


Brainstorming: community subteam
#64

I didn’t call for immediate action on a weekend, but for availability after a major announcement. That alone would have been a good reason not to announce things on a Friday evening that are bound to lead to disagreement.

Imagine deploying on a Friday evening and telling your users that they have to wait until Monday because of that. That wouldn’t fly.

Sadly, by its plea for constructiveness, it comes off as demeaning other efforts as not being just that.

I’ll remind you again that I have given the issue much thought, that I do take action in that regard and I do have patience - but that has an end at some point. And that point being where core becomes harmful to this action.

Stopping to tone down those with a rightful reason for anger is the first actually a part of good outreach efforts. Give me something to work with, instead of pleas for prolonging further. Anger can be a very constructive thing.

I’m not interested in suggestions, I’m interested in activity. And that activity starts by an acknowledgement of damage done.

Mind @jdm’s post: asking me for fixes for damage inflicted on my efforts is also bad. I’m happy to talk about any other ways of action, I proposed a quick fix so that everyone can sleep at night. It’s not my job to suggest further.

Currently, I’m the only one with an actionable proposal on the table.

Weak suggestions of future efforts don’t help.

In my opinion you are misappropriating the term diverse here. We’re not talking about structure, but people.

Have you considered specifically targeting marginalized groups? Contact any of the many outreach groups and try to encourage them getting into that talk.

Basically: read up on things, even if the wiki is called “geek feminism” and invest time speaking to specific groups. Advertise your diversity if you manage have get any. Train people.

I agree on that, but then, it’s the damage already done by them which must be complained about for them to take that into account. The best people to oppose these practices are the ones hired by Mozilla.


#65

Anger can be a very constructive thing.

But it very often isn’t. Fire can also be a useful tool, but people who aren’t careful using it end up hurting those nearby and accomplishing nothing.

The tech feminism scene has enough anger already. It’s not helping the cause and it’s causing extreme burnout among people like me and Steve who try to help, get zero credit (of course we’d be mocked if we admitted to needing any), and as a bonus also get much worse from the “other side”. I’m not saying we deserve medals, but this problem has been on our radar for a very long time (have you heard of Graydon and Tim?), it has been the subject of many discussions as well as concrete actions taken, and most of that had no effect except pissing off people in every direction. That’s not in any way an argument that we should stop trying. But maybe it means your anger is counterproductive in this case. You already have our attention, but you’re acting like we still don’t give a shit and never did. That is a massive slap in the face.

By the way, many pages on the Geek Feminism wiki are truly terrible. We need a plurality of feminist thought where substantive debates are tolerated. Not social-media-based bullying to conform to a naive worldview that actively reinforces patriarchy. And please don’t lecture me now on how men are clueless about gender and need to shut up. I’ve heard it all before. That’s a weak heuristic, not an ironclad rule. I have put in the effort to “educate myself” and the result is that people with a simplistic understanding of the same issues yell at me for having more nuanced views, while arranging the terms of debate to put themselves beyond criticism. (I’m not straight or gender-conforming either, and I have significant mental health issues that come into play here – but I’m still a “privileged person” and our mental health is just a matter of “comfort” in social activist circles.)

I deeply resent that you are trying to drag this community I love down into the gutter of scorched-earth identity politics.

This is a painful and personal topic for me and I hope it is abundantly clear that these are my personal views, not those of Mozilla or the Rust project. I’m not on the core team, or the moderation team, or any other Rust team, and I don’t want to be, and I ruffled a lot of feathers by insisting that the moderation team should even exist. I stopped contributing to rust-lang/rust largely as a result, so don’t think that I hold them blameless.


#66

Had you actually had read the slides I posted, I refer to both Tim and Graydon. Yes, I heard of them. Yes, I read all they wrote. Steve gets credit from me in spades and it’s very painful to me that this happens around him. I wanted to keep his name out of this.

I haven’t lectured you in any way and I don’t intend to. I got asked for advice person to person. If you have better advice, please post it.

I don’t do this and I am as much an active member of the community as you are.

I appreciate your actions, please appreciate mine.

I don’t know what you want to achieve with this post. It reads like you are assuming that I am some community newcomer coming trying to just push an agenda. Or you just want to put me back into my place. I really don’t know.


#67

The team did respond in the original Twitter thread, and there have been people in both the core and moderation teams responding in this thread.

I understand that you don’t think the response has been sufficient, but I really don’t know what possible response their could be in such short time short of simply pulling the announcement of the subteams, and as I described, I think that would a step back, not forwards.

I agree, deploying on a Friday can lead to these sorts of problems.

Of course, I think that part of the issue is that no one anticipated this announcement would be controversial. And I don’t think that any of the individual choices are controversial either, it’s only the aggregate result that gives you pause.

I apologize, that is the opposite impression that I had meant to give. I can now see how it would read that way, but my intent was only to discuss my post and that all criticisms I had given were intended to be constructive in spirit.

Perhaps in certain circumstances, but in other circumstances it can be quite corrosive.

Sorry, I’m not trying to ask you to solve the problem yourself, but just trying to get ideas for what would help. Having more than one available path forward can help to find something that works for everyone.

I just want to make sure I understand you. The suggestion you have is to roll back the change, moving from a structure with a core team and subteams back to one with just the core team, and go back to the drawing board on the subteams?

I am talking about people as well.

The core team has not changed from before the announcement to after. It has 8 people, who by my count consist of eight men, seven from the US and one from Australia, with no under-represented minorities as far as I can discern (apologies if I have mischaracterized anyone’s gender identity, nationality, or ethnicity).

With the addition of the subteams, the leadership structure now includes people from Germany, Austria, Poland, Russia, Romania, and India. I would say that that is a substantial increase in diversity from seven people from the US and one from Australia.

Now, that doesn’t mean there isn’t further to go, one of the biggest omissions being any women on the team, but I don’t see how reverting the decision and thus reducing diversity on the team, and then having to wait for outreach efforts and community building to help find sufficient candidates to join the governance team would help.

Well, that talk already happened at the 1.0 release party/meetup. But I do hope to be able to do more; there’s only so much ground you can cover in a one-hour long talk, there’s much more to teach.

I have found a few local groups for teaching women in software development; I have not found any for any other under-represented groups. Most of the groups for women appear to be focused on web development, and are only open to women, so I don’t know if they would be interested in having me give a talk, but I will reach out to see, or to see if they’d be interested in advertising future Rust Boston meetups to their membership.


#68

The team felt like mentioning my group as an explicit example for diversity work. This was the first time the team spoke to us in any team capacity. Do you see my point about neglect there?

I appreciate that sentiment. What is your opinion on a concrete way forward? What time frames does it have? What is the commitment? When do you consider it successful or failed?

That pretty much sums up the problem. It hasn’t been seen as a problem. A joint announcement instead of a link on twitter would have fixed a lot of things.

My current suggestions is to move back on commitment of to the teams and make them clearly temporary with explicit goals.

Why haven’t you considered that before the party? That would have been the moment for a show of force. We’re far to focused on “and now we finish this milestone and then we finally do the outreach work”.

We did most of our outreach through Rails Girls. Ask those groups to propagate your invitation and put it into their channels. Make sure you get good standing with those groups and they will reflect you message. Also: yes, they only focus on web, but maybe not everyone is interested in web after a while? The Berlin clojure community for example is run by a Rails Girls training group. (Which makes local Clojurists rants about Ruby very funny)


Organizing Community Organization
#69

It would probably be useful @skade, if you could describe in what way the team announcement was directly damaging your efforts. That might allow others in this thread understand in what way the team announcement was undermining diversity efforts.

I’m not sure that it has been quite clear that this was your suggestion, but it certainly sounds reasonable to me personally. Is this something that the Rust team could work with? Could you express, @skade, how this would help repair the damage to your and possibly others’ efforts?

I must say that I’m a bit surprised that if this has come up in internal discussions (i.e. lack of diversity) that no-one suggested to Mozilla to pay for a member to work on diversity. When you want to conquer the world you surely need some diplomats?

That member might have been able to avert the disaster that the team announcement was. Basically all women coders that I follow on twitter have gagged on the all-male teams.


#70

I think this hits the nail on the head. Each member of the teams seem to be excellently chosen, but as a whole it definitely doesn’t look good, and quite rightly so. I really hope it was just an honest mistake, but in the interests of moving forward productively, I’m going to treat it as one.

This isn’t really going to solve itself overnight. I might be blind (correct me if I’m wrong) but I can’t think of any long-time, committed member of the community who isn’t male, let alone anyone willing to spend the time as a volunteer on those teams. This seems like a self-sustaining trend that many in the community, including myself, seem to have been blind to. Suggestions like getting advocates from outside onto the moderation team, and having a more diverse community building team could help in the initial stages. This will probably need support from Mozilla itself, before we can establish self-sustaining diversity in the Rust community.


#71

I did describe it. Local loss of trust, undermining of our efforts to show us as a diverse community and actual potential team members taking another go at thinking whether they want to be involved. No one really likes doing diversity work in a non-diverse setting.

It would show a strong signal that the current teams have to be like they are, for lack of wanted for staff that was failed to train up before the release. It would lead to more transparent and clear handling of the situation and make it clear that this is an acknowledged issue.

It would also make it easier to clearly state goals.

I am fundamentally opposed to a “diversity team”. That means everyone else has a different job.


#72

Yes, if that was the first time the core team discussed your work with you, I can see why you feel like you had been neglected. On the other hand, the fact that they mention it mean that they have been listening and are aware of your work.

I think that one of the things that was missed in setting up the subteams is having one responsible for community building. It isn’t an aspect that the core team has had much time to spend on in the pre-1.0 push, but now that 1.0 is out, it’s an ideal time to spin one up, and dedicating a subteam to it would help it scale a little bit more than it just being a part of the responsibility of a couple of core team members.

Moderation and community building are really two very different things, so I think that a separate subteam would be more appropriate than trying to add that to the responsibilities of the moderation team. Setting up a new subteam and delineating its responsibilities couldn’t happen instantly, but it would probably be possible to form one within a week or two, and then give it a couple of weeks to get up to speed and start work; one thing to recall is that while the subteams have just been formed, in many ways they are responsible for defining their own policies and procedures, so even after they are formed, it will take a couple of weeks for them to figure out how they want to operate.

Now, I don’t want to presume to have the only answer for how the core team should do its outreach and community building. Perhaps, rather than forming another subteam, the core team would prefer to keep responsibility for outreach and community building efforts for now, and that would be reasonable if they are able to have the bandwidth to deal with it.

Beyond that, the next concrete action I would expect is actual outreach to such groups. For example, perhaps offering internships via Outreachy, or working to coordinate speakers at meetups and conferences targeting under-represented groups like AdaCamp, or maybe sponsoring minority fellowships via something like the GEM porgam. That will take some more time and work with outside groups to set up, so I don’t expect any announcements immediately, but could happen within a few months. Mozilla is already an Outreachy sponsor, and has several current interns, so having the Rust project get involved in that in a future round would be a good step.

Yes, I think that a joint announcement after having taken some concrete step forward, like one of the above I mentioned, would be better than just one apologizing, disbanding the subteams, and not providing anything concrete since the concrete steps are all going to take a little more time than just a day or two to implement.

Personally, I wasn’t involved in organizing the meetup, I was just speaking. The organizers included one woman, and there were more in the audience; however, it did have the usual skewed gender ratio at these types of events. My experience there, and the extra light that this thread has brought to the very skewed ratio currently in the community, has made me realize that indeed, active outreach is probably more important than just offering content and hoping that people show up.

Indeed, in fact, many of the people who ran the recent Rust Boston meetup are in the local Ruby community. I will see who I can get in touch with.


#73

My complaint isn’t about lack of community building directly. That’s actually doing quite fine - we have many usergroups and an extremely active IRC and so on. The core team has done a bad job at ensuring the diversity of the core teams and subteams. Community building might be a path to change that, but it is a different thing. Formulating what the goals are comes first.

A community building team also doesn’t necessarily ensure diversity.


#74

Your actionable proposal has its own faults too. Setting arbitrary boundaries and then saying that you’re the only one bringing stuff to the table doesn’t really add to the argument.

Multiple people have already mentioned that removing the governance structure would be a step back.

I have put forward various other proposals. That I’m not willing to push forward on them until the core team gets here is a different matter, and it doesn’t make them weaker.

Agreed. But my hope with this is that the community building team will actually notice the problems with the community. As others have mentioned, community wasn’t a focus before 1.0, and this could be a reason why this wasn’t noticed in the past. I mean sure, we all cared about the community and helping it grow, but I bet many of us were focusing on the code to really give some thought to it.

Having a team with explicit focus on this; a team that regularly discusses these things; and takes into account feedback from community organizers; would be a way to safeguard us from this stuff happening in the future. I’m not sure if I’ve mentioned this before, but there is a lack of communication/connection between the online community and the offline one. People involved in local events and stuff (eg you) need not necessarily be active online and vice versa, and online there is little awareness about such efforts made outside of the SF meetups (which get aired). The online community mainly focuses on discussing features and the color of the bike shed and technical minutae; the offline community seems to do a lot of outreach and/or diversity efforts. Clearly having both working together would be what we want, but it hasn’t happened so far.

A community growth team would be an explicit bridge here. Sure, I’d love if the communication gap was bridged implicitly, but I don’t see that happening just like that. Of course, there are probably other ways to bridge this. Perhaps better ways.


#75

You are right, I overstepped there. Sorry. I’ll wait for further inputs.


#76

I looked up a number of large open source projects to get an idea of the composition of their teams. Most had very little information about who is actually behind the project, but here is a list of sources I found. Many of them are old and out of date, but I included everything I found.

I will say that I am not surprised at the apparent level of gender diversity I found among these projects. It seems accurate to say that Rust is not alone in this problem, which does not make the problem Rust has any less of a problem, or solving the problem any less the Rust community’s responsibility. I am surprised though that anyone is particularly put off by the composition of Rust’s teams; myself, I felt like I knew the score and expected nothing else.

I’d also say that Rust has a rather excellent community despite lying at the deep end of a vortex of awfulness - open source systems programming projects are not associated in my mind with friendliness, inclusion, and empathy, though the Rust community is. Bluntly, what I expect from projects like Rust is aggressiveness, machismo and self-satisfied superiority (as an aside, I have found myself very unfairly hostile when I’ve felt I was being condescended to, I think as a result of a trained fear of this which really does not exist here). Rust is not like that primarily because of hard work put in by Rust core developers over the past several years.

But I do think it is past time that the project redouble its efforts to include and welcome. I would say that it has not just “posted the CoC,” but has made serious efforts to enforce it. That is a negative action though, only counteracting the harmful efforts of others, and not in itself a positive move.


@skade, thankyou for your most recent post. I think we share a common desire for Rust to be a different kind of community, but some of your posts have seemed unfairly insistent and accusatory. I fear the possibility of silencing other people who would contribute to this conversation but for fear of being the target of an aggressive response. Your most recent comment makes me feel much more like this conversation can come to a positive closure.


#77

Thanks for making the work to collect these! I’d like to note about the MRI team that japanese names are hard in that regard. and I’m actually rather comfortable with their layout. Also: it’s a committers list, not a team list, there’s also release managers on that team which have less raw commit numbers. I’m couldn’t find the official team list either.

I don’t want to go into details why I have an issue with the Rust team beyond what I already said, I feel like that would only reignite. I also feel like I made all important issues clear. Fetch me via IRC query or in some other fashion if you feel like you have open questions.


#78

I find this whole discussion not constructive at all. There is nothing wrong with having a team page and it’s not the fault of the Rust team in any form that it’s not diverse. Most projects in this world start out with a group of friends or colleagues and grows from there. These groups typically are not diverse.

In my mind to expect Rust 1.0 to have a diverse team is ridiculous. CPython does not have a significant percentage of active female contributors from what I know and nobody faulted the team for it after more than 20 years. Would not have been a good idea anyways given that the Python community is one of the most diverse when it comes to either programming languages or open source projects.

May I please reiterate (since this has been apparently lost in this discussion) that the Rust community has always been about inclusion and tolerance and a good tone between participants? This discussion is not exactly a good example of the friendliness of our community even if it’s in the name of inclusion and friendliness.

From my experience with the Rust team and the community this is generally all about hearing each other out and coming to consensus. There have been controversial discussions in the past (integer suffixes, the 1.0 release timeline, everything including strcat :P) but they were pretty much all resolved without people getting hurt.

I think this discussion has the opposite effect. It’s a controversy that nobody needed and helps nobody. I would suggest that next time a controversy like this comes up we all collectively let it die down for a few days and then look at it in a calm manner without getting at each other’s guts.

So can we just all go back to being friends and evolve the community in a healthy way?


#79

It absolutely is. If the team only consists of men, it’s the fault of those who only out men on that team. I’m not saying that it was done on purpose but the responsibility for it surely lies with those who came up with that team roster.

The fact that other project are also not better at diversity is no excuse. Using well established projects and structures as the bar for younger projects will lead to never making any progress at all. Especially new projects like Rust have a big opportunity to be better.

There have already been posts in this thread that prove otherwise.


#80

People do not come up with a team roster. Team rosters happen naturally through whoever engages over time. I much rather have a released programming language with lack of diversity than a non released programming language with a lot of diversity. Diversity is pretty irrelevant to the core functionality of a programming language.

I also find it weird that diversity is something that has such a big focus here all the sudden to the point where people reject the entire project due to lack of it. I’m pretty sure you would still go to a dentist even if 100% of the team there is female.

Actually it is. If you think that programming languages in general need more diversity then I suppose you take this to some overarching initiative or you apply the same scrutiny to every project out there.

I also want to point out that more important than diversity is motivation to the project and a friendly attitude in the team. You can’t just put a token female developer on the team and expect this to contribute positively to the overall project. Keep in mind that at the end of the day this is an Open Source project where many contribute without monetary rewards to it. It’s their own time. People come naturally to such projects, not because someone made them to.

I don’t think they prove anything, they just show that people love controversy and take a part in it. Especially if it’s about a topic like this. Everybody wants more females in programming and I feel like complaining about the status quo is a pretty easy position to have. Actually contributing to a change there not so much.

The reason there are not more female developers in the Rust team is largely a result of there not being more females in computer science unfortunately. To fix this: support PyLadies, RailsGirls, Women Techmakers, any other organization out there that helps getting women into tech. Be nice and friendly to everybody and support whoever comes into communities as a newcomer. Unfortunately though this will probably only contribute to a raising female developer base for compiler development and language design in years and not days.


#81

The reason there are not more female developers in the Rust team is largely a result of there not being more females in computer science unfortunately.

I disagree, because we seem to have less female developers in Rust even compared to field average.

On the other hand, my impression is that Rust seems to have more people of color developers compared to field average.


#82

Don’t forget that the field is “programming language development” not “IT in general” and there the average seems to be very low from looking at other languages.