2014/Sumana Harihareswara keynote

Sumana Harihareswara's opening keynote address at Wiki Conference USA, May 30 2014, in New York City.

Introduction

Jen Baek:

Sumana is a Senior Technical Writer at the Wikimedia Foundation, where she works in the Engineering Community Team, engaging volunteer developers within the Wikimedia movement, and rocking hackathons. Sumana has worked for Collabra, GNOME, QuestionCopyright.org, Fog Creek Software, Behavior, and Salon.com. She has contributed to the media wiki AltLaw, Miro, and Zeitgeist open source projects. She’s also a blogger at Geek Feminism, and a member of the Board of Directors of the Ada Initiative, and was an editor and release organizer of the Gnome journal. She’s truly a badass and a friend who has supported and helped me as I’m sure she has for many other people in this room and around the world, feel welcome within the Wikimedia free culture, open knowledge, techno activist and feminist communities, and I’m very excited to be introducing Sumana to all of you as your first keynote speaker.

Sumana Harihareswara:

Hey there. You can all hear me all right? Great. Well, thank you to everyone who worked on creating this conference and bringing it here. And thank you for inviting me to open this conference. I'm speaking for myself today, and not the Wikimedia Foundation or the Ada Initiative, today, which is good because I might swear a little bit. And thank you to NyQuil for making it possible for me to be here.

laughter

Another acknowledgement. I acknowledge the Lenape people on whose ancestral land I stand. the African people whose bones were buried unmarked in this city’s foundations, and the involuntary and exploited labor of people from every land which helped create New York City.

And I want to thank all of you who are here, and everyone who shares in imagining a world in which every single human being can freely share in the sum of all knowledge. You might have heard that line before. That’s our commitment together. And Wikimedia is a wonderful place to be because I can help everyone, and everyone can help me. All of us here have goals, about what we want Wikimedia to be, about how we see that mission unfolding. And we each have our own different perspectives, which is great, because no one of us has all the answers to how to achieve this mission, which means we have to learn from each other. Every single one of us – every single one of you – has stuff we need to learn to help achieve the mission. For some of us, we need to learn how to use new tools, we need to learn certain aspects, little bits of domain knowledge, we learn how to talk to each other in new ways, or we need to learn how to teach each other, and teach new people, better. And so that’s why I’m going to be talking today about making learning environments nurturing learning environments.

I'm going to tell you about one that worked for me, a place where I found I could learn things that I had not been able to learn elsewhere, including at Wikimedia and I want you to see how the essential features of that place helped everyone learn more effectively than some people can learn right now within the Wikimedia community. Then I'll talk about how we apply that to Wikimedia as a whole.

Why we should look at Hacker School

In fall 2013 I took three months off from my Wikimedia Foundation work to improve my programming skills. I did this at an experimental place called Hacker School, where people who already have some programming experience get together to improve their own skills. And there's no set curriculum; it's a face-to-face place, not too far from here, right at Canal and Broadway, right here in Manhattan, where people work on their own projects, or contribute to open source together, or work through textbooks, or online courses. It's free to attend, but to encourage gender diversity, there are grants for women, to cover living expenses. And in my batch, which was 59 people, gathered together for three months, it was 42% women.

So I’ll start off by talking about ways in which Hacker School is unlike us, but then talk about why I think we can still learn from it, and there are some ways in which Hacker School is very Wikimedian. Now, it’s unlike us in that every single person there has a really, concretely, shared goal. And you might say “Hold on, Sumana, you just talked about this shared mission!” Well, yeah, but I think a lot of us contribute to that mission in very different ways and have somewhat different conceptions of what it is, some of us contribute to Wikisource, or to Commons, some of us care more about editing, some about programming, some about design, some about outreach – it can be fuzzy, and Hacker School is much more concentrated. Every single person there is just there to become a better programmer, even if they’re learning different languages, and so on. And it’s small. And young. Hacker School has only been around for a few years, and there’s a total of maybe 250 people who have ever passed through it. It’s very face-to-face. Now, there is some online chat with alumni, but it’s in New York City, and there’s very little remote component. And possibly most importantly, they’re willing to exclude. Hacker School has a selection process, and not everyone gets in. They aren’t that big on you having to be some kind of hotshot programmer. They are totally fine with letting in people who have, let’s say, two months of programming experience, or twenty years of programming experience. In my batch, there were two PhDs. They balance having that basic skills check with valuing heterogeneity, but there is a selection process, and I’ll talk more about what they’re checking for later.

