Why give credit to reviewers?

This is a lightly edited version of an email I sent to pgsql-hackers today.

Josh Berkus asked:

> How should reviewers get credited in the release notes?

Without getting into how the community might decide to do this, I thought it might be helpful to share the reasons why I believe recognizing and expressing gratitude to reviewers is a helpful, useful and gratifying exercise for the Postgres community.

I support crediting reviewers in a more formal way than we currently do for a few different reasons.

First, I believe it’s worth finding a way to say “Hey, you just did something great for Postgres”, publicly, to a bunch of people who could have spent their valuable time and energy in some other way.

Second, reviewers get better at their work by reviewing multiple times – so I’d like to encourage people to review more than once.

Third, reviewers don’t always need to be expert developers, or experts at Postgres to get started, but many people who do open source work have no idea this is true. Public recognition helps make it clear that we have people who give useful reviews and are relative novices.

We also have several different kinds of reviews:

  • “does it compile”
  • style/typo/easily seen bug passes
  • in-depth discussion of design choices, use case, interface
  • complex testing cases
  • performance testing
  • pre-commit checks for more subtle bugs or committer preferences.

All of those, except probably the very last, can be done by people who are familiar with Postgres or its configuration, but aren’t necessarily Postgres or C experts.

Fourth, we have very few accepted ways to recognize contributions to Postgres. Naming in Release Notes is one way this community has consistently supported as a public way to say “hey, you just did something great for Postgres”. The complete list of ways I’m aware of are:

  1. Recognizing major, minor and emeritus contributors
  2. Making someone a committer
  3. Being part of the -core group
  4. Naming authors by name in commit messages (but without consistent metadata, making it difficult to count well)
  5. Naming authors in release notes

That’s pretty much it. That’s great for the people who have already secured positions through seniority, or because they’re amazing C hackers. I don’t know if I need to lay out for everyone the value of public recognition – if you want me to I can enumerate them. But the benefits of public recognition are huge — both in a social and a financial sense.

Currently, the only way I know of to be recognized for work on Postgres that is not seniority or code-related is #1. If you’re a reviewer, there’s almost no chance you’ll be recognized in our list of contributors without some additional, very significant contribution to our community. (Please let me know if I’m mistaken about this — I only know what I know!) Adding names to Release Notes (or some variant of Release Notes) seems like a minor concession for work that we as a community need, value and want to encourage.

We are so few in terms of patch contributors – somewhere between 300-400 people contribute code to PostgreSQL each year based on the names I try to pull out of commits. I haven’t counted how many reviewers we have who do not also contribute patches separately.

Giving people appreciation for the review work they’re doing, for free, is a good thing for everyone. Naming more names helps describe the true scope of our community. Spreading gratitude is good for those who thank and those who receive thanks (like, proven scientifically!). And we increase the number of people who benefit directly from the work that they do here, by giving them something they can point their boss, their company and their colleagues to.

So, when we’re debating how recognition might be done, please don’t lose sight of why this is important in the first place.

AdaCamp Day 2: Welcoming hackerspaces, Being Feminine in Tech and messing around with IR LEDs

This is a recap of my second day at AdaCamp. My second post in this series was about day 1.

Diversity beyond gender

My first session of the day was about creating welcoming spaces that encourage all kinds of diversity, rather than only focusing on gender. Those present were very interested in physical space issues involving hacker/maker spaces or running events. We discussed a set of practices that have worked in several spaces:

  • Let the people involved set the agenda and define the uses of a space.
  • Create an environment where a person of color is not the only person of color when they walk in.
  • Describe a space as a “makerspace” rather than a “hackerspace”.
  • Make events invite-only to establish a welcoming culture.
  • Don’t say “please come if you are a woman”. This is tokenizing language that discourages participation.
  • Invite everyone to organize events, not just attend events.
  • Invite people to events through existing, established groups.
  • Spend time thinking about who and what is missing from a group or space and take action to fix or change.

Patterns of exclusion start long before we deal with them in technology culture.

Being feminine in tech

This was a very large group, so we attempted to focus discussion on some key issues. I was also reminded of “grunch“, the feeling you get when you’ve suddenly been reminded that you’ve got a feminine body.

Our initial set of discussion topics were:

  • Masculinity valued over femininity — how do we get to express a masculine identity in an authentic way and not devalue femininity? Are we expressing masculinity because it’s who we are or because we perceive it as having more value?
  • How “woman” can I be? do I have to switch to their language? what rules do I have follow?
  • How do I make suggestions for a more gender neutral culture in the workplace?
  • Peer shaming if you represent as highly feminine or androgynous
  • Reacting to the hyper masculine by occupying a more feminine place despite its authenticity

