Tag Archives: mentoring

Open source needs you!

While there are probably as many avenues into open source as there are open source contributors, two interesting programs are gearing up in March 2016 and I want to draw your attention to them. These both offer routes for new contributors who’d like to be paid, as well as opportunities for people and communities interested in mentoring.

Outreachy

Outreachy helps people from groups underrepresented in free and open source software get involved. We provide a supportive community for beginning to contribute any time throughout the year and offer focused internship opportunities twice a year with a number of free software organizations.

Currently, internships are open internationally to women (cis and trans), trans men, and genderqueer people. Additionally, they are open to residents and nationals of the United States of any gender who are Black/African American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, or Pacific Islander. We are planning to expand the program to more participants from underrepresented backgrounds in the future.

Applications for the program are now open and the deadline for applying is March 22, 2016. Free and open source software organizations and supporting companies are invited to express interest in sponsoring the program this round by March 22.

Read more about Outreachy and get application/sponsoship information on the Outreachy website. One thing that I think is really nice about Outreachy is that it is an internship that is not limited to students and recent graduates but instead focuses on underrepresented communities. I’ve never participated, but students and mentors alike have told me that it is a great program that fosters a deeper mentoring connection than many similar programs. I particularly love how communities around Outreachy really go out of their way to help the interns network and get access to job opportunities.

On a personal note, the Python Software Foundation currently has money that could be earmarked for Outreachy but insufficient mentorship available to sponsor an Outreachy intern. If you’re an experienced mentor and Python contributor, or willing to volunteer as an administrator who could try to entice and coordinate such people, please drop me a line at terri(at)toybox.ca and I’ll try to get you connected to the right folk.

Google Summer of Code

GSoC2016Logo: a sun containing the characters "</>" with the words "Google Summer of Code" beside it

11 years, 103 countries, 515 open source organizations, 11,000 students.
Over 50 million lines of code.

Spend your summer break writing code and learning about open source development while earning money! Accepted students work with a mentor and become a part of the open source community. Many become lifetime open source developers! The 2016 student application window is March 14th to 25th.

Google Summer of Code is open to post-secondary students, age 18 and older in most countries.

You can read more about it on the Google Summer of Code website. It’s a pretty neat program: Google chooses a set of open source organizations to participate each year (2016’s orgs should be chosen by the time this post goes up!), then those organizations in turn get slots and choose students who they’re willing to mentor. Google pays the students, the open source groups provide the mentoring, and the students provide code and fresh ideas.

I’ve been involved with GSoC for a number of years, as a mentor for GNU Mailman, I did a few years as a mentor and administrator for Systers (a women in computing organization; I no longer mentor for them because the time commitment wasn’t possible), and the past few years I’ve been the organization administrator for the Python Software Foundation. It’s a great program that has really had a huge impact on the open source communities who participate — I’m particularly proud of one of my students with Mailman who went on to become one of our more active core contributors.

Interested in participating as a student?

If you haven’t participated in the program, you may not know that the largest group of applicants are young men from India, in part because many Indian colleges actively encourage their students to apply. So if you’re someone who is not a young man from India, you’ll be a minority in this context! Many open source projects are especially eager to talk to students in other time zones (sometimes there are mentors who go idle because no students are available to work to their schedules!) and with different academic backgrounds, so this can be a chance to really stand out.

Here on the Geek Feminism Blog, we’ve talked about GSoC quite a few times. Here’s two posts that might be useful to you:

In my role as Python org admin, there are two questions I hear more than any others, so they’re part of our FAQ. Since they might be useful to others, here are some links:

We need mentors too!

Both Outreachy and GSoC groups are actively recruiting mentors right now. If you’re involved with a open source project that’s participating and willing to spend some mentoring time, these are both structured programs that can be great ways to give back to your open source community.

If your project isn’t contributing, there’s still time to sign yourselves up for Outreachy! And although GSoC mentoring organization applications have closed, there may still be opportunities for new mentors who are willing to learn a new project or participate as a “sub org” under the umbrella of a larger organization.

Not in a position to mentor? Cheer on the students, advertise the program, or use this as an excuse to learn a new project and follow along with the incoming students as they learn!

Quick hit: Programming Languages Mentoring Workshop, January 2014

I don’t have the hard data at hand, but my impression of the field of computer science that I did my graduate work in and continue to apply in my career — programming languages — is that it’s unusually homogeneous, even for computer science. I’ve written before on this blog about some of the consequences of gender inequality in programming languages research; things are not much less dire with respect to racial and cultural diversity.

One upcoming opportunity to get help with getting started in the field, for both graduate students and serious undergraduate students, is the Programming Languages Mentoring Workshop (PLMW). In 2014, PLMW will be co-located with POPL (the ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages), in San Diego, California, USA in January. The deadline to register for PLMW is December 10, and the ACM is making some funding available for students to attend PLMW and POPL, including travel costs.

POPL is probably the most prestigious conference on programming language theory, and I can say from experience that many (if not most) of the talks at POPL tend to be not exactly geared to a novice audience. When I attended POPL 2008 in San Francisco, one of the custodians at the hotel where the conference was taking place asked me, out of the blue, “What’s this conference about? With most conferences that happen here, I can figure out what they’re talking about, but with this one I have no idea.”

So attending PLMW looks like a great opportunity to be reminded that you’re not the only one who doesn’t already know everything. I just wish it had existed back in the early 2000s when I could have benefited a lot from it!

Why I Keep Coming Back to Mentor with TechWomen

This is a cross-post, written by Larissa Shapiro, from the TechWomen blog. Larissa Shapiro is the Head of Contributor Development at Mozilla.