But they’re also like us. They appeal to me in much the same way that Wikimedia does, in that it’s experimental and it’s very consensus-driven. There’s a lot of ad-hocracy. Many things have changed from month to month and year to year at Hacker School, iteratively and experimentally, and there are different people on different projects and everyone has something to learn and teach each other. It’s an ad-hocracy, and a do-ocracy, as you might be familiar with, and there’s a balance between peer mentoring and paid help. And this probably sounds familiar to you, now in the 10-plus years of the Wikimedia movement, we’ve grown to have that. The vast majority of the stuff that’s happening is being done ad hoc, by volunteers, people helping each other, but we agree there are some things it’s really useful for paid people to do. At Hacker School there are five paid facilitators, who do things like helping people set and reach their learning goals, and directing them to resources, and starting them off with things like peer programming. And there are diversity goals at Hacker School, and that feels familiar to you, probably. You’ve seen that in the past several years Wikimedia, the movement, has set various diversity goals and tried various ways to achieve them. And there’s a lot of transparency and open source at Hacker School. For instance, their user manual is public. You can just go to Hackerschool.com and read it.

to photographer: Any time I see a camera pointed at me, I start making more hand gestures, I hope you don’t mind.

(laughter)

Camera Operator: Don't worry; I’ll make you look beautiful!

Sumana: Make me look smart, that’s more important.

(cheers)

In fact, a lot of Hacker Schoolers do their work either by making small open source projects or contributing to them, and so it felt very familiar to me in various ways, and I think we can learn from how they’re achieving certain goals that we couldn’t, necessarily.

So let’s look at how the environment is set up at Hacker School, and see what we can borrow. And here, as I talk about how people learn, I’m going to be taking bits and pieces from cognitive apprenticeship theory, from a book called How Learning Works, and various others citations that I already put on my blog earlier today at harihareswara.net, and I’ll be tweeting and denting and linking to later.

How we learn

People learn differently, for one thing. I mean, really, different people learn incredibly differently. If you were making clothes, you will have to make more than 1 size of shoe. If you were making almost anything, you would have to think about that. And different people really learn incredibly differently. For instance, the Felder-Silverman Engineering Learning Styles suggest forming axes that different people vary on. Either way is good, but if you’re just going to be tailoring something for someone, they’ll learn even better. Some people are more active learners, they want to bump into things and make mistakes, and that’s how they learn. Some people are more reflective learners, they prefer to look at a map first. Some people are more sensing learners, they prefer concrete examples. Some people are more intuitive learners, and they like to look at patterns and think about how things connect together. Visual versus verbal, do people want to make diagrams, or read or listen to words? And sequential and global. Does your learning proceed along Lego brick by Lego brick, or do you sort of fall in and then have a big epiphany a little bit later.

I have changed the way that I teach and the way that I mentor and the way that I even ask little questions – answer little questions in IRC, based on knowing this. My mentee Frances is here, for the outreach program for women, and as she was writing her application for her internship, I basically said “Would you mind taking this assessment so that I can know how you learn so I can teach you better?” And things have gone a lot better, because I’m not going to send her to videos, because she hates videos! And interpersonal conflict actually goes a lot smoother, because sussing out how other people are learning, and how they’re listening to me, and maybe what their mental model is that’s different from mine, makes a massive difference. It decreases friction and increases the productivity of that encounter.

Another way that people learn is through legitimate peripheral participation, which is quite mouthful. If there’s any members of Wikimedia Foundation’s Growth Team here they might be kind of bouncing up and down, because that’s a lot of what they help enable. The idea of legitimate peripheral participation is “Here’s a main, hard, complex activity that only the most expert people in a community can do” but sort of coming out in ripples from that are smaller, less complex, easier to learn tasks, where if people do the easier to learn tasks first while they can look over the shoulders of the experts, they’ll learn more. You know, if you’re sweeping up sawdust in a woodworking shop and then learning to measure while you watch other people doing the really complicated cuts, you’ll learn more. You’ll see how long things take, what the rhythm is, what kinds of decisions you have to make. And the Growth Team has been helping people find legitimate peripheral participation in editing through things like typo fixes and it seems to me like mobile editing, and increasing people’s ability to do quick photo uploads to Commons and add to Wikidata is very similar.

