Wednesday, December 5, 2012

In Defense of Anonymous Proposals

Recently, the Code4Lib community has been working to write an anti-harassment policy and combat gender discrimination. One proposal (full credit: coming from JSConf EU's excellent strategy for increasing diversity, which I in turn learned of from the ever-vigilant Andromeda Yelton) was to have anonymous conference proposals but it was quickly shot down on the C4L listserv. I don't mean to pick on C4L but I wanted to discuss briefly why I think that's a mistake.

Anonymous proposals aren't just one measure among others to increase diversity, they're vital. JSConf EU notes "This is crucial. Even if you don’t think you are biasing against anything or anyone, unless you anonymise CFP submissions, you will apply your personal bias." (emphasis in original) Why? Anonymous proposals circumvent most of the latent biases we all have: gender, race, culture, etc. are difficult to determine from an abstract. What's more, underrepresented parties are more likely to submit without fear of judgement or judgement's liberal sibling, tokenization. Anonymization shields selectors from their biases and proposals from discrimination.

The Counter Arguments

Few people disagree that anonymous proposals have benefits. But do their benefits outweigh their disadvantages? Anonymity's detractors tend to argue that knowing someone aids in evaluating speaker quality. I find that more of an excuse to reify bias than a legitimate contention. To run down the list:

A) Obviously implicit bias is still at play,
B) The subset of people you know or have seen speak echoes previous biases–if a disproportionate number of men tend to speak at Code4Lib, then the people you've seen speak is going to be disproportionately male and thus your supposedly informed selections make for a poor representation of the full community,
C) If you know someone but haven't seen them speak, you may be inclined to vote for your friends and not necessarily on quality.

It was also mentioned that anonymous proposals go against the "openness" of Code4Lib. But the end result of openness is more important than some deontological essence attached to our actions; if openness in this instance supports bias, then we should be closed. In some ways, one can be more "open" when anonymous than when afraid of discrimination. Also, my identity as a voter is not revealed; how come that is not considered a threat to the openness of the community? Anonymous proposals do not damage openness if they allow a more representative population of a community to present.

All this said, are anonymous proposals always the right choice? Maybe not. I'm part of a conference planning committee that isn't evaluating talks anonymously. I'm not entirely clear why but we did at least discuss it. You wouldn't want to select keynotes anonymously. But for most sessions, anonymous proposals have proven to yield more diverse speakers. I have yet to see reports from conferences indicating that anonymous proposals lower speaker quality. That contention appears to be more hypothetical than real. In the end, what is more important? Making a real commitment to diversity or ensuring we can vote for people we know over strangers? I'd argue that allowing anonymous conference proposals is beneficial even if it decreases the quality of speakers a little.

1 comment:

  1. I think the idea for LITA Forum is that we can have an anonymous voting period for community feedback, but ultimately the committee knows who is who. This is how ER & L does it and others.

    I couldn't agree with you more that in the case of an entirely community selected program such as Code4Lib, proposals should be anonymous for voting. This doesn't help everything--well connected people can still encourage votes, but having seen a few years of Code4Lib talk voting, you can see pretty clearly that certain people's talks are *always* selected, even if they don't have much new to say. Maybe that's ok, but I am guessing there's a ton of inherent bias in people's votes whether or not they realize it.

    ReplyDelete