TechWomen is an initiative of the US Department of State, administered by the Institute of International Education. TechWomen brings professional women in STEM fields from the Middle East and Africa to the SF Bay Area for month-long mentorships with women in industry and academia here. The “Emerging Leaders” are paired with a “professional” mentor (I have been honored to hold this role three times for the program) – who has the Emerging Leader with her at her workplace for a month, and a “cultural” mentor who shares the local culture and her own community and family life. The Emerging Leaders and their mentors also have the opportunity to travel to Washington, DC together in a delegation to the State Department and to other meetings with political and social movers and shakers in the capitol. Some mentors are also able to travel to the Middle East and Africa on delegations, as I was privileged to do in 2011 to Morocco. If any readers of Geek Feminism are interested in more information about the project, please visit the TechWomen page or reach out to me directly

I came across TechWomen by chance. A former colleague forwarded me a note from a local Women in Tech newsletter calling for mentors for a new State-Department-sponsored mentoring program. I thought… hmm…. am I ready for that? I’d gotten tremendous benefit from the mentors in my own life (I still do). I wanted to “give back” but felt terribly… green. I’d been in tech for about 15 years at the time, yet I felt unsure. I took a deep breath, filled in the application and sent it off, thinking there was no way I’d be accepted! In retrospect, I had Impostor Syndrome about becoming a mentor. What I did not realize then was how much mentoring would change my life, and change what I do with my life.

I was honored to be chosen for the first mentor cohort of TechWomen. I remember the first mentor meeting, and the incredible caliber of the women I met – I knew right away that this community of mentors would be a critical part of my TechWomen experience. Through mentoring, I have met and become friends with a network of amazing technical professional women with similar goals; all of us are dedicated to supporting each other and women in STEM around the world. Lifelong friendships have been built.

When my Emerging Leader arrived, I was impressed with her skills, talent, and intellect right away. It was not shocking – the women selected for this program are less than one out of ten of those applying. In 2013, 2000 women applied and 78 were selected. From the beginning I knew that I wanted to know every Emerging Leader well, and that we would never get enough time together.

Sanae and I dove into her mentorship, in which she studied project management techniques. We spent a lot of time at the French bakery down the road over coffee, learning how much we had in common. As much as I know I passed on wisdom to her about specific technical matters, she gave me her deep insights into my work relationships, and our friendship has continued. One of the biggest realizations for me in my first year as a mentor was that the technical mentorship is a container for work, but it is filled with deep international perspective, caring relationships, growth, and connection. The official “work” of the mentoring project turns out to not be the real “work” at all – not that it is not important.

As part of the program I was able to travel to both Washington, DC and to Morocco. Washington, DC was a wonderful trip – sharing both a city and a national heritage I love with new friends – that first year we happened to be in DC over the 4th of July and got to watch the fireworks from the top of the State Department. I felt like the luckiest American of all. Even more deeply meaningful for me was joining the TechWomen mentor delegation to Morocco – we travelled to Marrakech, Casablanca, and Rabat. One day we visited a house that provides care for girls who move to the city to attend secondary school – which they cannot do in their villages. The girls spoke mainly Berber, Arabic and French, but a few also spoke English and we talked with some of them. One told me of her determination to become a doctor and return to her village to improve healthcare for women and girls. At twelve years old, she spoke with an adult understanding of the world. I see the same fire in many girls who want to go into STEM – to change their circumstance – to change the world. She inspired me.

TechWomen moved into its second year, and expanded into more countries. I was thrilled to apply again – and my company wanted me to as well, having seen what an outstanding networking opportunity it was. I was matched with a brilliant emerging leader – an IT instructor from Tunisia. She chose a technical research project, studying the penetration of the IPv6 address protocol in Tunisia. She was also engaged in politics in her home country following its “Arab Spring” and taught me so much, giving me ever more respect for the work that goes into fighting for and building democracy.

I am now in my third year with TechWomen. I changed jobs during this year, and I was so determined to mentor again that I made my participation a criterion of my hire. I’m loving every minute with my newest Emerging Leader, Imen Rahal, who is very excited about the mission and projects of my present employer, Mozilla. Her enthusiasm is contagious. She has jumped in with both feet and is exceeding my expectations, taking on our modified Agile development process in the FirefoxOS project. I am very lucky that Imen’s Cultural Mentor is my friend (and Mentoring Process Architect) Katy Dickinson, and we have made cultural excursions together already, most recently to the redwoods near my Santa Cruz home.

Why do I mentor? Why wouldn’t I? For me, mentoring has become an emotional, networking, and perspective-building bank account where what I get back in “interest” is much more than what I put in. These women inspire me, bring my “game up” and become deeply cherished friends. If you have the chance to Mentor… I cannot recommend it enough.

Structure and Justice

A few months ago, I attended a talk at Mozilla by Ted Nyman (of Github) titled “Scaling Happiness”. The video is freely available.

Nyman argued that companies with minimal formal structure are better for workers (specifically, better at maximizing workers’ happiness) than more traditional companies. Whenever someone asks whether something is “better”, I ask “better for whom?” Whose happiness was Nyman talking about? He didn’t say, but when I think about happiness, I ask what’s best for women, for people in GRSMs (gender, romantic and sexual minorities), for disabled people, and for people of color, since not too many people seem to think about what’s best for people in these groups. (For the record, I’m in the second and third of those groups, though I’m usually not perceived that way in one case, and often not perceived that way in the other.) Happiness for the dominant cadre in the software industry — that of people who have white privilege, male privilege, cis privilege, and heterosexual privilege, and who lack visible disabilities — is not the same as happiness for everybody.