One thing that I think we can learn from legitimate peripheral participation, as that idea, is – do we actually have good pathways for people to do that in other parts of Wikimedia, the more social ways? Like being on the Grants Committee, or WikiProjects, or other more complicated forms of contribution that involves more interpersonal interaction. We can redesign tasks to reduce the cognitive load on learners so they can focus on key aspects of the task they are deliberately practicing. There's a summary of this process in the How Learning Works book.

To become self-directed learners, students must learn to assess the demands of the task, evaluate their own knowledge and skills, plan their approach, monitor their progress, and adjust their strategies as needed. And when you’re doing something you’re an expert at, you do that without thinking about it too much, but helping people get that into their muscle memory is a process in itself, and it’s one worth designing.

My friend Mel Chua, who's a Wikipedian and an education researcher, once summarized these three lessons as super important for us to learn, as: one, learning is designable like code; two, our brains are snowflakes, we learn differently; and three, we do not function standalone, we learn in communities. So I lived through all these lessons in the autumn, at Hacker School.

I thought about how I learn. I learned a lot about how I learn. I use little rituals. I listen to certain music – for me, it’s the Tron Legacy soundtrack – or I take a break every 90 minutes. I learn best by setting small goals for myself, to combine textbook learning with making little apps or websites. And I learn with and from others. It is important for me to be around other people in person and online, so that I can learn from them and I can teach them. For me, it has to be reciprocal. And it worked! I learned a lot at Hacker School. I came in a dabbler and I came out a much better programmer.

One reason is Hacker School was a place I could show up and I could ask what the hell an array was, and someone would help me and give me an answer. I could have looked up individual definitions on my own, but conversation was what helped me build the conceptual models for those definitions to fit into. So you might think about the next time someone asks a question, is – answering the question is partly about figuring out what their conceptual model is, so you can help them build it.

And nothing is magic. I think that was – that’s something that all of us sometimes have to remember, is that that thing that someone else is doing that seems impossibly hard, or the thing someone else knows that’s full of all this jargon – if we try different ways, if we ask the right questions and set up nurturing learning environments, we can learn it. It’s not magic. And I didn’t have that belief before I think I came into Hacker School a little bit afraid of certain buzzwords, as though they were just impossibly hard. And that was a change for me. You may have heard of Carol Dweck's research on the fixed versus the growth models of how we look at the world and learning. The short summary is, if you believe that talent is nurture and practice, then you’ll grow. But if you believe that some people are just good at X, if it’s inborn or nature, then we won’t learn. And I was able to learn at Hacker School because it was safe to fail. If you’re going to try things, you’re going to fail sometimes, you’re going to make mistakes in front of other people, and people learn a lot slower if they’re afraid to fail, if they’re slower to ask questions.

The No Asshole Zone

So how does that work? How do you make people feel more okay about working in public, which includes sometimes failing or showing ignorance? Well, a No Asshole zone really helps.

(laughter)

So remember when I talked about the selection process? Part of the interview and admissions was a pair programming interview where you tried to solve a small programming problem over the internet, and the main point was not "How good are you as a programmer?" It’s "How well do you deal with frustration, and do you turn into a jerk when you're trying to solve a problem with someone else or teach someone something?" ‘Cause it’s kind of hard to really keep the jerkitude inside, I think, when you’re, like, a little bit frustrated and you’re trying to work with somebody for that. And those people got rejected. It was amazing what a pleasure it was to be in a room with 58 other people, all of whom had specifically been chosen for their ability to collaborate with others.

Also, to keep us from accidentally discouraging other people from doing the things they need to do to learn, at Hacker School there are four social rules. These are social rules to help everyone feel okay with failure and ignorance. No feigned surprise. No well-actuallys. No back-seat driving. And no sexism, racism, homophobia, and so on. Now, the user manual, which is available online, does a great job explaining all these, and I’m going to talk about the first two, because they’re most important for our context.

Feigning surprise. When someone says “I don’t know what X is”, you don’t say “You don’t know what X is?!” or “I can’t believe you don’t know what X is!” Because that’s just a dominance display. That’s grandstanding. That makes the other person feel a little bit bad and makes them less likely to show you vulnerability in the future. It makes them more likely to go off and surround themselves in a protective shell of seeming knowledge before ever contacting you again.