Participants shared a series of stories about their experiences expressing feminine or masculine dress, haircut, physical attributes. Most of the descriptions were posed as experiments — “I spent a month wearing dresses to normalize femininity in my workplace and here’s what happened.” The experiments women are running on themselves and their coworkers to try to get people used to women in the workplace are fascinating and shocking. Reflecting on the discussion, I felt like we were back in pre-women’s suffrage, where men were shocked at women working or wanting equal rights.

I also realized that I think about issues with what I wear a lot, but rarely talk about it with my colleagues.

I learned about differentiating between a few different concepts when talking about expressing femininity:

  • Gender policing: comments designed to inform someone that they’re violating an accepted norm. Examples include being described as “dressing too slutty”, aggressive attention when a woman has a shaved head and looks masculine or androgynous.
  • Masculine assimilation: dressing more masculine to avoid unwanted attention
  • Feminine presentation seen as inviting sexual attention: several people described a dramatic change in behavior among colleagues or students when women wore traditionally feminine clothing (skirts, dresses, blouses)
  • Peer shaming: in this context, we discussed concerns with women who shame other women over appearing/acting too feminine, or using feminine symbols like the color pink.

There was a lot more to this conversation. Looking back over the notes, I am a bit overwhelmed at how much ground we covered among so many people in just an hour. This session also led to some other hallway track conversations where I learned a bit more about how individuals are trying to balance their activism with their personal relationships with other women in open source/hardware/culture communities.

Hardware hacking!

I spent some time with the hardware hackers. Several women brought soft circuits, and one person brought a soldering station so that people could try out soldering for the first time. I was trying to get some IR LEDs integrated into a headband, and we had some issues with the shape and the stretchiness of our material. Other folks at the table were making blinking fuzzy muppet/monsters for their badges. Lots of very adorable blinky things were assembled.

I did demonstrate how to troubleshoot LEDs and what IR light looks like on digital cameras. I talked a bit more about medical devices with someone looking into how to hack her own augmentations. It felt a little like a “from the future” conversation. πŸ™‚

Mozilla contributor dinner

I spent Sunday evening having dinner with some Mozilla contributors from France and a couple coworkers. I was probably the only person at the table who spoke only English, reminding me that I really aught to keep up on my language lessons. πŸ˜€

I caught my buddy Diane up on what had happened at AdaCamp, met Delphine’s husband and tried to convince some contributors to lead an effort to have an AdaCamp in Europe!

By the end of the evening, I was ready to collapse and get back to Portland!

Summing up

My last post about AdaCamp will be reflecting on all three of the camps – starting in Melbourne, Australia, then Washington, DC and finally in San Francisco. The event has grown from about 40 people to 200+, and for me, is the most exciting gathering of women in open source, open hardware and open culture. I’ve never been around so many women who share the same values, who are fighting for openness in technology and who are focused on tearing down the many barriers we face to involving more women in our technical communities.

AdaCamp day 1: Allies workshop, OPW, The likeability paradox and depression/activism

This is a recap of my first day at AdaCamp SF. My first post in this series was about the opening reception.

Allies Workshop

I started the day with the 2 hour Allies workshop. Valerie Aurora led this session, with the intention to train a number of new people on how to give the workshop. I took a ton of notes, so here goes, without much editing:

The presentation starts with 15 minutes of introductory slides, which are Creative Commons licensed. We answer the question “why is men fighting sexism important?” There’s a visualization at the start of the number of women involved in FOSS (not many – 2%) and Wikipedia (slightly more, but still not many). We got sidetracked on a slide that had a bit of jargon on it – introducing the idea that we don’t have a gender binary, but for the purposes of the discussion today, “man” will mean “cis white male”, as that’s typically who will be participating in the allies workshop.

I failed to take notes on this (probably because I was intensely paying attention!).. There was a part about the purpose of speaking up. When you decide to speak up about sexism, you’re often not doing so to educate someone who has made a mistake, or is being a jerk. You’re helping a group set a boundary and showing everyone listening in what is ok and not ok. Super important point for me!

There’s a reminder to not be scared of the discussions about to happen. They will be uncomfortable possibly awkward, and that’s ok. When men speak out about sexism they do not get the same responses that women do. They are often publicly supported and privately criticized — the opposite of what happens to many women. The workshops will be a 7-minute discussions, followed by summaries and reflections to the group. These discussions are the times to ask questions, even seemingly foolish questions. Val asks that everyone respond authentically (my word, not hers) when questions are asked. This is a safe place for Allies to find the answers to difficult problems.

Then we went into some example scenarios. We did three scenarios that were prebaked and then one that a participant brought up. I’ll save my notes on these discussions for another time. I really enjoyed the time I spent on this, and learned quite a bit from my group.

The Likeability Paradox