I don’t mean to say that happiness is a zero-sum game, that when abled white cis men are happy, that inherently takes away some of the limited pool of happiness from disabled trans women of color. Rather, part of the problem is that people who have privilege perceive happiness as a zero-sum game; part of their happiness comes from seeing themselves as better than others.

I think most people in the tech industry or in open-source or free culture communities know what I’m talking about when I say “structurelessness”. Perhaps you work at a “flat” company that encourages employees to make up wacky job titles to put on their business cards, calls everybody a “team member”, or renders everyone uncertain about who their boss is. Or maybe you’ve only worked at more structured, hierarchal organizations: ones with managers, a complicated organizational chart, ranks, and hierarchy. You probably know the distinction even if you’ve only been on one side of it.

Does structurelessness eliminate competition, abuses of power, and status hierarchies, or does it just drive them underground? To break down the question, let’s look at a few ideas about structurelessness, some of which are from Nyman’s talk and others are just things I keep hearing from people in the free/open-source software and culture world.

  • Authenticity: people are happier when they are able to be who they really are at work.
  • Informality: people are happier when they’re able to be informal at work, such as by wearing T-shirts with holes in them or saying “fuck” a lot.
  • Conduct: formal mechanisms for guiding behavior aren’t that important, since in a healthy organization, people will just be nice to each other.
  • Leadership: people whose job it is to manage aren’t necessary when people can just manage each other.
  • Accountability: formal goals and performance metrics just get in the way of getting a job done.

As a nod to structurelessness, I’ll take on these points in no particular order.

Hierarchies

First, why would a feminist argue in favor of structure when structure so often means hierarchy, and hierarchy is deeply entwined with oppression?

It’s true, I’m not a big fan of hierarchies. Maybe they can be used for good, but I haven’t seen a lot of that in reality. At the same time, though, it’s also a fallacy to think that simply declaring we’re not going to have hierarchies makes hierarchy go away. Jo Freeman wrote about this in the ’70s, in her essay “The Tyranny of Structurelessness”. Based on her experiences in feminist organizing, she found that groups of people (like feminist consciousness-raising groups) that declared they weren’t going to have a formal structure devolved into unofficial hierarchies, which were much harder to challenge and hold accountable.

Authenticity

Do you trust people to see you for who you are? I mean the question in two senses: (1) Do you believe that it’s even possible for you to communicate who you are to others without a great deal of effort, and (2) Do you trust others, as a general rule, enough to assume they will behave cordially towards you once they know who you are?

In his talk, Nyman talked about how in typical companies, many relationships are inauthentic. That is, people don’t act towards each other in the ways that they would in the absence of a rigid, externally imposed set of relationships. At least stereotypically, people don’t behave towards their bosses, or to their subordinates at work, the way they behave with their friends. He argued that people are happier when they can present themselves authentically and have authentic relationships, and that a less structured organization fosters such relationships.

If you are queer, or trans, or have mental illness, or all of the above, you probably know something about the perils of presenting yourself as you really are. Dan-Savage-style coming-out narratives notwithstanding, many of us who are placed socially in these ways find that we cannot be completely authentic in all aspects of our lives. I definitely want to express myself, but I have to balance that against other needs, like being able to make a living in a capitalist society. If I dressed the way I’d prefer to, if I talked more openly about the times when my depression and anxiety prevent me from getting work done, I might find it harder to fit in, to stay attached to a professional group, to stay employed, than I already do. So instead, I wear T-shirts and cargo pants, and I let people think (at times) that I’m merely disorganized or not that committed to what I do.

In my opinion, it takes a lot of privilege to assume either that greater authenticity leads to greater happiness, or that the only reason you would leave who you are at the door when you step or roll into work is the formal, organizational structure of the place where you work.

Moreover, being your authentic self in front of somebody else requires trust, and outsiders have very good reasons not to trust insiders. For me, part of what I mean when I say I lack a certain amount of privilege is that every day at work, I make calculations about who is safe to interact with and who is unsafe. Of course, there are degrees of safety and it’s not a binary choice. For example, every time someone uses “crazy” as a pejorative — suggesting that what I am is also a label to insult an idea with — that decrements their “safety” score inside my head. Almost everyone uses this word in this way — even I still do, given that I’m not free of internalized ableism — which is why I say it’s not a binary property. If my company became totally flat and got rid of all structures, processes, and goals, I wouldn’t be able to have authentic interactions just because of that. I’d still have this calculus of safety I have to apply all the time.

And what about when who you are makes people uncomfortable? If you’re queer, trans, kinky, poly, disabled, you probably either have spent a lot of time trying to blend in, or you have stories about when people become uncomfortable upon realizing some aspect of who you really are, and having to comfort them. (Or both!)

To take a completely different example, do you really want to encourage people to be “who they really are” when who they really are is a harassing creep? Maybe having to be a bit inauthentic at work serves an equalizing function, like a uniform. If you know what the rules are, it’s more likely that you’ll be able to follow them and less likely that you’ll be cast out for breaking a rule you didn’t know existed.

Informality and isolation

Usually, no one tells little kids on the playground who to play with and who not to play with. But even very little kids start forming hierarchies of exclusion when left to their own devices. Vivian Paley’s work, as documented in her book “You Can’t Say ‘You Can’t Play'” showed both that in groups of kindergarteners, leaders emerged who got to decide which kids got to play and which kids got excluded; and that a teacher could change that by imposing the simple rule that “you can’t say ‘you can’t play'”. And increasing the amount of inclusion in the group made the kids in it feel more accepted, on the whole. An advocate of structureless organizations might argue that Ms. Paley should have just let her pupils be their authentic selves and form their own social alliances. But at least according to Paley’s account, imposing the rules made the kids happier — contrary to Nyman’s claims about structurelessness and happiness.

