For the last two years, I’ve been going to the conferences the Ada Initiative has put on for women in open technology and culture. It’s a really awesome experience to be in a room full of hundreds of techie, geeky women. There’s everyone from open source developers to security analysts, hardware hackers to fan fiction writers. Heck, I even met a documentary producer at the last AdaCamp in San Francisco.
One of the most important things I learned at Ada Camp was how to combat impostor syndrome. It’s basically the feeling that you’re not really that smart, that your accomplishments are just luck, and some day, someone is going to find out, and you’ll get humiliated/fired/shunned. It’s surprising the number of highly successful tech women who experience this feeling. I used to have the worst case of impostor syndrome, until the women at AdaCamp taught me how to fight it.
The LKML thread where I stood up against verbal abuse has been winding down. I’ve posted a summary of my position. As I noted, I have been listening and learning from the arguments on the thread. In the course of the thread, my personal viewpoints have changed subtly, and I’ve chosen to push for change in areas where I think I might actually make headway. It wouldn’t be a discussion if no one changed their mind.
Nothing is going to change overnight in the Linux kernel community. As Casey Schaufler pointed out, I cannot force or demand change. I’m merely asking to discuss the possibly of change at the Linux Kernel Summit.
Thank you for listening and debating on this subject. Open discussion can only improve our community.
I’m standing up against verbal abuse on LKML. I will happily stand alone, however you can also support this cause. Please speak up, either by resharing this post, or commenting on this post with words of support. If you dare, you can also reply to my LKML email.
“Where do I put this fire? This bright red feeling? This Tiger Lily down my mouth? He wants to grow to 20 feet tall… I’m so tired of being shy; I’m not that girl any more. I’m not that straight-A anymore.”
Examples of verbally abusive behavior on the Linux kernel mailing list:
You are racist. You are sexist. You are homophobic.
Now stop. Analyze your response to my words. Is your heart racing? Do you feel tense, ready to fight? Are you already in my comment section, blasting off a response about how you have plenty of black/gay/disabled/women friends and of course you don’t stereotype? Are you ready to find holes in my argument and punch right through them?
If you want to be a true ally, you need to realize that this type of response is happening. When someone questions you, or calls you biased, you immediately have physical and mental urges to defend yourself, to fight and stick up for yourself. This immediate defensive response is not conducive to having a well-reasoned discussion about whether you actually have a bias. You are likely to shout at your ally, find excuses, and otherwise alienate them. If you truly care about your allies, you need to learn how to suppress that response.
This week, Facebook came under fire for not pulling several pages that promote violence against women. Pages like “Violently Raping Your Friend Just for Laughs” remained up, even after they were reported to Facebook. After a dedicated campaign to get ad sponsors to pull their ads, Facebook said they would retrain staff to take down pages that promote gender-based violence.
That’s not enough, in my opinion. Sending the message that violence against women isn’t socially acceptable on Facebook is a step in the right direction. However, silencing the conversation on social media does not change how our culture views violence against women and rape. Thoughts on how to prevent rape and violence are below the cut.
A month ago, Amanda McPherson and Greg Kroah-Hartman from the Linux Foundation asked me to coordinate an internship program aimed at getting more women to participate in the Linux kernel. In order to be considered for an internship, the applicants need to submit patches to the Linux kernel, and get them accepted.
The results have been amazing:
41 women applied for 6 Linux kernel internships.
In 13 days, 374 patches were submitted, and 137 patches were accepted.
Diff stat for accepted patches:
105 files changed, 3889 insertions(+), 4872 deletions(-)
At AdaCamp D.C. last year, there was a really awesome session where we created a “Gender Gap Timeline”. Basically, there was a timeline that included early childhood, high school, college, and career. Each woman was given a pink notepad and a green notepad. They recorded positive experiences with technology and the tech community on the green notepad, and put negative experiences on the pink notepad. The page was placed at the woman’s age where the experience took place.
It was really useful to see the spikes in positive and negative experiences laid out in chronological order. For the tech women who made it through their careers to attend AdaCamp D.C., there were a lot of good experiences in early childhood. There were also some very common negative experiences, and even trivial negative experiences with a person of power (teacher, parent, mentor) stuck with the women.
Now the people who put on the session have made an online version, and it’s pretty awesome. I think they may be looking for people to help out with it, so contact +Georgia Guthrie if you’re interested in hacking on it.
Oh, I just came up with a really good metaphor for how to create a good looking patchset:
A patch should be one logical change. For example, you should put all whitespace changes in one patch. If you’re changing variable names to avoid CamelCase, you should do only one variable name change per patch. Basically, you’re breaking up patches into the smallest logical unit necessary, in order to make it easy to read and review. A patch that’s over a hundred lines is going to be pretty hard to review.
Think of it this way: you’re preparing a big meal for a friend, and you have many different dishes you want to serve them. You don’t throw all the food into one big pot and serve it to them. Instead, you serve each part of the meal on separate plates, so that they can admire your cooking, and you take the time to explain how you prepared each dish, and why it’s tasty.
A good patchset is like a well-prepared meal. You provide a menu (cover letter or patch zero) that explains what you’re going to serve (what the overall goal of the patchset is), and bite-sized portions (one logical change per patch) beautifully arranged (documented, signed, and up to coding style) in a particular order (numbered patches, with bug fixes and refactoring first).
It takes a while to learn how to cook a full course meal, and even longer to figure out how to present it with a flourish. People new to Linux kernel development should work on sending bite-sized, smaller patches, with one logical change per patch. Once you’ve got that down, you can work on presentation of multiple patches.
Hooray! +Linus Torvaldspulled my first patchset sent directly to him! Usually I send +Greg Kroah-Hartmanpatches, and he sends a pull request to Linus. It’s a trivial thing, but it means my pull request flow is fine for more than one maintainer.
ReportingBugs looks much better now, and I hope this rewrite will help explain who to contact about bugs, and what time frame to expect responses back.