In the book Lean In, there’s a section about the difficulty of being liked vs being respected when you are a woman leader. This discussion was by far the best large-group of the day for me, and extremely well-moderated. I wrote down lots of phrases: bossy, “risk theater”, damning with faint praise, competition between women == disdain, acceptable level of emotional discourse, the difference between “earning respect” and “earning like”, likeabliity == emotional catering, gendered insecurity about a woman’s place, the amount of time it takes to earn respect vs first impression likeability, orgs maximize stability by ignoring these kinds of problems.

There was the start of a great discussion about dog whistle adjectives, adverbs and verbs that subtly and not-so-subtly remind women of their role and place. Are there words we can choose to describe “aggressive” behavior, for example, that are less gendered and more fair to both men and women? Example was asking an employee to “be more aggressive”, when what the manager really meant was they wanted more “decisiveness”. Another person said they started using “inspire” instead of “convince” in their activist work.

There was a short discussion asking “what is respectibility” and how do we unpack that term. This brought up some experiences people have had with being questioned consistently about their qualifications — “the veracity of contribution is questioned” and “what has ‘this woman’ ever done for this community?” Another comment was that by speaking less as a manager, and “planting seeds that employees then run with and come to the same conclusion” a woman had found it much easier to get her employees to do what she wanted. There was quite a bit of discussion about how problematic recommending “speak less” is, even if it is an effective tactic. Upon reflection, I think what was problematic was the framing, rather than the management tactic. Men who are managers clearly use this tactic as well, and it is effective.

Later, Sumana tweeted a link to this piece in Politico about Jill Abramson.

Depression and activism

I mostly came to this session for tips from those in attendance. Here’s what I wrote down:

  • Ask for a big chunk of time off to recharge
  • Structure time for fun
  • Only work when you really want to — give yourself permission to relax when you feel like crap!
  • Consider flipping your “alarm” system to management – start talking about how busy you are when you’re at 70% capacity, rather than 150%!
  • Be selfish with your time and energy

Internal strategies:

  • Try cognitive behavioral therapy (there are great books: Mind over mood, Panic attack)
  • Flip negative self talk, going even so far as to rewrite personal stories in the best possible light

IBM had suicide prevention training for new folks working on-call. A hacker training school has a weekly 2-minute “talk about your life” time.

At AdaCamp this weekend – reception & plotting for the imposter syndrome workshop

I flew to San Francisco yesterday to join 200 women and allies at AdaCamp. This is the third Ada Camp I’ve been part of, and it’s been wonderful to see the event evolve, get quite a bit bigger and turn into a place where I meet coworkers and like-minded nerdy women in an unabashedly feminist space.

I stopped by Heroku before heading to the reception, to meet up with @cathynalee and see my buddies at Heroku Postgres. After a round of a hilarious card game where you fight rounds to the death (with dice of course) with strange heros (mine was a Barbarian) and acquire coins to win, I headed off to the Google SF offices for our reception.

I’d never been to the space before. The view was pretty great.

BMNbHA7CQAEqs1K

Many, many old friends were there. Having the opportunity to sit and mingle and be silly for a couple hours was great for calming me down, and wonderfully restorative to be able to just relax with friends I work on so many difficult problems with, week after week. I also saw several friends from Portland, who I don’t see often enough at home. I ran into Sarah Sharp, who gave me the stats on her work with the Gnome Outreach Program for Women and the Linux Kernel. In short: In 13 days, 374 patches were submitted, and 137 patches were accepted. Six women were accepted into this round of OPW. Fantastic work on the part of the Linux Kernel contributors and all the women who applied.

I also got to mingle with hackerspace founders from Seattle and San Francisco. I’m just a supporter of hackerspaces, rather than a founder, so I felt a little bit like a fangirl joining their conversations. I also met the creator of Hate Map, a sentiment analysis heat mapping tool.

And, I met a fellow coworker from Mozilla for the first time and we chatted about PyLadies, PyStar and grassroots education efforts for adult, beginner programmers. And then another woman joined us and we veered off and talked about Texas, how insane the advisory system is in high schools that steer women away from tech and science classes “to keep balance” in the girls lives (!!??!?!) and learning to drive as an adult.

As the party wound down, I met with some organizers of an imposter syndrome workshop. My advice to women who feel like they’re frauds: pick some badass skill to acquire and spend a couple days mastering the basics. For me, my eyes were opened to the power of badassness and the confidence that it inspires when we taught PyLadies how to use git. Several of the women who have taken these classes have come back to me with stories of impressing their coworkers, getting jobs and overall just feeling like they belonged in tech circles and discussions because they could confidently talk about git workflows.

Overall, great conversations and I’m looking forward to more amazing ones over the next two days.