Now, perhaps kids are just different from adults. I also don’t think it’s necessarily human nature to form hierarchies in the absence of formal rules. Fundamentally, I don’t care whether that’s because of nature or nurture. No matter what combination of nature or nurture it is, as human beings we have the latitude to choose what we will value. Personally, I value inclusion, and while I can’t prove logically to somebody else that this is something they should value too, I think there’s plenty of evidence that inclusion and the overall happiness of people in a group correlate. And, as Paley’s kindergarteners show, inclusion does not necessarily naturally arise from structurelessness.

Mentorship

Isolation is closely related to an insidious way in which people who believe themselves to be good can perpetuate oppression: the withholding of mentorship. In another context, that of law schools, Pamela J. Smith wrote about how even when Black women gain admission as law students, informal social barriers to the development of mentoring relationships with faculty members are a form of discrimination that is difficult to challenge (“Failing to Mentor Sapphire: The Actionability of Blocking Black Women from Initiating Mentoring Relationships”, reprinted in Critical Race Feminism, Adrien Katherine Wing ed.)

Informal mentoring between apparent peers is mediated by social power dynamics as well. In her book Leaving The Ivory Tower, Barbara Lovitts wrote about the importance of tacit knowledge in determining whether Ph.D students succeed or fail. Many graduate programs are quite structureless in a day-to-day way; despite having a clear hierarchy (tenured faculty, tenure-track faculty, non-tenured instructors, postdocs, grad students), new graduate students must navigate a system with very little formal structure in order to learn the unwritten rules of the game. The difference between being a popular person and an unpopular one in grad student social groups can be the difference between academic success and failure. Would fewer grad students drop out because of isolation if there was a more formal process for initiating beginning students?

In my personal experience as someone who, earlier in my life, didn’t resemble most of my colleagues, lack of mentorship is a major structural barrier to success both as an academic computer scientist and as a software engineer. And I think lack of structure translates into lack of mechanisms to encourage formal mentoring relationships — something that has a disparate impact on women, people in gender, romantic, and sexual minorities, people of color, disabled people, and everybody else who may not feel comfortable approaching someone of higher social status to ask for support.

Likewise, people with disabilities that affect how they process tacit social cues — such as people who are on the autism spectrum — may have a much easier time contributing harmoniously when the rules are made clear than when they must access all resources by guessing at a system of unwritten rules. Since ability to write software isn’t contingent on being neurotypical, barriers to entry for neurodiverse people mean excluding a portion of the talent pool for no particular reason.

When a marginalized person joins an organization, in the absence of structure, isolation and lack of mentorship can combine to render them powerless and unable to ask for — or perhaps even express — what it is that they need. In such a situation, it’s easy for that person to then be labeled “unproductive” by the very community that has, without even knowing it, made it impossible for that person to learn and grow. Formal structures are one way to level the playing field and make sure that everyone has the same opportunities, regardless of whether senior folks in the organization find them initially easy to relate to or identity with.

Codes of conduct and diversity expectations

I don’t know how a structureless organization would maintain or enforce a code of conduct. Maybe in such an organization, everyone just likes each other so much that it’s not necessary to have one. But codes of conduct aren’t needed because people aren’t nice or because they don’t like each other; they’re needed because different people have different expectations about what kind of behavior is appropriate in which contexts. It doesn’t seem to me like getting rid of formal structure solves that problem.

Codes of conduct are just one way to help a group become or remain diverse, by ensuring a safe environment for everyone and providing mechanisms to address breaches of that safety. Without formal structures, how does a company make and keep itself diverse? While the practice of affirmative action is often inaccurately derided as “quotas”, a few tech companies do go as far as to institute numerical quotas for hiring women. I would suspect that such a practice, and even more flexible affirmative action concepts, would conflict with informality. But how does a structureless organization avoid devolving simply into hiring friends?

In general, how do you make sure that an organization without structure doesn’t default to recreating the same power hierarchies that exist in its underlying society? I asked this question during the question and answer period at Nyman’s talk, but it got a little lost in translation. Nyman’s answer amounted to “we won’t hire racist or sexist people”. But that’s not good enough. Everyone raised in a white supremacist society has unconscious racism, and everyone raised in a patriarchy has unconscious sexism. It’s obviously inadequate to dismiss the possibility of recreating systematic oppression “because most of us are good ethical people”. Nyman himself admitted that Github is getting less diverse.

Leadership

Unless it literally consists of a collection of people, each working alone — in which case you’d wonder what makes it an organization — in an organization without people formally titled “manager”, people will have to step up to manage each other at least sometimes and to some extent. How do you take initiative and assert power — in the absence of a structure that makes that power legitimate — when you’re already culturally oppressed and disempowered? If nobody is a manager, who will be most successful in, say, asking that their team institute a “run regression tests before committing code” policy: a tall, white, able-bodied, cis man; a short, Latina, disabled, cis woman; or a fat, Black, genderqueer person? When is it possible for people to really treat each other as equals, and when do they infer hierarchies when not given a formal hierarchy to look to?

What about when you’ve been punished in the past for trying to regulate others’ behavior instead of “knowing your place”? If you’re perceived as female, knowing that girls who assert power get called “bossy” and women who assert power get called worse, but also knowing that your leadership skills will eventually be called into question if you don’t assert power, structurelessness starts looking like a double bind.

Accountability

Without goals and performance metrics, how do people get held accountable? I don’t just mean accountability for delivering on the promises one makes as part of doing one’s job. How about, for example, not finding a subtle way to fire somebody for discriminatory reasons and make it look like it was performance-related?