Well-actuallys. That’s the pedantic corrections that don’t make a difference to the conversation that’s happening. Sometimes it’s better to err on the side of clarity rather than precision. Well-actuallys are breaking that. You sometimes see, when people actually start trying to take this rule in, that in a conversation, if they have a correction, they struggle and think about it. Is it worth making? Is this actually important enough to break the flow of what other people are learning and getting out of this conversation. Kind of like I think we in Wikimedia world will say "This might be bikeshedding but -". It’s a way of seeing that this rule actually has soaked in.

I think it’s also important to note, well, how do these rules get enforced? Well, all of us felt empowered to say to anyone else, quickly and a bit nonchalantly, “Hey, that was a well-actually,” or “That’s kind of feigned surprise, don’t you think?” And the other person said sorry, and moved on. I can’t tell you how freeing it felt that first week, to say "I don't know" a million times. Because I had been trained not to display ignorance for fear of being told I didn't belong.

We have the 4 social rules up on the wall, framed, at Hacker School, and sometimes people will, while referencing it, unconsciously turn their bodies towards them, because it’s that much in our core values. If you don’t understand why something you did broke the rules, you don't ask the person who corrected you. You ask a facilitator. You ask someone who’s paid to do that emotional labor, and you don't bring everyone else's work to a screeching halt. This might sound a little bit foreign to some of us right now. Being able to ask someone to stop doing the thing that’s harming everyone else’s work and knowing that it will actually stop and that there’s someone else who’s paid to do that emotional labor who will take care of any conversation that needs to happen.

Vulnerability

Community management is a first-class responsibility at Hacker School. Every one of the five facilitators who are the only employees at Hacker School are community managers. That’s a big part of their job. They will help with any kind of problem, including the brains of everyone trying to work, and including helping you with having a bad day, with your emotional fears and anxieties as well. Emotions are first class citizens. If you are having a bad day, if you are worried about being good enough, if you find it demoralizing that someone told you were wasting your time trying to contribute to some open source project, you are not weak for having these problems and talking about them openly. If we are publicly vulnerable then we can also help each other.

Speaking about being vulnerable, now's when I talk about what it's like to be a woman in Wikimedia. Especially when I'm the only woman in the room. There's an xkcd about what it feels like to be the only woman in the room. That's number 385, for those of you who do XKCD by number. A guy makes a mistake solving a math problem, and another guy says, "Wow, you suck at math." A woman makes the same mistake, and a guy says, "Wow, girls suck at math."

Which happens to me – I feel that way, I worry about that – a fair amount in Wikimedia world. Especially in the engineering spaces, where I spend most of my time. The Zurich hackathon was 14% women, I believe, earlier this month, and that was the most I’ve ever seen. It was amazing to not always be the only woman in the room. But at Hacker School there were 42% women in my batch. There were dozens of other women. It made a tremendous difference to me. I didn’t know all the women’s names at the end of the first week! That was amazing to me! And there were so many different kinds of women, as there were different kinds of people. Some of them had been programming for two months, some for twenty years, like kernel hacking. Some of them were interested in back-end development, in machine learning, in visual learning, various different kinds of things. No matter who I wanted to become, there was someone who looked like me. There was someone who could talk to me in my register. And we had conversations with everybody, but because half the people were women, half my conversations were with women, and if I failed at something, it was very unlikely that I was carrying the banner for all womankind.

The How Learning Works book points out that we have known about stereotype threat since 1995. We have known that if you point out to members of a marginalized group “Hey, hi there Member of Marginalized Group, did you know you’re marginalized here?”, that’s going to decrease performance and their willingness to be vulnerable. And there are different kinds of accepting climates for marginalized groups. DeSurra and Church, also in How Learning Works, talk about the climate for people who are LGBT. A community might be explicitly marginalizing, overtly discriminatory; implicitly marginalizing, subtly excluding certain groups; implicitly centralizing, welcoming of alternate perspectives, can validate them, but it's on the minority group still to bring the topic up even though it’s okay when they do. And then there’s explicitly centralizing the alternate perspective. Bringing up and welcoming alternate perspectives without those minority students needing to do that work. A teacher, for instance, bringing it up in syllabi, in the first discussion.

In the book Women's Ways of Knowing around community confirmation, there’s also an observation that some groups, especially many women, find that confirmation and community are prerequisites rather than consequences of learning certain hard things. When you look at how our editathons have been able to increase attendance by women by starting with the social aspect, I think you can see how this plays out in practice. Software Carpentry, another learning outreach project, has also been able to increase attendance by underrepresented groups at their bootcamps by suggesting that people bring their friends.

Liberty and hospitality