In his talk, Nyman acknowledged that more “formal” processes are necessary for handling harassment: he acknowledged, “you can’t just go to anyone” if you’ve been harassed. But what else, falling short of “harassment” as such, might require a formal process?

Summing up

I’ve been pretty negative about structureless organizations. But there might be positives. Are they more open than more traditional companies to people with less formal education, or whose biographies are otherwise non-traditional? (I don’t know.) Do they make it harder for entrenched managers to retain power by virtue of seniority? (Again, I don’t know.)

To be fair, there isn’t just one set of processes that could arise when an organization sets aside formal structure. The majority could end up ruling most of the time. Or an organization could make decisions based on consensus. Or it could be cloyingly called a “do-ocracy”, in which decisions get made by whoever has enough time and energy to implement the consequences of the decision. I still think there’s the risk of majority rule, though, and the problem with that is that decisions about basic rights, respect and dignity can’t and shouldn’t be made by a majority. Where do basic rights, respect, and dignity come into this discussion? The number of occupations that are at least potentially a route into the middle class, at least theoretically available to anyone who has acquired a certain skill set that is possible for anyone dedicated to acquire, is steadily decreasing. If you’re in a social class such that you need money to live, learning how to program isn’t a bad way to go. But that will only continue to be true if tech company jobs are open to any qualified candidate, without the hidden price tag of humiliation based on one’s race, gender, disabilities, or sexual orientation.

Majority rule is, then, a problem because majorities often opt to keep minorities in their place for the benefit of the majority. And yes, a group made up of entirely people who see themselves as good and ethical can and will deny basic rights, respect and dignity to people based on gender, sexuality, ability, race, class, and other axes of oppression. The world might be different someday, but we can’t get there by pretending we are there.

Your thoughts, readers?

Thanks to Geek Feminism bloggers Sumana, Mary and Jessamyn for their comments.

By your powers combined, I am Captain Linkspam! (21 September, 2012)

  • Scientists, Your Gender Bias Is Showing: “To test scientist’s reactions to men and women with precisely equal qualifications, the researchers did a randomized double-blind study in which academic scientists were given application materials from a student applying for a lab manager position. The substance of the applications were all identical, but sometimes a male name was attached, and sometimes a female name. Results: female applicants were rated lower than men on the measured scales of competence, hireability, and mentoring (whether the scientist would be willing to mentor this student). Both male and female scientists rated the female applicants lower.”
  • Beating the Odds – How We got 25% Women Speakers for JSConf EU 2012: “We received 234 total talk submissions by 180 unique submitters. 162 (90%) men, 18 (10%) women. We invited 35 women to submit to the CFP, of these 13 ended up submitting one or more proposals, 5 women submitted on their own. The 40 speakers we selected for the weekend are the top 40 anonymously ranked of all proposals.The final tally:
    • 40 speaking slots (100%)
    • 30 men speaking (75%)
    • 10 women speaking (25%)”
  • World Con and accessibility (or lack thereof) | sasha_feather: “Karen Moore recently went to WorldCon and was struck by the difference in the lack of accessibility there vs. at WisCon. She wrote us a letter to say so, and gave me permission to quote her letter in my blog. Excerpts from her letter follow”
  • Things To Do When The Internet Makes You Enraged | Skepchick: “I’ve been struggling recently, trying to find the best way to handle the ongoing barrage of anger and hate that has been directed at various people in the [feminist/atheist/skeptic] community….So I thought I’d put together some things that you and others can do to make a difference in this community to build it up and strengthen the foundations”
  • Wikimania 2012: Opening Plenary with subtitles | Amara: Mary Gardiner’s “Fostering diversity” Wikimania keynote, begins at 11:44
  • WitsOn, an online mentorship event/program, has been getting some attention with their recent press release and a New York Times article . College students can sign up to participate at https://piazza.com/witson.

You can suggest links for future linkspams in comments here, or by using the “geekfeminism” tag on delicious or pinboard.in or the “#geekfeminism” tag on Twitter. Please note that we tend to stick to publishing recent links (from the last month or so).

Thanks to everyone who suggested links.

Google, gossip, and gamification: comparing and contrasting technical learning styles

I just ran across Karen Rustad’s “How to teach programming: shy, practical people edition.” She cared more about making practical things than about what she perceived as “coding,” so her early technical life centered on HyperCard and making webpages, rather than boring faffing about with “mathematical curiosities.” Finally she came across a project she wanted to help, and scratching that itch meant learning more programming:

Basically what revived my interest was having the opportunity to work on OpenHatch. Getting thrown into web app development and all the associated languages and tools — Python, Django, git, Agile, bash and other command line nonsense — all at once? Yeah, it was a lot. But Python out of context is just a toy. Django out of context is plausible, but hard. Git out of context … wouldn’t’ve made any dang sense. So sure, I couldn’t remember half the git commands (Asheesh eventually made a wiki page for me :P) and I had to look up how to restart the Django development server practically every dang time. But I made do, and I learned it, because the context totally freaking motivated me to. Because *finally* code had a purpose — it was clear, finally, how it could be self-expressive and useful to me. Learning these tools meant I could help make OpenHatch exist. Like, fuck yes.

Different people learn in different ways, and for different reasons.

I figure I learn how to tinker in software, especially in open source, via three methods:

  • Google
  • gossip
  • gamification

I learn to search the Net well, iterating on keywords and site: and so on; I fall into or develop a network of folks who won’t think I’m stupid for asking questions; and I play little games with myself, or write them, feeling the thrill of the challenge, leveling up little by little.

I was missing all of these when I tried to Learn To Program.

Continue reading

“Put up or shut up”

One thing I love about open stuff, such as open source communities, is that we (try to) measure people by what they contribute.

I’m now Volunteer Development Coordinator for the Wikimedia Foundation (although I am not speaking for them in this post), so I care about the quality and quantity of contributions to MediaWiki, and about the people behind them.  In fact, I’ll partially be measuring my success through statistics on the number of people who offer code, bug reports, translations, documentation, talks, mailing list posts, and so on.

And it’s not just doing, it’s doing and sharing.  We value collaborative work, not hoarding.

This norm, among others, leads us to use “put up or shut up” to quash unproductive conversations, bikeshedding, trolling, and “you should…” unhelpful suggestions.  I once had the satisfying experience of saying, to a guy full of “why didn’t they do foo”, “you should totally post that suggestion to the mailing list!” and seeing him just shut up, defeated.  He knew that doing this without embarrassing himself would take a modicum of research and thought, and he had no intention of doing anything that arduous.  He’d just wanted to mouth off.  And now I’d revealed him as a noncontributor.

I saw another example in Kitt Hodsden’s talk about the Hacker Dojo community center.

all talk, no action

Another aspect of open source development we encountered, an aspect that is also found in just about every volunteer organization ever, are the troll subspecies “we oughta.”

The we-oughtas clan is often very vocal, they know what we should be doing. When it comes to the actual doing, however, they aren’t around, they aren’t available, or that’s not what they meant.

When this is the case, the response is either, that’s nice, and ignore it, or, just as in open source projects, “put up or shut up.” Essentially, if you’re not willing to put forth the effort of leading your own project – even if that leading is just finding someone else to lead your project – we’re not going to follow.

At its best, “put up or shut up” is empowering.  In Hodsden’s talk, she shared a story about a potential member whose “project was outside of our expected and supported hardware and software development spaces”:

We gave the answer we have learned to give for people who have crazy, though potentially awesome, ideas that in the future could work wonderfully in our space: lead the project: tell us what it is going to take for your project to succeed, develop a game plan, put in the safety measures, find supporters, work up a budget, start the fundraising, make it happen.

The community defines itself. If the community decides it wants to become a metalsmithing shop or an experimental biology lab, it’ll become that, because that’s what the community wants.

I bet all of us who have held leadership in FLOSS can attest to the two sides of “well go ahead then, patches welcome, make it happen, this is a do-ocracy.”  Great, we can empower people.  But how often do we use it to shut down discussions, ideas, and people we don’t like?  In particular, have you been part of an interaction where a privileged FLOSS project member used “you want it, you make it happen” to wrongly dismiss a concern that might require the whole community to change its behavior?

Look at what I did, in the anecdote I told in the third paragraph of this post.  I wasn’t purely kind or rational or ideologically anarchic in telling that guy to write to the list; I found him annoying and wanted him out of my hair.  I told him to contribute, superficially encouraging him, but really wanting to discourage him.  Have you ever been on either end of that, especially around geek feminist issues?

And I suspect this disproportionately affects newbies and non-native speakers of a community’s language.  This is the problem with saying “you want it, make it happen” in response to requests for a harassment policy, or for all of an app’s strings in one file to make localization easier.  The very people who need those new policies, procedures and abstractions are least able and worst placed to implement them.

(Small digression: in the case of harassment policies, consider “Did you know how to react?” by Noirin Plunkett, and Bitch Radio’s interview with Valerie Aurora.  The Ada Initiative, in suggesting and working towards conference anti-harassment policies, has far more energy and resources than would one individual seeking protection.)

Developers are used to dealing with requests for features or bugfixes, but FLOSS leaders are still learning how to deal with requests to socially engineer our projects.

And no matter whether you’re considering adding a feature, hosting a sprint, changing version control systems, or joining a conservancy, it’s sensible risk mitigation to chat about it before putting substantial effort in.  This is a different kind of work, not coding, but building support and getting the lay of the land.  And it’s part of contribution.

So, fellow FLOSS leaders: If you want to grow new contributors, along with giving them permission to suck, build personal relationships with them.  In private or face-to-face, listen as they vent and discuss their ideas, even the half-baked ones.  Listen for the difference between “we should” and “I’d like to/how do I?”.  Sometimes they’ll need sympathy, and sometimes advice.  If you say “go do it then,” say it encouragingly, not dismissively.  Watch out for moments when a marginalized potential contributor is essentially asking you, “help me help you.”  And watch yourself in case you’re about to do what I did, using “put up or shut up” to shut down someone you find abrasive.  Because sometimes I’m abrasive too, and sometimes I have good ideas.  :-)

As hypatia puts it: “a gentle ‘that’s definitely an issue, could you file a bug’ goes a long way.”

Google Summer of Code 2011: application tips

Student applications for Google Summer of Code open March 28 and close April 8, but students are expected to begin talking to mentoring organisations now. The mentoring organisations responsible for various startup and internship applications like latest casino deposit bonuses collection companies and other debt/gambling institutions for 2011 have just been announced. People have been more interested on being able to understand the bet history and when bets get settled.

Students who are interested in applying: this is a big process, don’t wait for the official opening to get to work on researching and talking to mentoring organisations, as there are only two weeks between the open and close of applications. Here’s some starting points:

Terri’s post from last year, Showing your awesomeness for Google Summer of Code has many more details.

If anyone wants to discuss experiences with applying to Summer of Code, or evaluating applications, please do so in this post! Remember that places are limited, especially in the popular programs revolving around the best real money casino sites.

Update: this thread is for discussing how best to apply to Summer of Code. So that that isn’t drowned out, use the classifieds post for advertising your project or projects you have worked on, and for general discussion of Google Summer of Code that isn’t on either of those topics, use the latest open thread.

GF classifieds: Google Summer of Code 2011 edition