So Hacker School provided a relaxing learning community for me where I could fail safely and I had role models. It was great. I learned a lot. And then in January, when I came back to work, I felt like a fish who had taken a three-month break from the water she swims in, and wow, it was demoralizing. It is – we have demoralizing people in the Wikimedia community, and we have some demoralizing processes in places, and some of us have gotten used to it, but then there’s the people who are leaving or who are thinking of leaving, or who never even come in. It’s super demoralizing to be in a world where some people seem to follow the opposite of those four social rules, like those are the key tactics in how they relate to others. I was able to able to articulate this to myself as the spectrum of liberty versus hospitality. The Wikimedia movement really privileges liberty, way over hospitality. And for many people in the Wikimedia movement, free speech, as John Scalzi put it, is the ability to be a dick in every possible circumstance.

Criticize others in any words we like, change each other's words, and do anything that is not legally prohibited. Hospitality, on the other hand, is thinking more about right speech, just speech, useful speech, and compassion. We only say and do things that help each other, the first responsibility of any citizen is to help each other achieve our goals, and make each other happy.

I think these two views exist on a spectrum, and we are way over to one side, and moving closer to the middle would help everyone learn better and would help us keep and grow our contributor base.

What we should do

So what should we do? Well, I'm going to point to a few sets of recommendations now, at a very high level, and only talk about a few of them. And, as I mentioned, there’s a bunch of links on my blog at this very moment that I’ll also be linking around.

There are recommendations from Ada Initiative's Valerie Aurora, in her session at the Wikimedia Diversity Conference in October. The slides and notes from that session are up. And one of them is to think carefully about what we do in super-public versus how we act in invite-only space or quite private spaces, and to think about what those spaces are. I think of the spaces that are more secret or private as places where certain people can sort of rest and vent and collaborate, and ask the questions they feel afraid of asking in public, so they can gain the strength and confidence to go further out, into the invite-only spaces or the very public spaces. I think we’ve seen this in my own experience at Hacker School, and we see that also the invite-only spaces, or spaces where everybody coming in agrees to follow the same rules so it’s a place where you feel safer, these are like tidepools, places where certain kinds of people and certain kinds of behaviour can be nurtured and grown so that it’s ready to go out into the wider ocean.

We can also modify existing spaces. We can set up informal but real contracts or promises with specific people or in specific larger spaces. I’ve done this. I’ve said “Hey, for this conversation – I know in the past we’ve had trouble assuming good faith of each other. Will you try – I will try extra hard to assume good faith of you if you’ll assume good faith of me.” And that actually made things go a lot better.

Valuing hospitality, another thing I’d like us to do. When someone is criticized for doing something inhospitable, the first response needs to not be “Oh, but remember their edit count. Remember he’s done X or she’s done Y for this community.” We need to start treating hospitality as a first class virtue, and see that it is the seed of everything else. Alberto Brandolini said “The amount of energy necessary to refute bullshit is an order of magnitude bigger than to produce it.” It has a big cost when someone treats others badly. If someone is ruining the hospitality of a place by using their liberty in a certain way, we need to stop making excuses, and start on the path of exclusion. If we exclude no one explicitly, we are just excluding a lot of people implicitly. Including people like me.

The Hacker School social rules. I personally have started following them all the time, not just at Hacker School, and I'd encourage you to do the same. Maybe we could even get userboxes!

(laughter)

Is that how everything changes, right? In Wikimedia? Just get the right userbox. Also let’s go to Karen Sandler’s presentation this afternoon, here at Wiki Conference USA, called "Bringing More Women to Free Software: What's Working for Us". That’s about another different kind of learning environment that’s more like Wikimedia in some ways that Hacker School is. The outreach program for women is a mentorship and learning project that MediaWiki, Wikidata, and a number of other aligned groups and organizations participate in. So let’s go over there and talk and learn more! And I’m also happy to talk more about this stuff in the hallways, and during the Unconference day. Possibly I’ll offer you my hand sanitizer, because I am still a little bit sick.

And any time that you’re talking with someone who knows less than you about something, you have an opportunity to teach them. And this includes in those OnWiki conversations, in IRC, in the bug tracker, in RT, in the outreach – behind the scenes on those outreach days, everything! There are three really important things that will help you teach them. Learning is designable like code. Our brains are snowflakes; different people learn differently. And we do not function stand-alone. We learn in communities. We learn from and with each other. And we’re all doing this together. Thank you.

Credits

Transcribed by Katherine Nehring.