Google Summer of Code–yes, bad name for anyone in the southern hemisphere, but you are allowed to apply!–is a project sponsoring Open Source development by students (largely university students, you have to be 18+ or turning 18 by April 25 to apply) over the northern summer period. Google pays a stipend for students to work on a contribution to a project over summer. Open Source projects are selected as mentoring organisations, students apply by submitting a project proposal to a project, and some of those proposals are accepted.

The mentoring organisations for 2011 have just been announced. Student applications open March 28 and close April 8, but students are expected to begin talking to mentoring organisations now.

So as with last year, here’s an edition of GF classifieds for mentoring organisations to reach out to readers here. If you are a mentor or part of a mentoring organisation for Google SoC and you’d like to bring your project to the attention of readers here, please post a description in comments at any time before April 2 (comments automatically close then). The more you can say the better:

  • Do you have link to a list of ideas for projects?
  • Can applicants make contact with you or your mentors in order to discuss their application before submitting?
  • Are previous years’ students available to discuss their experiences?
  • What kind of skills are you looking for?

Of course, if your project has made a commitment to diversity in some way, then feel free to tell us about that.

Former Summer of Code participants who worked on a project and liked it and found it welcoming or diverse, feel free to also promote your former project here, if they are mentoring again.

Note: obviously Google SoC projects accept applications from people of any gender. The reason for this post is to level the playing field at the awareness level. By posting here, what you’re doing is hopefully increasing the visibility of your project among interested women, rather than excluding anyone else from applying.

Update: this thread is for mentoring organisations and former mentees to promote themselves and their projects. So that that isn’t drowned out, use the application tips post for discussing how to apply, and for general discussion of Google Summer of Code that isn’t on either of those topics, use the latest open thread.

Re-post: When you are the expert in the room

In anticipation of a December/January slowdown, I’m reposting some of my writing from 2010, for the benefit of new (and nostalgic!) readers. This piece originally appeared on the 4th October 2010.

This is an Ask a Geek Feminist question:

This a “what should we do” question, but a fairly specific one.

Recent discussions, particularly Restore meritocracy in CS using an obscure functional language , have left me thinking “this still doesn’t say what it would be helpful for people like me (white male with computing experience starting early) to actually do about it”. Just saying to avoid the viewpoint that this reflects enthusiasm or innate ability isn’t very specific, but the discussion seemed to finish around that point.

The answers will probably be different in different contexts. For example, how about in class? The best I can think of is “don’t be eager to answer the lecturer’s questions to the class, but let someone else go first”. Would that help? Is that enough, in that context? But if you give the lecturer the impression you’re not knowledgeable, but then do well in the written exam, you can invite suspicion of cheating in the exam (this definitely happens). Or should you even make deliberate wrong answers, to lower your apparent expertise? I’d find that horribly condescending if I knew someone was doing it towards me.

And in a professional context, if you know the answer to a colleague’s question (or on a mailing list, to any question), but you hold back on it to let someone else answer, you’re holding back the asker from getting on with whatever raised the question. But is that less important than letting others answer? (I suspect it depends on the group or list concerned.)

And a branch of that one, relevant in my present job, in which part of my role in the team is specifically to be the experienced programmer who can answer people’s questions, how is it best to handle that?

And in a seminar, should you hold back in a discussion if you have advanced ideas, so as not to scare the less confident? But then, you’re not making your best technical contribution.

The most extreme suggestion I’ve seen (only once, I think) is that geeky men should get out of computing altogether, to make it more comfortable for others to get in. In which case, a big source of potential mentors would be lost.

And do the same suggestions apply to female experts?

So, I’m stumped on this and can’t contribute any significant answers, but I hope the questions are useful for discussion.

There was some discussion among the cob-loggers about whether and how to answer this question. But there was always lots of confusion about this on the LinuxChix lists while I was subscribed (I haven’t been for a few years now), men who genuinely wanted to in some way to address gender issues in computing but the only strength they saw in themselves was their expertise, and when it was suggested to them that displaying this at every opportunity was at best annoying and at worst harmful they were completely at a loss. So I think an answer is genuinely useful.

Important note: this answer is aimed at privileged people (in this context, generally men with a good technical background) hoping to check their privilege and keep it on a short leash. If you are a woman reading this, it’s entirely possible the reverse applies to you in geeky environments: you might be wanting to learn how to have more confidence in your expertise and how to inspire confidence in others. Some of these techniques might be useful to you at some times when you want to help others learn, but this answer isn’t really intended for you.

Important note 2: from here on, “you” refers to the general you, the person who want to encourage/support/etc women but is struggling to see how to do it without being dishonest about your own abilities, not necessarily “you” the person who asked this specific question. I’ve seen this a lot, so I want to try and address it in general. I’m generally going to assume that the relative expertise of the question asker is in fact a correct assessment but you should question whether you are really the expert or whether you’re partly benefiting from structural assumptions that you are.

Let me start by stating that there are at best misguided versions of this question: people who say “I want to share my expertise with women who want to get into computing! But now I’m not supposed to be intimidating. Fine then, I’ll take my expertise and go home. See how you like that, women in computing! Ahahahaha!” Don’t be one of those people. Your participation in technical and geeky groups, especially groups for learners, isn’t solely about you. If you insist on either being the top dog expert or going home… go home.

My beta reader for this suggested that much of the question is based around the assumption that in order to help build people up, you have to drag yourself down. There’s two problems with this: one is that this sort of thing isn’t a zero sum game, and the other is that not all women (or outsiders in general) are also beginners. They may be intimidated in spite of substantial ability and experience. So in many cases your role is less to try and hide your own excessive light under a bushel, and more to support the discovery of what’s already there.

When you’re the expert at work

In terms of your workplace, an approach I like is one that some activist groups make explicit: if you are the only person who knows how to do something that the organisation needs, you should make it your top priority to train at least one other person to do it. You could do some of the following:

  • presumably part of your role as designated expert, or something that you can make part of your role, is keeping a sort of list (mental or physical) of areas of expertise other programmers have, and referring questions to the other experts.
  • if something should be documented, ask the person who consults you if she can document it as she learns it. Then you can refer future questioners to that documentation, or get them to improve it. And you can credit its authors when you point people to it. And by having people teach others and write for others, you are turning them into experts.
  • if something should be automated (for example, you are consulting on a fiddly manual process) ask the person who consults you if she can automate it as she learns it.
  • when you get too busy (and this sounds like the sort of role where you are constantly in more demand than you can satisfy) decide that someone else needs to be the expert on some subset of the organisations knowledge base, and come up with some kind of handover process in collaboration with her, so that she is confident in being able to handle that set of problems and people know to go to her without even involving you.
  • consider that your own expertise is unlikely to be all-encompassing. If there’s a task that takes you half a day and a colleague half an hour, ask her for her help with it. (No need to go on and on about how she’s the expert here yay for her, just get her help.)

Note that those aren’t specific to women colleagues despite my choice of pronoun. The idea is to change the environment such that expertise is being built everywhere, not to go out of your way to make women into experts, unless you are in an environment specifically focussed on women (like LinuxChix is).

Similarly, in teaching roles, it is important to know when someone is thinking out loud on their way to the answer and when they are genuinely stumped and starting to get too frustrated to make progress. In the former case, just let them think and give them some time to put those thoughts into action.

When you’re the expert in class

Some of the question about classroom behaviour does seem a little excessively fearful. I guess there might be some classes that are structured as lectures and a final exam, but all my classes at university involved submitted assignments throughout the course in which you can demonstrate knowledge without taking up class time. A class in which people must ask questions to demonstrate their knowledge, as opposed to asking questions because they need the answer sounds like it must be terribly tedious for everyone involved. And they must be awfully small classes, or really long ones, if everyone who doesn’t regularly participate but still does well in the class is then investigated for cheating. In general, if you are required to demonstrate expertise solely in order to pass, see if you can do so in a way that isn’t public.

In terms of being part of classes or seminars, it is situation dependent. Is the class or seminar or discussion a bit introductory for you? Perhaps you should absent yourself or remain silent while the others get the hang of things, or at least wait for one-on-one approaches from other students for help rather than taking up teaching time demonstrating your knowledge. Is it genuinely challenging for you too? Well, make it visible that you’re being challenged. Be that wonderful person who asks the lecturer half way through the class “uh, I don’t think I really understood that first set of hypotheses, can we slow up?” when everyone else thought it was just them. Throw a few ideas against the wall before you think you have the answer. If someone else has a good idea, give them space to express it, thank them, and then see if you can extend it, especially in a collaborative way with the original proposer. Watch the tendency to try and set up a you-and-me-the-smart-ones dynamic with the teacher by speaking up only when you’re totally confident.

It may help periodically to actually try and measure (by making notes of who speaks when, assuming you can do it subtly) whether you are the most talkative person in the class. If you are, take a break from talking: it’s unlikely your ideas are so uniformly superior as to need that much airtime, and if they are, perhaps you need a more advanced class.

My beta reader also suggests that if you find a classroom is centred around you and other confident students and generally being a little self-congratulatory and that other students are floundering and suffering, that perhaps you should have a word to the teacher about how you feel the classroom environment is letting most of the students down.

When you’re the expert in a women-centred geek forum

In situations like mailing lists, at least places like LinuxChix which have a specific mission to be encouraging and a good place for learning, here’s some tips:

  • Have a look at the average turnaround time of the discussion. Is it common for someone to wait 24 hours to have a question answered? Well, people asking for help are probably aware that they may need to wait 24 hours (unless of course they say something like “ARGH HELP NOW DON’T DELAY FIRE FIRE FIRE IN THE THEATRE”). So make that your delay. Wait 24 hours (say), and see if they got a decent answer yet. If not, then post.
  • Very important: before you post an answer, read the other answers. It’s a common problem to have a self-appointed expert insist on re-explaining the whole thing from scratch, rather than seeing that Suzy already sorted out Jane’s compile error, so you just need to help Jane work out how to get the info she needs out of the core dump.
  • If an answer worked, but is missing a nuance, or isn’t precisely how you would have done it, consider carefully if you need to point that out. Is it actually harmful in the long run to do it the other suggested way or is it a matter of taste? Is this a good time and place to evangelise on matters of taste? It usually isn’t.

Note that none of this is denying your interest, expertise or talent: it’s not about pretending not to have it, it’s about genuinely putting it at the service of other people, and about developing similar expertise in other people.

I think it’s also important to interrogate your motivations in being the expert in women-centred groups. All of these approaches are not uncommon in tech groups with a lot of women:

  • assumptions that you, a man, must surely be the only expert in such-and-such who is part of the group, because, really, how likely is a woman to be a such-and-such expert? (There were certainly subscribers to the LinuxChix lists who believed that this was true of all of Linux systems administration, to the constant chagrin of women members who had spent 20 years in the field.)
  • assumptions that women geeks, unlike men geeks, will properly acknowledge you and respect you for your expertise, finally, the admiration you deserve!
  • the good ol’ not having enough women in your social circle thing, and being there to make friends.

The last one is tricky: here’s my take. Nothing wrong with having friends or wanting more! But, when you aren’t in a social group, attend to the mission of the group first, and the socialising a distant second.