Cogito, Ergo Sumana

picture of Sumana's head

Sumana Harihareswara's journal

: Answering the Phone: In one of my earliest internships, I volunteered in the local district office of my state Senator (that is, the guy who represented my area in the upper chamber of California's state legislature). I reordered and rearranged informational brochures for our waiting area, I filed, I took phone messages, I think eventually I graduated to writing drafts of replies to constituents for the staffers to revise and send. I volunteered there for a summer, which means that my time there overlapped with the Senate's recess, so I remember a lot more constituent service calls than policy calls -- and the district offices probably got fewer of those calls than the Sacramento office did, anyway.

One day, someone called and said something like, "I'm calling about the Senator's ethics violation." I had never heard anything about this and said "I'm sorry, which ethics violation is that?" to which the caller said "You mean there's more than one?!" I sputtered and put them on hold and took a message or transferred them to a staffer, which I clearly should have done as soon as I heard the tone of their voice and their general topic of inquiry, but hey, inexperience.

Within a few days, there was a letter to the editor in the local newspaper that mentioned this call and named me (I'm pretty sure misspelling my name) while excoriating the Senator and our office. My boss and colleagues sympathized and told me these things happen, and basically reassured me that this was not a black mark on my Permanent Record.

Decades later, I'm calling my local city councilmember, my Senators and my Representative who represent me in Congress, and related offices, spurred by emails from NGOs, aggregators like "We're His Problem Now" or Wall of Us, and local meetings. And sometimes I stumble over my words, not sure whether they want my name first or my message. But when the intern on the other end of the line says "I don't know what her position is on that; could you call back in 15 minutes? All the staffers who would know are in a meeting right now," I can smile and say "Yes, I can, and I know how it is, I've been on the other end of this call, it's fine." And at least I know I'm not utterly blindsidingly frustrating to deal with. I know, empirically, that I am not as bad as it gets.

: Clover: On Sundays I make omelets. Today's omelets included three diced cloves of garlic.

"I wish to make you aware that we are basically in a garlic ratchet. I will be increasing the number of cloves of garlic involved in our Sunday omlets basically ad infinitum. In sort of a manigarlic destiny approach. So if at some point you find it's going too far, well, file a complaint with your local consulate."

"Well, since I am the one who buys the garlic, I think I can pretty effectively --"

"Oh, that's where the executive orders come in. You think you control appropriations?"

"Are you going to draw from the Strategic Garlic Reserve?"

"There's a slush fund."

(I see that I sort of went from early US President to ... emperor? ... to modern US President over the course of this flight of fancy.)

Filed under:

: Podcast Recommendations: Podcasts I've been enjoying listening to recently include the following (I have not made my way through the back catalog of all of these, by the way):

: Election Day: Sumana in a chair, smiling, wearing an 'I Voted' stickerI voted today.

Starting Saturday, and for a bunch of Sunday and Monday, I phone-banked and text-banked for the Clinton/Kaine campaign. I also caught up with a few aunts and uncles of mine to remind them to vote, and to ask them to vote for Hillary Clinton.

One aunt of mine has stage IV cancer. It's inoperable. She has trouble getting around but her son will drive them both to the polls tomorrow. If she can't get out of the car, poll officials will come to her and bring her a ballot.

Today I put on a pantsuit and went to our pollsite to cast my ballot. We got there maybe fifteen minutes after the polls opened. Already a long, quiet line curved around the block, under early light in a clear sky.

In New York State: watch out for the so-called "Women's Equality Party".

In New York City: The official government poll site locator site will also tell you your electoral and assembly district, which might help you bypass the first queue when you get to your polling place.

Everywhere in the United States (and for US citizens abroad): helps you confirm where you'll vote and learn voting requirements (such as whether your state requires you to bring ID).

Several US states have same-day voter registration so you can register and vote today.

If you're having trouble voting, you can call the Election Protection Hotline.

  • 866-OUR-VOTE (866-687-8683) -- English language hotline
  • 888-VE-Y-VOTA (888-839-8682) -- Spanish language hotline
  • 888-API-VOTE (888-274-8683) -- Chinese, Vietnamese, Korean, Bengali, Hindi, Urdu, Tagalog
  • 1-844-418-1682 -- Arabic language hotline

Spanish speakers in the US can also text VOTA to 47246 for voting help.

Now: more phone-banking.

: Book Catch-up: I need to catch up with my book reviews or at least log some of the books I've read and liked. I have some notes going back more than a year -- I'll do a very uneven and incomplete recounting just to start catching up.

In mid-2015, for instance, I read and enjoyed several stories in the Kaleidoscope anthology, Andrea Phillips's Revision, Jennie Crusie's Bet Me and Welcome to Temptation, a big chunk of Thomas Merton's New Seeds of Contemplation, about a third of Charles Platt's interview collection Dream makers: the uncommon people who write science fiction, and more. And I reread Losing Joe's Place by Gordon Korman. I remember the first time I ever read Losing Joe's Place, in a childhood bedroom in Stockton, to calm and entertain myself after a scary episode of Unsolved Mysteries. It still holds up as comfort reading.

This year I reread Ann Leckie's Imperial Radch trilogy (Ancillary Justice, Ancillary Sword, Ancillary Mercy). I'd read them as they came out but this was the first time I read them all in a row. As I mentioned in a Making Light comment which is a longer review of the third book (but I softened my view upon rereading), I thought the shape of the books' narratives was interesting -- the first book is like an arrow, and the second is like a V, going from spaceship (and functional community) to space station to planet and back again. What's the third one like? Another commenter, TexAnne, said: an orbit. Yes. These are books about power-over versus power-with, about an unreliable narrator, about the Borg as protagonist, about complicity, and -- Ancillary Sword especially -- trying to give up privilege when it's superglued to your hand and won't come off (Of Noble Family by Mary Robinette Kowal takes on that same issue and it's a reason I'm fond of them both). The most resounding and heartbreaking bit of Ancillary Sword is Queter saying that she can make you look at it. Zeiat's demonstration of cakes and counters -- how we socially construct differences & sameness -- has an enthusiastic explication by JJ Hunter. I'm reminded of the comparison in Emily Nagoski's book Come as You Are: The Surprising New Science that Will Transform Your Sex Life of us and constellations -- the effect of having the same parts, but arranged differently, can be tremendous. (And there's now a fan trailer for the Imperial Radch books!)

More as logging than as reviewing: I haven't yet blogged here about reading Too Like the Lightning by Ada Palmer, Known Associates by thingswithwings, Hold Me and other recent works by Courtney Milan, Seveneves by Neal Stephenson, Making Conversation by Teresa Nielsen Hayden, the Hamilton book, Zen Cho's The Terracotta Bride, Ken Liu's The Grace of Kings, Jeannie Lin's The Lotus Palace, The Unbeatable Squirrel Girl written by Ryan North, Colson Whitehead's The Underground Railroad, part of Breaking the Bow: Speculative Fiction Inspired by the Ramayana, and probably other books. And I want to note that in the last year I've reread, or reread most of, Inherent Vice by Thomas Pynchon, Travels by Michael Crichton, Zodiac by Neal Stephenson, American Taxation, American Slavery by Robin Einhorn, The Hundred Thousand Kingdoms by N.K. Jemisin, How To Win Friends and Influence People by Dale Carnegie, Getting to Yes by Fisher and Ury, A Semester in the Life of a Garbage Bag by Gordon Korman, and Dear Mr. Henshaw by Beverly Cleary -- plus probably other stuff I'm not remembering off the top of my head. I read Octavia Butler's Parable of the Talents and Parable of the Sower, one of which I'd read before and one of which I hadn't. Bracing, and inspiring the way that memoirs of successful activists can be inspiring.

Right now I'm making my way through Elinor Ostrom's Nobel Prize lecture, "Beyond Markets and States: Polycentric Governance of Complex Economic Systems", and Thomas Pynchon's Bleeding Edge.

Filed under:

(1) : Political Memories: I've been reminiscing about past US elections and administrations.* I've been paying attention to US federal politics since the early nineties, which means I remember a lot of details that many younger politics enthusiasts don't. I decided to dredge some of them up:

I imagine some of my readers will be utterly uninterested in this litany, and some will be a little curious, and some will say "AGGGGH" and remember a bunch of things they thought they had forgot in a partially pleasing and partially disorienting experience. I will admit that this entry is mostly aimed at that last group.

* I misheard Leonard or something and we came up with the phrase "Munchin' Accomplished" which he immediately realized ought to be the name of a George W. Bush-administration-themed food cart. It would serve:

  • Freedom fries
  • Pretzels
  • "Condoleezza" rice (her name is Italian, so, risotto maybe?)
Filed under:

(1) : How Do We Encourage Technologists in the Public Interest?: As I mentioned when the Recompiler interviewed me, my inspirations and role models in technology are technologists who serve the public interest. The person who introduced me to free and open source software, Seth Schoen, is a kind teacher and a rigorous thinker who deploys his software engineering expertise at the intersection of technology and activism. I was lucky enough to meet the right people early in my career so I see public interest technology as a desirable and viable career path AND something you can integrate into a career that doesn't focus on nonprofit/government work -- but not enough people know about it, and not enough institutions encourage it.

How do we help encourage and employ more Seths, more Bruce Schneiers, more Eleanor Saittas, more Kelsey Gilmore-Innises? If you were to say "Sumana, that's a pretty infosecurity-centric list there, what about people who are more about analytics to enable policy work, or the web developers at 18F, or --" then I would agree with you! This is a broad and deep field, and thus a broad and deep question.

Again and again, we were told that public interest organizations and government will not succeed if they do not quickly figure out how to better harness the wave of innovation sweeping the world, and that one key element of that challenge will be to implement more effective strategies for developing and integrating technologists into relevant organizations and projects.
That is from A Pivotal Moment: Developing a New Generation of Technologists for the Public Interest, a new report that aims to help philanthropists choose what to fund (and how) to make this change happen. This is not just a bunch of vague "let's grow the pipeline" stuff. The authors interviewed 60 experts, laid out 26 specific things we can do (many of which are already in progress), and made a bunch of recommendations. Section III, starting on page 10 (page 16 of the PDF), summarizes the interventions in five categories: interest cultivation, skill-building, recruitment and training, skill deployment, and growth and retention.

If you can influence decisions on grants or donations, or if you just want a framework for thinking about this problem and its solutions (and where your existing work sits in the ecology), check out the report.

: Learning Styles: For years, while mentoring others, I've been using these engineering learning styles as a tool to help newer engineers reflect on how they learn, and to give them a sense of the possible toolbox of learning approaches, so that if they get stuck, they can recognize what approach they're using and try another one. But students don't have different learning styles, really, per science-based required reading for a Software Carpentry train-the-trainer class I'm about to attend. I need to rework my advice.

: New Zine "Playing With Python: Two of My Favorite Lenses":

half-scratched-out bpython logo, Python code, and technical prose written and drawn on paper, with notebook and pen, on a wooden table that also has a mug and a laptop on it

MergeSort, the feminist maker meetup I co-organize, had a table at Maker Faire earlier this month. Last year we'd given away (and taught people how to cut and fold) a few of my zines, and people enjoyed that. A week before Maker Faire this year, I was attempting to nap when I was struck with the conviction that I ought to make a Python zine to give out this year.

So I did! Below is Playing with Python: 2 of my favorite lenses. (As you can see from the photos of the drafting process, I thought about mentioning pdb, various cool libraries, and other great parts of the Python ecology, but narrowed my focus to bpython and python -i.)

Zine cover; transcription below

Playing with Python
2 of my favorite lenses
[magnifying glass and eyeglass icons]

by Sumana Harihareswara

Second and third pages of zine; transcription below

When I'm getting a Python program running for the 1st time, playing around & lightly sketching or prototyping to figure out what I want to do, I [heart]:
bpython & python -i

[illustrations: sketch of a house, outline of a house in dots]

Fourth and fifth pages of zine; transcription below

bpython is an exploratory Python interpreter. It shows what you can do with an object:

>>> dogs = ["Fido", "Toto"]
>>> dogs.
append count extend index insert pop remove reverse sort

And, you can use Control-R to undo!

[illustrations: bpython logo, pointer to cursor after dogs.]

Sixth and seventh pages of zine; transcription below

Use the -i flag when running a script, and when it finishes or crashes, you'll get an interactive Python session so you can inspect the state of your program at that moment!

$ python -i
Traceback (most recent call last):
    File "", line 5, in 
        toprint = varname + "entries"
TypeError: unsupported operand type(s) for + : 'int' and 'str'
>>> varname
>>> type(varname)

[illustration: pointer to type(varname) asking, "wanna make a guess?"]

Back cover of zine; transcription below

More: "A Few Python Tips"
This zine made in honor of
NYC's feminist makerspace!

CC BY-SA 2016 Sumana Harihareswara @brainwane

Everyone has something to teach;
everyone has something to learn.

Laptop displaying bpython logo next to half-scratched-out bpython logo, Python code, and technical prose written and drawn on paper, with notebook and pen and mug, on a wooden table

Here's the directory that contains those thumbnails, plus a PDF to print out and turn into an eight-page booklet with one center cut and a bit of folding. That directory also contains a screenshot of the bpython logo with a grid overlaid, in case you ever want to hand-draw it. Hand-drawing the bpython logo was the hardest thing about making this zine (beating "fitting a sample error message into the width allotted" by a narrow margin).

Libby Horacek and Anne DeCusatis not only volunteered at the MergeSort table -- they also created zines right there and then! (Libby, Anne.) The software zine heritage of The Whole Earth Software Review, 2600, BubbleSort, Julia Evans, The Recompiler, et alia continues!

(I know about bpython and python -i because I learned about them at the Recurse Center. Want to become a better programmer? Join the Recurse Center!)

(1) : Rough Notes for New FLOSS Contributors On The Scientific Method and Usable History: Some thrown-together thoughts towards a more comprehensive writeup. It's advice on about how to get along better as a new open source participant, based on the fundamental wisdom that you weren't the first person here and you won't be the last.

We aren't just making code. We are working in a shared workplace, even if it's an online place rather than a physical office or laboratory, making stuff together. The work includes not just writing functions and classes, but experiments and planning and coming up with "we ought to do this" ideas. And we try to make it so that anyone coming into our shared workplace -- or anyone who's working on a different part of the project than they're already used to -- can take a look at what we've already said and done, and reuse the work that's been done already.

We aren't just making code. We're making history. And we're making a usable history, one that you can use, and one that the contributor next year can use.

So if you're contributing now, you have to learn to learn from history. We put a certain kind of work in our code repositories, both code and notes about the code. git grep idea searches a code repository's code and comments for the word "idea", git log --grep="idea" searches the commit history for times we've used the word "idea" in a commit message, and git blame shows you who last changed every line of that codefile, and when. And we put a certain kind of work into our conversations, in our mailing lists and our bug/issue trackers. We say "I tried this and it didn't work" or "here's how someone else should implement this" or "I am currently working on this". You will, with practice, get better at finding and looking at these clues, at finding the bits of code and conversation that are relevant to your question.

And you have to learn to contribute to history. This is why we want you to ask your questions in public -- so that when we answer them, someone today or next week or next year can also learn from the answer. This is why we want you to write emails to our mailing lists where you explain what you're doing. This is why we ask you to use proper English when you write code comments, and why we have rules for the formatting and phrasing of commit messages, so it's easier for someone in the future to grep and skim and understand. This is why a good question or a good answer has enough context that other people, a year from now, can see whether it's relevant to them.

Relatedly: the scientific method is for teaching as well as for troubleshooting. I compared an open source project to a lab before. In the code work we do, we often use the scientific method. In order for someone else to help you, they have to create, test, and prove or disprove theories -- about what you already know, about what your code is doing, about the configuration on your computer. And when you see me asking a million questions, asking you to try something out, asking what you have already tried, and so on, that's what I'm doing. I'm generally using the scientific method. I'm coming up with a question and a hypothesis and I'm testing it, or asking you to test it, so we can look at that data together and draw conclusions and use them to find new interesting questions to pursue.


  • Expected result: doing on your machine will give you the same results as on mine.
  • Actual observation: you get a different result, specifically, an error that includes a permissions problem.
  • Hypothesis: the relevant directories or users aren't set up with the permissions they need.
  • Next step: Request for further data to prove or disprove hypothesis.
So I'll ask a question to try and prove or disprove my hypothesis. And if you never reply to my question, or you say "oh I fixed it" but don't say how, or if you say "no that's not the problem" but you don't share the evidence that led you to that conclusion, it's harder for me to help you. And similarly, if I'm trying to figure out what you already know so that I can help you solve a problem, I'm going to ask a lot of diagnostic questions about whether you know how to do this or that. And it's ok not to know things! I want to teach you. And then you'll teach someone else.

In our coding work, it's a shared responsibility to generate hypotheses and to investigate them, to put them to the test, and to share data publicly to help others with their investigations. And it's more fruitful to pursue hypotheses, to ask "I tried ___ and it's not working; could the reason be this?", than it is to merely ask "what's going on?" and push the responsibility of hypothesizing and investigation onto others.

This is a part of balancing self-sufficiency and interdependence. You must try, and then you must ask. Use the scientific method and come up with some hypotheses, then ask for help -- and ask for help in a way that helps contribute to our shared history, and is more likely to help ensure a return-on-investment for other people's time.

So it's likely to go like this:

  1. you try to solve your problem until you get stuck, including looking through our code and our documentation, then start formulating your request for help
  2. you ask your question
  3. someone directs you to a document
  4. you go read that document, and try to use it to answer your question
  5. you find you are confused about a new thing
  6. you ask another question
  7. now that you have demonstrated that you have the ability to read, think, and learn new things, someone has a longer talk with you to answer your new specific question
  8. you and the other person collaborate to improve the document that you read in step 4 :-)

This helps us make a balance between person-to-person discussion and documentation that everyone can read, so we save time answering common questions but also get everyone the personal help they need. This will help you understand the rhythm of help we provide in livechat -- including why we prefer to give you help in public mailing lists and channels, instead of in one-on-one private messages or email. We prefer to hear from you and respond to you in public places so more people have a chance to answer the question, and to see and benefit from the answer.

We want you to learn and grow. And your success is going to include a day when you see how we should be doing things better, not just with a new feature or a bugfix in the code, but in our processes, in how we're organizing and running the lab. I also deeply want for you to take the lessons you learn -- about how a group can organize itself to empower everyone, about seeing and hacking systems, about what scaffolding makes people more capable -- to the rest of your life, so you can be freer, stronger, a better leader, a disruptive influence in the oppressive and needless hierarchies you encounter. That's success too. You are part of our history and we are part of yours, even if you part ways with us, even if the project goes defunct.

This is where I should say something about not just making a diff but a difference, or something about the changelog of your life, but I am already super late to go on my morning jog and this was meant to be a quick-and-rough braindump anyway...

Filed under:

: Analogy: At MidAmericon II I got to shake hands with Dr. Stanley Love and tell him that I liked his speech (he had accepted the Campbell Award for Best New Writer on behalf of his friend Andy Weir). When I later recounted this to friends I found myself saying things like "I reassured an astronaut, which means I will surely go to heaven" or "I couldn't lie to an astronaut! That's a sin!"

This led me to realize that astronauts are, vaguely, to the general US public now as Catholic nuns (at least schoolteacher nuns) were to previous generations. They are cloistered away to be closer to heaven. They have to live in close quarters and collaborate under conditions of micromanagement. They go through arduous selection processes and care a lot about education. Nuns had Rome, astronauts have Houston. We are in awe of their dedication and endurance and altruism and grace. And just the sight of one of their uniforms/habits triggers that reaction of awe.

(Your mileage may vary, conditions may apply, vanity, vanity, all is vanity.)

Filed under:

: iCalendar Munging with Python 3, Requests,, and Beautiful Soup: Leonard and I love seeing movies at the Museum of the Moving Image. Every few months we look at the calendar of upcoming films and decide what we'd possibly like to see together, and put it on our shared calendar so we remember. And for every showing (example) the MoMI provides an iCalendar (.ics) file, to help you add it to your electronic calendar. But it's a pain to individually download or refer to each event's .ics file and import it into my electronic calendar -- and the museum's .ics files' DTEND times are often misleading and imply that the event has a duration of 0 seconds. (I've asked them to fix it, and some of their calendar files have correct durations, but some still have DTEND at the same time as DTSTART.)

Saturday morning I had started individually messing with 30+ events, because the MoMI is doing a complete retrospective of Krzysztof Kieslowski's films and I am inwardly bouncing up and down with joyous anticipation about seeing Dekalog again. And then I thought: I bet I can automate some of this tedious labor!

bash terminal showing the successful output of a Python script (a list of movie titles and "Calendar ready for importing: MoMI-movies-chosen-2016-09-26.ics") So I did. The script (Python 3) takes a plain text file of URLs separated by newlines (see movie-urls-sample-file.txt for an example), downloads iCalendar files from the MoMI site, fixes their event end times, and creates a new unified .ics file ready for import into a calendar. Perhaps the messiest bit is how I use a set of regular expressions, and my observations of the customs of MoMI curators, to figure out the probable duration of the event.


  • It can be a bit slow as the number of URLs adds up -- it took maybe 5 minutes to process about 31 events. I oughta profile it and speed it up. But I usually only need to do this about six times a year.
  • This script is not careful, and will overwrite a previously created .ics file at the same address (in case you're running it twice in one day). It has no tests and approximately no error-checking. This was a scratch-my-own-itch, few-hours-on-a-Saturday project. No Maintenance Intended. 'no maintenance intended' badge
  • Absolutely not an official project of the Museum of the Moving Image.
Much thanks to the programming ecology that helped me build this, especially the people who made RegExr, Beautiful Soup (hi Leonard), Requests,, and the bpython interpreter, and the many who have written excellent documentation on Python's standard library. Thanks also to Christine Spang, whose "Email as Distributed Protocol Transport: How Meeting Invites Work and Ideas for the Future" talk at Open Source Bridge 2015 (video) introduced me to hacking with the iCalendar format.

: New Essay: "Toward a !!Con Aesthetic": Over at The Recompiler, I have a new essay out: "Toward A !!Con Aesthetic". I talk about (what I consider to be) the countercultural tech conference !!Con, which focuses on "the joy, excitement, and surprise of programming". If you're interested in hospitality and inclusion in tech conferences -- not just in event management but in talks, structure, and themes -- check it out.

Christie Koehler also interviews me about this and about activist role models, my new consulting business, different learning approaches, and more in the latest Recompiler podcast.

[announcement cross-posted from Geek Feminism]

: Habit, Identity, Self-Care, and Shame: Lately I've been working to acknowledge and honor the difference it makes to me to invest in various activities and habits when they do make a difference to me. Exercising every day, and setting out my workout stuff the night before so I can just grab it in the morning. Witnessing live music. Talking with friends via voice or in person, more often than would happen by chance. Using Beeminder to increase the quantity and frequency of good habits, and LeechBlock to reduce the amount of time I spend on Twitter or MetaFilter. Praying every day. Keeping my work area and my chunk of the bedroom relatively uncluttered, so I feel more peaceful and focused. And beside the noticeable positive effects are some strange echoes and murmurs that are also worth attention.

When the bedstand and bureau and desk are clear of clutter, sometimes I feel unmoored, as though I am surely just moved into or about to move away from this apartment. A life with great expanses of unused horizontal surface area is unfamiliar enough to me that it feels liminal, not mine. Yet, anyway; perhaps I can get used to it.

And sometimes, I feel shame about what I want or need, shame about what sustains me. This is different from anti-"guilty pleasure" bias. I engage in self-care in response to specific stress or disappointment. When a blow hits me, I curl up with the latest Courtney Milan romance novel and some combination of tea, cognac, corn nuts, and chocolate. And feminism has helped me overcome fatphobic and anti-feminine prejudice that castigated these forms of comfort. For instance, I now much more rarely use the word "trashy" for a certain genre of fiction; just as Disneyland takes a hell of a lot of engineering, fiction that conveys engaging characters and a diverting plot through accessible prose takes quite a lot of craft. And besides, what I'm feeling isn't guilt anyway; guilt is about what you've done. Shame is about what you are.

I can see that it helps me to use Beeminder and LeechBlock, to exercise, to pray, to make people laugh, to see live music. So why the sense of shame? I think it's because if I like or need those things, then I am not entirely autonomous, I am not entirely self-disciplined, I am not a brain in a jar. My body needs things, my sociability needs to be fed, my focus and persistence need assistance. The analysis presented by the social model of disability holds true here; I get the message that the way I am is wrong, but when I stop accepting that assumption and start systematically asking "why?", I figure out that it's because there's an assumption in my head that I should be as efficient and autarkic as a space probe.

So perhaps, along with "trashy", I should watch out for places in my internal narrative where "need" and "weak" and "strong" show up. Because yes, I need, and maybe needing feels weak, but if I recognize that need and then take care of it, aren't I strong as well?

I'm also disentangling my intuitions about care and power. I am the one setting up these habits, these guardrails, and I'm doing it as self-love, not as self-punishment or as a power play against another faction of myself. My mindfulness meditation practice has been reminding me to be less clingy about what I think my identity is, and Emily Nagoski's excellent Come as You Are: The Surprising New Science that Will Transform Your Sex Life suggests it's helpful to think of one's self as a swarm or constellation. This approach helps me get less hierarchical about all the varying bits of me. So instead of rebelling, I can say "argh" and then say to myself "yeah I know" and then breathe and do the process anyway.

And I can see how I need to show myself self-love via accommodation. I am like both the builder of the building and the person with accessibility needs who needs to use that building. Wouldn't I want some other builder to build hospitably, and wouldn't I want other building users to joyfully make full use of the accommodation available?

And that loving approach, plus seeing my past successes, makes it easier for me to work the way that works for me. Timers, minigoals, setting up mise-en-place ahead of time. The timers and minigoals don't have to be optimal, just right enough to get me in the right neighborhood, then iterate from there. I can have patience and trust the process.

Perhaps the biggest change, the biggest unmooring, is to my identity. I was always behind on correspondence, always surrounded by clutter, fairly sedentary, and I had not realized how these formed part of the furniture of my mind until I started dismantling them. I am curious what the new configuration will be, and whether it will have a chance to consolidate before another set of changes begins.

Thanks to my friend J. and my friend and meditation teacher Emily Herzlin for conversations that led to this post.

Filed under:

: Grief: It's been a tough week. Wednesday of last week, I learned that Kevin Gorman had died. He was only 24 years old. I met Kevin through my work at the Wikimedia Foundation. He was a feminist activist who put a tremendous amount of energy into making Wikipedia a better resource for everyone. He added and improved articles, and he taught others, and he took on the emotional work of moderating and responding to voices that were arguing against feminists, and of fighting harassment (in all his communities). As he said on his user profile:

I dislike systemic biases; both those caused by our gender, racial, and geographic biases, and those caused by no abstract available bias and its kindred. One of my stronger interests on Wikipedia is making available online in a freely available format content that cannot be currently be found on the Wikimedia projects because of our systemic biases. I think that this is some of the most important work that can be done on Wikipedia at this time.

I had known that he'd been fighting various illnesses for some time, but I was still shocked to hear of Kevin's death; he was far too young. My condolences to his family and his friends and his many collaborators in free knowledge and justice. Kevin and I didn't have that many conversations but in every one I heard his deep passion for the work of improving our culture on all levels; he never ceased to be shocked at things that aren't right, and to channel that shock into activism and organizing. I will miss his dedication and I will remember his ideals.

He was only 24. As I handle more and more death I come to learn which deaths cause more painful griefs. I seem to believe, somewhere deep inside, that people younger than me really shouldn't die, that it breaks an axiom.

And then the next day I learned that Chip Deubner had died. Further shock and grief. I met Chip because we worked together at the Wikimedia Foundation; he was a desktop support technician, and the creator and maintainer of the audiovisual recording and conference systems, and then rose to manage others. And I can attest to his work ethic -- he cared about the reliability of the tools that his colleagues used to do their work, and he was that reliable himself, ready at a moment's notice to take on new challenges. He demonstrated a distinctive combination of efficiency and patience: help from Chip was fast, accurate, effective, and judgment-free. If anything, he was too reticent to speak up about his own frustrations. I was glad to see him grow professionally, to take on new responsibility and manage others, and I'm glad he was able to touch so many lives in his time on earth -- I only had a few memorable conversations with him, since he lived in the Bay Area and I mostly telecommuted from New York, but I know he enjoyed office karaoke and that many WMF folks counted him as a friend, and grieve him as one. He was a maintainer and a keeper and a maker of things, in a world that needs more such people. He will be in my thoughts and my prayers. (I wrote much of this in a guestbook that might decay off the web, so I'm publishing the words here too.)

Chip died of a brain tumor. He knew he was dying, months before, so he left his job and went back to his family home in Missouri to die. He died on July 9th. And I didn't know, and didn't have a chance to say goodbye, and I suspect this is because I am not on Facebook. Thus, for the first time, I am seriously considering joining Facebook.

Sometimes, in the stupor of grief, I find comfort in doing certain kinds of work -- repetitive, well-specified, medium-cognition work without much call for self-expression. So the article about Hari Kondabolu on English Wikipedia is a lot better now. I took it from 22 citations to 78, found an openly licensed photo to use, and even created the stub of a Telugu Wikipedia page. My thanks to the makers and maintainers of Citoid and the VisualEditor -- with these tools, it is a positive delight to improve articles, a far better experience than in 2011.

Hari Kondabolu turns his anger into comedy. I turn my grief into Wikipedia edits. We all paint with our pain. If we do it right and we're lucky, the stuff we make helps, even if it's just two inches' worth of help, even if it just helps ourselves.

Filed under:

: Advice on Starting And Running A New Open Source Project: Recently, a couple of programmers asked me for advice on starting and running a new open source project. So, here are some thoughts, assuming you're already a programmer, you haven't led a team before, and you know your new software project is going to be open source.

I figure there are a few different kinds of best practices in starting and running open source projects.

General management: Some of my recommendations are the same kinds of best practices that are useful anytime you're starting/running/managing any kind of project, inside or outside the software world.

For instance: know why you're starting this thing. Write down even just a one-paragraph or 100-word bulleted list description of what you are aiming at. This will reduce the chance that you'll look up one day and see that your targeted little tool has turned into a mess that's trying to be an entire operating system.

And: if you're making something that you want other people to use, then check what those other people are already using/doing, so you can make sure you suit their needs. This guards against any potential perception that you are starting a new project thoughtlessly, or just for the heck of it, or to learn a new framework. In the software world, this includes taking note of your target users' dependencies (e.g., the versions of Python/NumPy that they already have installed).

Resources I have found useful here include William Ball's book on theatrical direction A Sense of Direction, Dale Carnegie's How to Win Friends and Influence People, Fisher & Ury's Getting To Yes, Cialdini's Influence: The Science of Persuasion, and Ries & Trout's Positioning: The Battle for Your Mind.

Tech management: Some best practices are the same kinds of habits that help in managing any kind of software project, including closed-source projects as well.

For instance: more automated tests in/for your codebase are better, because they reduce regressions so you can move faster and merge others' code faster (and let others review and merge code faster), but don't sweat getting to 100%, because there's definitely a decreasing marginal utility to this stuff. Travis CI is pretty easy to set up for the common case.

I assume you're using Git. Especially if you're going to be the maintainer on a code level, learn to use Git beyond just push and pull. Clone a repo of a project you don't care about and try the more advanced commands as you make little changes to the code, so if you ruin everything you haven't actually set your own work back. Learn to branch and merge and work with remotes and cherry-pick and bisect. Read this super useful explanation of the Git model which articulates what's actually doing what -- it helps.

Good resources here include Brooks's The Mythical Man-Month, DeMarco & Lister's Peopleware, Heidi Waterhouse's "The Seven Righteous Fights", Camille Fournier's blog, and my own talk "Learn Tech Management in 45 Minutes" and my article "Software in Person". I myself earned a master's in technology management and if you are super serious about becoming a technology executive then that's a path I can give more specific thoughts on, but I'm not about to recommend that amount of coursework to someone who isn't looking to make a career out of this.

Open source management: And some best practices are the specific social, product management, architectural, and infrastructural best practices of open source projects. A few examples:

If you're the maintainer, it's key to reply to new project-related emails, queries, bug reports, and patches fast; a Mozilla analysis backs up our experience that a kind, fast, negative response is better than a long silent delay. Reply to people fast, even if it's just "I saw this, thank you, I'm busy, will get to this in a few weeks," because otherwise the uncertainty is deathly and people's enthusiasm and momentum drip away.

Make announcements somewhere public and easily findable that say something about the current state of your project, e.g., about whether it's ready to use or when to expect it to be. This could even just be someplace prominent in your README when you're just getting started. This is also a good place to mention if you're going to be at any upcoming conferences, so people can connect to you that way.

Especially when it comes to code, docs, and bug/feature/task lists, work in the open from as early as possible, preferably from the start. Treat private work as a special case (sometimes a useful one when it comes to communication with users and with new contributors, as a tidepool incubates growth that can then flow into the ocean).

I am sad, as a FLOSS zealot, to say that you should probably be on the closed-source platform that is GitHub. But yeah, the intake funnel for code and bug contributors is easier on GitHub than on any other platform; unless you are pretty sure you already know who all the people are who will use and improve this software, and they're all happy on GitLab or similar, GitHub is going to get you more and faster contributors.

You are adjacent to or embedded in other programming communities, like the programming language & frameworks you're using. Use the OSI-approved license that the projects you're adjacent to/depending on use, to make reuse easier.

It's never too early to think about governance. As Christie Koehler of Authentic Engine warns, to think about codes of conduct, you also gotta think about governance. (The Contributor Covenant is a popular starting point.) If you can be under the umbrella of a software-related nonprofit, like NumFOCUS, that'll help you make and implement these choices.

Top reading recommendation: Karl Fogel's Producing OSS is basically the bible for this category, and the online version is up-to-date with new advice from this year. If you read Producing OSS cover-to-cover you will be entirely set to start and run your project.

Additionally: Fogel also co-wrote criteria for assessing whether a project "is created and managed in a sustainably open source way". And I recommend my own blog post "How To Improve Bus Factor In Your Open Source Project", the Linux Foundation CII criteria (hat-tip to Benjamin Gilbert), "build your own rockstars" by one of the founders of the Dreamwidth project, and "dreamwidth as vindication of a few cherished theories" by that same founder (especially the section starting "our development environment and how we managed to create a process and culture that's so welcoming").

Obligatory plug: I started Changeset Consulting, which provides targeted project management and release management services for open source projects and the orgs that depend on them. In many ways I am maintainer-as-a-service. If you want to talk more about this work, please reach out!

: MidAmericon and Zambia: MidAmericon II, the 74th Worldcon (a long-standing yearly celebration of scifi and fantasy and the fandom thereof) has just released its programming schedule. I'm participating in several program items. All of the following take place August 17-21, 2016, at the Kansas City Convention Center in Kansas City, MO.

  1. Panelist, "The Interstices of Historical and Fanfiction", Wednesday Aug 17, 7pm-8pm, KCCC 2204
  2. Panelist, "The Imaginary Book Club", Thursday Aug 18, 11am-noon, KCCC 2502A
  3. Panelist, "Bad Boy Woobie", Thursday Aug 18, 1pm-2pm, KCCC 2204
  4. "Comedy Tonight!" (I'll perform about 30 minutes of stand-up comedy during this three-person showcase), Thursday Aug 18, 7pm-8:30pm, KCCC 3501B
  5. Panelist, "The New Space Opera Golden Age on the Screen", Friday Aug 19, 10am-11am, KCCC 2503B
  6. Auctioneer for Tiptree Award Auction, Friday Aug 19, noon-1pm, KCCC Flexible Activities Space
  7. Panelist, "The Art and Science of Fiction Translation", Friday Aug 19, 2pm-3pm, KCCC 3501F
  8. Panelist, "Comics Confrontational! Social Issues in Recent Comics", Saturday Aug 20, 10am-11am, KCCC 2206
  9. Panelist, "Representation in Comic Books: From Absences to Affirmatives", Saturday Aug 20, 1pm-2pm, KCCC 3501B

At this Worldcon I will finally get to meet, for the first time, Ken Liu, whom Leonard and I published in Thoughtcrime Experiments seven years ago. I predict I will meet him because he and I will both serve on that scifi translation panel, and I'll see friends Elise Matthesen and Teresa Nielsen Hayden because we're also on sessions together. Will I get to see other friends? Only future Sumana knows.

Then, in late August and early September, I'm visiting family abroad. Specifically: my sister Nandini, an extremely impressive person, works for the United Nations Capital Development Fund as a Digital Finance Country Technical Specialist. In case you haven't heard of UNCDF:

UNCDF is the UN's capital investment agency for the world's 48 least developed countries. It creates new opportunities for poor people and small businesses by increasing access to microfinance and investment capital. UNCDF focuses on Africa and the poorest countries of Asia, with a special commitment to countries emerging from conflict or crisis.

Getting this job meant that she and my brother-in-law moved to Zambia. I will make my first ever trip to Africa in order to see them! And I'll get to see Victoria Falls. If you know someone in Lusaka you think I should meet, especially anyone interested in open source software, please let me know!

: A Few Thoughts On Recent Scifi/Fantasy: Star Trek Beyond is actually a Star Trek movie rather than an arbitrary summer blockbuster wearing Starfleet paint. (I thought the MacGuffin was going to be the resonator from "Gambit" but the movie ended up being more like "The Wounded". Actual Trek episodes! Yay!)

Naomi Novik's Uprooted features a grand library of magic-related books. In this scene a young woman is seeking writings by the magician who most inspires her, a woman named Jaga, or by magicians like her, and speaks with the disapproving Father Ballo:

"Are there any other spellbooks like Jaga's here, that I might look in?" I asked, even though I knew Ballo didn't have any use for her.

"My child, this library is the heart of the scholarship of magic in Polnya," he said. "Books are not flung onto these shelves by the whim of some collector, or through the chicanery of a bookseller; they are not here because they are valuable, or painted in gold to please some noble's eye. Every volume added has been carefully reviewed by at least two wizards in the service of the crown; their virtues have been confirmed and at least three correct workings attested, and even then they must be of real power to merit a place here. I myself have spent nearly my entire life of service pruning out the lesser works, the curiosities and the amusements of earlier days; you will certainly not find anything like that here."

..... [some of the excluded works] seemed perfectly reasonable formal spellbooks to me, but evidently hadn't met Father Ballo's more rigorous standards.

Father Ballo is the fantasy equivalent of a Wikipedia deletionist. Indeed, given Novik's love of fandom and the internet, I would venture to guess that she's aware of the echo and doing it deliberately.

And a few recent short stories to recommend:

Filed under:

: A Great Explanation of WebDriver and Browser Automation: Maja Frydrychowicz's "Untangling WebDriver and the Browser Automation Landscape I Live In" is a delightful, very satisfying read. It covers the difference between the W3C WebDriver specification and Selenium WebDriver, explains their history and future, and uses the Firefox ecology as the concrete browser example so you understand how the components fit together. Also, Frydrychowicz drops in this punchline:

and some day all browsers will implement it in a perfectly compatible way and we'll all live happily ever after.

Upon reading the post, I noted:

I look into the middle distance, more motivated, yet calmer as well. I seem to hear the opening notes of "Fanfare for the Common Man" somewhere behind me. Automated browser testing seemed overwhelming previously, something to be left to Experts who knew this strange tongue. But now I know the power is in my hands; the map gleams and names that formerly confused me now fall into place. My world makes more sense; I have better comprehension of lists like PhantomJS's list of relevant test frameworks and their corresponding test runners. What might not be possible in this fresh new light?

So, if you feel faintly alienated and unmoored when trying to understand automated browser testing, check out the post.

(I know Maja Frydrychowicz because we both participated in the Recurse Center. Want to become a better programmer? Join the Recurse Center!)

: Five Loosely Connected Things:

  1. Unexpected beauty: There's a little stretch of quiet waterfront walkway with benches tucked away behind the Astoria Costco. It's just north of Rainey Park.
  2. Fierce spycrafty women: At the launch party for Genevieve Valentine's new book, Icon, I purchased it plus The Girls at the Kingfisher Club. Both recommended! Valentine engages in a recurring focus on women who fight their way out of institutional and interpersonal status traps -- using deception, self-control, fashion, and any other means at their disposal -- to achieve freedom and security for themselves and those they care about, and I consistently enjoy it.
  3. Incisive comedy: Hari Kondabolu has a new album coming out! And he and W. Kamau Bell have a new podcast!
  4. A little better every day: Beeminder continues to be a great tool to help me make better choices that will lead me towards my goals.
  5. Bees and art: The current exhibition at Socrates Sculpture Park includes a salvaged piano turned into a beehive -- and earthworks and gardens that attract pollinators. I like to imagine it would be a safe place for a woman to make bees in public (short story by Alexandra Erin). That piece of fiction is sad and funny and incisive about the necessity of being fierce and spycrafty in order to be a woman, about bees, about unexpected beauty, and about doing a chunk of work every day and witnessing what emerges. I recommend it.
Filed under:

: Ambition And Failure: People who are trying to make stuff often feel like we're failing. Ira Glass's articulation of the gap between taste and skill gets at this. He suggests making more stuff, for deadlines, for others, as a rhythm to push you to progress through that gap. But how do you keep up your morale during that push?

I'm a Recurse Center alumna, and that community often shares learning tips that are relevant to this struggle. For instance, I recommend Allison Kaptur's "Effective Learning Strategies for Programmers", which suggests reframing failure -- and reframing praise and success. Even if the tips I get via RC are programmer-centric, I can usually reuse them in other activities, such as growing my business. And earlier this year, in Ramsey Nasser's keynote The Unfortunate Value of Failure at !!Con 2016 (transcript & video), I heard a different nuance that really spoke to me. Here's the chunk of the captions/transcript that particularly resonated:

I have the same anxieties at 29 as a programmer that I did when I was a teenager. I don't feel measurably better about myself as a programmer over the last ten years, although it is objectively true that I'm a better programmer. Just looking at my GitHub repo, I can see rationally that I have actually improved, but I was trying to figure out why I didn't feel any better.

And my understanding of it... This may be different for other people, but this is my take on it. I don't think that my feeling about my skill as a programmer is actually tied to my skill at all. It's actually tied to the things that I'm trying to do, at whatever skill level I'm at. So when I was 19, I was just trying to make websites. And it was really hard. Right? And ten years later, I'm trying to write a symbolic compiler. And that's really hard. And the diff between what you're trying to do and what you're able to do is how you feel. And as I got better as a programmer, I just kept trying harder and harder things.

So the feeling is constant. Right? That's why there's no point where everything will just feel wonderful. Because I have to do this. I would have to just make basic websites for the rest of my life. And I would feel great. My anxiety would go away. I can whip up a website really, really quickly. But that's not actually what I'm excited about anymore. So my ambitions and the things that I'm excited about grow with my skill. And that's what keeps that feeling constant. That's what it's been for me. Like, right now, I'm running this whole presentation out of custom slide show software that I wrote, and I'm terrified that it's just gonna explode. Like, eat this presentation in front of everybody. And I hope it doesn't.

So if we can't eliminate it, I think we need to learn to love it. Right? We need to embrace it as part of the craft of programming. And not as this thing to be avoided. Failure... When you fail, that means you're pushing yourself. That means you're reaching beyond what you're capable of, because you want to be better. When you're failing, you're learning and you're growing. Right? You're sort of saying to yourself... Whatever you know now is great. It's wonderful. But there's more that you want. Right? It's a sense that you haven't given up on just absorbing as much as you can. When you're failing, you're exploring things that are in that grey area. That there may be interesting surprises there, or there may be things that you don't want, but you're willing... It's a sort of brave commitment to go there and to see what's out there. Failing is not wrong.

As a homeschooling parent once wrote: "The only thing that makes you smarter is doing hard things." (From the same parent: "I do think that one of the greatest educational gifts I can give her is confidence that she can seek out challenges and master them." and: "being out there on the edge of what you maybe-can't do. That's the place that you value, because that's where you stretch".)

Filed under:

: On A Fraught Word:

(This is a blog post specifically aimed at people who aren't in or from the United States and who have conversations with people from the US, especially online. Also, content note: I explain what lynching is and why it's a bad idea to joke about it, with examples.)

Sometimes when people are joking about vigilante justice, they might use the word "lynch," like "we ought to lynch so-and-so," and think it is a harmless and hyperbolic way of saying "we ought to punish them". As a person who likely (if you are reading this blog) cares about inclusivity and social justice, you probably should not use this term in this way. While some people certainly think it has that generic and benign meaning, in the US (the country whose history I know best), it mostly means white people getting together in mobs to kill black people -- for succeeding, for daring to buy houses or vote, or simply for anything deemed unacceptable by those angry racist mobs. It very rarely still happens here, but it was a more common occurrence not so long ago, such that the history and ramifications of this particular form of race-based terrorism are still very present in the American conscience.

In the summer of 1955, Emmett Till, a 14 year old black boy from Chicago, was spending the summer with family members in Mississippi, when he was suddenly accused of breaking the South's unwritten rules of interracial conduct by catcalling a white woman. He was abruptly apprehended by an angry white mob, tortured, and lynched. His mother asked for him to have an open-casket funeral, so people could see the extent of the battering and butchery, and newspapers around the country published the photos. This raised the consciousness of Americans across the nation and helped to spur the movement for civil rights in the United States.

More recently: in the 1990s, a black man (Clarence Thomas) was nominated to be a US Supreme Court justice. Anita Hill, an accomplished black female lawyer and Thomas's former employee, came forward and publicly stated that he had sexually harassed her. This accusation, and the subsequent televised judicial hearings, were a watershed moment that brought the issue of workplace sexual harassment into widespread national debate. Thomas responded to the accusations by calling them "a high-tech lynching". Hill was alternately applauded and attacked; however, the hearings ultimately proved no obstacle for Thomas, as the legislature went on to confirm his appointment. Twenty-five years later, Justice Thomas still sits on the US Supreme Court.

I know the basic facts above from memory, and those of us who were raised in the USA basically know much of this stuff by heart as part of the history of hate crimes. So that's the kind of shit that we are reminded of when someone jokes about lynching, and why you probably just shouldn't do it around us.

(Thanks to Camille Acey for suggesting revisions that improved this piece. And thanks to the white person I spoke with on this point in private conversation; I adapted that conversation into this post.)

: Pulse: I am deeply grieving the Pulse massacre.

Malinda Lo: "In the Club"

Alfred Soto: "Only When I'm Dancing Can I Feel This Free: Queer liberation, dreams, and self-discovery on the dance floor"

Sigrid Ellis: "The road to murder is paved with microaggressions"

Knit Me A Pony: "Home."

Creatrix Tiara: "urgh I've been heartsick the whole day." (MetaFilter comment) "As a queer person of Muslim background, the possibility of the Pulse nightclub shooting being used against ppl like me gives me anxiety." (Twitter thread)

Samra Habib: "Queer Muslims exist – and we are in mourning too"

: Two OSCON Conversations, And A Trip Report Between Them: Conversation the last night of OSCON, reconstructed from memory:

"So, Neil Young --"
"The singer-songwriter?"
"Man, what a white guy name."
"Are you impugning Neil Young? That man sells organic eggs at the farmer's market in my hometown!"
"Are you sure they're organic? You sure he doesn't just get them from Sysco?"
"Sysco doesn't even sell organic eggs."
"Uh, actually Sysco does sell organic eggs."
"Yeah right. I bet it's, like, orgänic, with an umlaut, so it can get around the FDA rules on calling things 'organic'."
"Yeah, and that's also how they get around the rules on Appellation Contrôlée."
"Anyway, Neil Young has a son who really likes model trains, and so he does model train stuff, and he actually has multiple patents related to model trains."
"Patents? Is he part of the Open Invention Network? Is this a defensive patent portfolio against Big Train?"
"You mean Supertrain?"

picture of Sumana in front of a steam train in Melbourne, AustraliaIn honor of late-night wackiness, I have not actually fact-checked whether Neil Young has any model train patents, or whether he or Sysco sell organic eggs. Caveat lector et caveat emptor.

My last visit to OSCON was in 2011, when I had worked for the Wikimedia Foundation for under a year, and wanted to build and strengthen relationships with the MediaWiki and PHP communities. I remember not feeling very successful, and thinking that this was a conference where executives and engineers (who in many cases are not terribly emotionally passionate about open source) meet to hire, get hired, and sell each other things.

These days, it turns out, OSCON is basically aimed at me! Because I am an executive trying to sell my services (e.g. get hired on an as-needed basis) to engineers and executives who make or depend on open source -- including the passionate ideologues, the burned-out used-to-be-passionate folks, the pragmatists, and all manner of other types. Changeset Consulting was novel, relevant, and interesting to approximately everyone I spoke with. Also, in the intervening five years, I've grown in skill, stature, reputation, and network. So I had something interesting to say, and O'Reilly accepted a talk proposal of mine for the first time. I saw scores of acquaintances, friends, peers, and colleagues in the halls and session rooms this year; I know and am known, which helps me feel at home.

I'm grateful to Audra Montenegro at O'Reilly Media for her speaker support. She worked with O'Reilly to cover my flight plus two hotel nights in Austin, making it possible for me to attend OSCON. She and other O'Reilly folks paid and worked with White Coat Captioning to provide CART (live captions) for my talk, at my request. And I was concerned that talking about inessential weirdnesses and inclusivity in open source upped my risk of harassment, so she arranged for some extra security for me. I'm also grateful to Andy Oram, my session chair, for his careful pre-conference prep (including checking on my pronouns -- she/her, thanks!), and for running a written Q&A session at my request.

I shall carry with me several memories of this OSCON, such as:

  • Breaking the no-electronics rule of the quiet room/relaxation lounge (since I was the only one using it) to finish revising my talk and blog about good code review
  • Staying with some lovely relatives in the suburbs for a few days and drinking spinach juice with them each morning (my uncle is in charge of making it, and sometimes he adds grape or orange juice, and sometimes something else, and sometimes it's just spinach. It's a surprise. "Every day's a new day," he said to me)
  • Helping my high schooler cousin revise a skit, and deploying my stand-up comedy wisdom, e.g., use over-the-top worshipful admiration as a kinder substitute for straight-up mockery
  • Being the only person in the pool at the Software Freedom Conservancy party (foolish choice on my part; it was pretty cold)
  • Meditating on a loved one during an exercise in Cate Huston's talk on technical interviewing, and feeling the lovingkindness throughout the whole room
  • Listening to an enthralling performance by rapper Sammus
  • Discussing pull request workflow, Contributor Licensing Agreements, the engagement funnel, the future of OpenHatch and of Apache Zookeeper, the failings of Google Summer of Code, whether GitHub should allow no-license repositories, how Facebook/Amazon/Google's idiosyncrasies come out in their open source work, performing femininity in the workplace, productivity and routines, effectively signalling to one's employees that they should not work on weekends, what maintainership is, JavaScript and data binding, and BLESS
  • Becoming increasingly convinced that continuous integration/continuous delivery is hitting an inflection point that source control hit several years ago, i.e., soon it will be a must-have for software-making communities and not having it will be embarrassing
  • Chatting with OSCON acquaintances in an Austin hotel lobby and being interrupted by a drunk white woman who called me "Mindy Lahiri" (a fictional character from The Mindy Project)
  • Opting out of the millimeter-wave scanner at the Austin airport and witnessing a person wearing an EFF shirt not opt out!

But here's a conversation that I particularly find stays with me. I was on the expo floor, talking with an acquaintance, and a stranger joined our conversation. I'll anonymize this recollection and call him Cyclopes.

He heard about the consulting services I offer, which focus on short-term project management and release management for open source projects and for companies that depend on them -- maintainership-as-a-service, in short.

Cyclopes: "Can you come to my company and tell us that the way we're doing deployments is all wrong, and tell them we should do it my way?"
Sumana: "Well, if your company hires me, and I assess how you're doing deployments and I think it's wrong, and I agree with the approach you want, then yes."
Cyclopes: "Great!" [explains his preferred deployment workflow, with justification, and says that it's like bashing his head against a brick wall for him to try to convince the rest of his company to do it]
Sumana: [lightheartedly] "So it sounds like what you really want is more a sockpuppet or an actor! Which might be cheaper!"
Cyclopes: "Hmmmm! You know, that is kind of what I want!"
[we three jest about this]
Sumana: "But, in all seriousness, like, you could go aboveboard with this. You know, you have options -- fraud and deception, or actually trying to persuade the other people in your org .... or, this is a wild guess, have you kind of burned bridges by being really abrasive, and now they won't listen to you?"
Cyclopes: "Yeaaaaaaaaah that might be what's happened."
Sumana: "OK! That totally happens and you weren't the first and you won't be the last."
Cyclopes: "Like, I've sent some pretty flame-y emails."
[acquaintance nods in sad agreement; we are all sinners here]
Sumana: "Oh man, the emails I've sent. I am so embarrassed when I look back. But you can come back from this. You really can. If you demonstrate to those people in your org that you really want to repair those relationships with them, they will respond. Like, if you say to them, 'I know I burned bridges before, I'm sorry about it, can we talk about this problem,' and you actually try to listen to them about what they need and what their context is, what they're worried about and what problems they're trying to solve, they will work with you, so you can figure out something that works for everybody. There's a book about this, about negotiation, that's a really short, quick read, it helped me a lot: Getting to Yes by Fisher and Ury."
Cyclopes: "Let me write this down." [notes book title and author on the back of my business card]
Sumana: "There you go, some free consulting for you. It's totally possible."
Cyclopes: "I think I could use that, I'm ripe for that kind of personal transformation in my life."
Sumana: "Great! Please, seriously, let me know how it works out."

Memory is unreliable, but I cannot forget the speed of my diagnosis, nor that this guy literally said that he was ripe for the kind of personal transformation I was prescribing. It's no model train patent but I think I'm happy anyway.

: Inessential Weirdnesses in Open Source Software (OSCON 2016): "Inessential Weirdnesses in Open Source Software": written version of a speech I delivered at the OSCON conference, Wednesday, 18 May, 2016, Austin, Texas. O'Reilly will be posting the video behind a paywall sometime in June 2016.


me smiling at cameraHi there. I'm Sumana Harihareswara and I'm going to speak with you about "inessential weirdnesses in open source software".

You can't be all things to all people. [pause]

We would be making more and better software, and empowering more people, if we got and kept more people, who have different strengths. [pause]

This is a contradiction. It is. The ways we do things right now, in open source, are really good at some things and bad at others. We are good at using some people's strengths and bad at using others. And if we want to get better at that, we need to reduce the barriers to entry, and I'm going to talk about how to do that. But we also need to watch out, so we don't accidentally get rid of the values and the habits we're really uniquely good at, the things we care about, that we should keep. There are people who really love open source culture the way it is now, who feel safe and loved and comfortable here, and that is great. We absolutely deserve to feel safe and loved. But I think there are some changes we can make so that even more people can also feel safe and loved here -- it's additive, it's not about replacement, it's saying, let's invite these people to the party too, and make sure they can have a good time once they get here. We can all work together, and complement each other's strengths.

That's the heart of what I'm going to talk about today, so you can look at your own project and think about where you want to add another interface to your community, so you can be more hospitable to new potential colleagues.


Just some housekeeping to start: I am not using any slides today; instead we have CART, Computer-Assisted Realtime Translation. A person is transcribing the words I'm saying. Stacey. Thank you, Stacey. I will be taking written questions at the end -- you can use pencil and paper, or you can tweet with the hashtag #osnewbie and I'll see it at the end of the talk. I'll be posting my notes online later today.

And there are other good talks happening right now, so to help you decide whether to stay in this room: this talk is going to be more interesting to people who already have been participants in open source software for a few years, who can use tools we commonly use in our community, like version control, IRC, mailing lists, bug trackers, and wikis, and who are already familiar with general open source software trends and arguments. And this talk is going to be most interesting to people who regularly spend time working to help reach out to new people and get them to use open source software and participate in our communities. So if that is not you then right now, check out the other talks, like "Making awesome things accessible", "I am your user. Why do you hate me?" or "Managing while Black".

"Inessential Weirdness"

OSCON 2016 So the title of this talk is "inessential weirdnesses in open source" -- and this phrase comes from the article "It's not 'them' -- it's us!" by activist Betsy Leondar-Wright. There'll be a link to this article in the notes I put online. The basic idea is, if you look at your own community with the eyes of an outsider, look at it from the perspective of a specific group of people you'd like to recruit, what do you think might discourage them or make them uncomfortable? Those are what we'll call "weirdnesses." And you get to decide, your community gets to decide, which weirdnesses are essential, and which ones, in Betsy Leondar-Wright's words, are inessential, meaning you should offer a workaround for them, or even try to change them.

Leondar-Wright suggests that there are a few classes of essential weirdnesses. There are weirdnesses that come out of our shared core values -- as she puts it, they "couldn't be eliminated without doing a deep injustice to someone". So, for us, that would include stuff like releasing our code in public. There are people who have a hard time with that. There was one coder I tried to help, because she wanted to get into open source, and she just choked, and could not start contributing to our community, because no matter how much handholding or guidance I gave, she was just too afraid to make commits in public. But that's inherent to open source. We can't make that one chunk of the codebase private so people can never see it, that would be against our values and also just logistically it wouldn't work.

Leondar-Wright also points out that some essential weirdnesses are "personal differences that may seem weird to others but are very important to the individual" (for example, choosing not to drink alcohol even though everyone around you is). I would argue that this is also a reflection of our values. We respect people's choice to abstain from alcohol because we value personal autonomy and bodily consent.

But "it's rarely essential to impose one's personal choices on others".

I've run into trouble using this term, because the word "inessential", to some people, implies that something has no value, or that it's harmful and we should get rid of it. No. It's more like a heads-up, that here's a place where you could build out some new API client libraries, in more languages, have more interfaces, so more people can interoperate with you.

I'm going to quote an anecdote from Betsy Leondar-Wright's article:

A few years ago, I listened to week-by-week reports from a radical working-class friend who tried to join a [group fighting corporate globalization]. He told me of snide comments about his fast food; elaborate group process that took hours and hours; insistence that everyone "perform" by answering a certain question at the beginning of the meeting; uniformly scruffy clothes that made his pressed shirts stand out; potlucks that were all tofu and whole grains; long ideological debates over side issues; and an impenetrable fog of acronyms and jargon. He soon quit in disgust. I wonder if the group members understood why he left.

For professional-middle-class progressive activists like myself, it's easy to understand why working-class people would be alienated by the mainstream culture of well-off people. After all, we tend to be alienated by it ourselves, because it represents values we've rejected, like greed and materialism. But the idea that working-class people would have any negative reactions to our own subculture, in particular our values-based 'alternative' norms, tends not to occur to us.

I read that and I thought about times I've seen new people in open source having a bad time, because of something that has nothing to do with our core values, nothing to do with transparency and freedom and helping your neighbor. But because someone was mean to them because they use Windows, or they feel pretty alone and isolated because of our communication norms, or they had a tough time getting started with Git, because it's really hard to get started with Git.

And am I saying "let's get rid of Git"? No! I'm saying, if someone wants to get started in open source, maybe Git isn't the very first thing I want to teach them. Maybe I accept that right now they're on Windows. You gotta meet people where they're at.

That progressive activist group that Betsy Leondar-Wright's friend tried to join -- it sounds like they were basically a working group full of experts who had process and jargon and habits that worked well for them. And we have specialized process and jargon and habits that work well for us, when it's all experts together. I think one of the hardest things to do is for experts to look at a culture that's working for us and figure out what scaffolding we can offer so new people can come in and become experts too. Researchers Stuart and Hubert Dreyfus actually talked about this problem in 1980, in their Dreyfus Model of Skill Acquisition -- when you go from novice to expert, you don't just learn a bunch of new facts. The way you look at the world changes, you're making decisions on a new analytical level, you have a whole new perspective. And it's really hard for you to empathize with people who don't have this skill, who haven't learned the judgment and the reflexes that you have. [See Mel Chua's talk slides on education psychology for more on this.] This is one reason writing documentation is so hard. [Here, despite the bright lights, I saw one audience member nod, and that made me happy.]

So today I'll be talking about some few examples, bits of our subculture, the open source software subculture, that routinely alienate new people. And I'll give my thoughts on how to discern the bits that are important, that we shouldn't ever give up because they're key to our values, from stuff where we can offer workarounds when we're doing outreach events and creating online spaces for newcomers -- those are the bits that Betsy Leondar-Wright calls "inessential weirdnesses". Then I'll explain how you can better recognize and fix these kinds of snags in your own outreach work. My hope is that after today's talk you'll be more effective and you'll help make outreach experiences more hospitable and thus more effective.

[Now: three stories.]


My first story today is Aurynn Shaw's story about realizing that hating on Windows and PHP has real costs. She writes in "Contempt Culture":

...when I started programming in 2001, it was du jour in the communities I participated in to be highly critical of other languages. Other languages sucked, the people using them were losers or stupid, if they would just use a real language, such as the one we used, everything would just be better.


This sort of culturally-encoded language was really prevalent around condemning PHP and Java. Developers in these languages were actively referred to as less competent than developers in the other, more blessed languages.

I do recommend that you read Shaw's essay. She goes into some really worthwhile insights on what this dynamic achieves for the people who participate in it, and whom it excludes.

She writes:

It's 2015, and I saw a presenter at a Python conference make fun of Java. How would that feel to people trying to move from Java into something else? I wouldn't feel welcome, and I'd have learned that the idea that the Python community is welcoming wasn't true.

I'm tired of calling people out again and again for dumping on PHP.

I'm tired of people dumping on Windows, that most popular operating system, because it's not what we choose to use, tired of the fact that we don't make it easy to use our tools and teach them how to move, when they're ready.

As I experienced in most of my community management work in open source software, over and over, I saw how few of our tools and applications make it easy for Windows users to try out open source software. On Windows, installing, for instance, an open source application that depends on Ruby is a big hassle, and might mess up other stuff you're doing that depends on Ruby.

So what is essential here and what is inessential?

Do you yourself have to go get a Windows machine and start writing PHP? No. Of course not. Remember, personal autonomy and choice is essential!

It's essential that we encourage people to move off of proprietary systems, giving them support in the short term with training and help, and in the long term with kick-ass operating systems and applications, and a culture and a political environment that encourages open source software. It's inessential to make people feel bad that they haven't done a really hard transition yet. Activists have known for a long time that if you ask a new potential ally to change their entire life and lifestyle at once, you don't get as many new followers as if you get more doable, with short-term goals that give them immediate benefits.


Here's my next example, and it's about language. Now, if you were teaching someone a skill they didn't know before, like woodworking or omelet-making or choral singing, it would make sense for you to teach it in the language they already speak. If they only speak English, teach it to them in English.

Well, every day, we do the opposite of that. We tell people that they have to learn a new language along with the new topic. The topic, the skill, is using open source software, and the language is the command line.

Gus Andrews, who's a usability expert and a Fellow at Simply Secure, has a provocatively titled blog post, "Why the command line is not usable". She discusses how the command line is an environment that requires tremendous cognitive load of new users. She reminds us that recognition is far easier than recall.

Command lines demand that users remember the correct phrase to make the system run, rather than giving them prompts which might help them guess what the system needs them to do next. The overwhelming majority of people alive today have never had the opportunity to learn those commands. Making them look them up and learn them themselves would make them very, very frustrated -- they don't have time for that. GUIs aren't just "shiny": they are tools which help us remember what is possible.

Some users absolutely find the command line a lot more usable and accessible! And I don't discount their experience! But over and over we see that a lot of new users find it really frustrating to get started on the command line.

And this is not just about uneducated users, or users who don't spend that much time with computers. As an example, computer science professor Philip Guo has an essay on his site called "Command Line Bullshittery" where he talks about all the little commands his research students, CS researchers, have to learn in order to get their research done. Stuff like

nohup tar -jxvf giant.tar.bz2 2> cmd.errs &

And he says that as an advisor, one of the things he has to do to keep his students from getting super demoralized is to teach them how to install and configure and use open source software on the command line, which is a really deeply unfriendly experience, and to reassure them that it's "just a necessary upfront tax required to enable them to do the actual interesting research".

And in that piece he distinguishes between incidental and intrinsic complexity.

The fact that it's hard to learn the command line "arises simply because modern research software development is a messy jumble of open-source tools tied together by the duct tape of command-line scripts." It's incidental complexity. It has nothing to do with the intrinsic complexity of CS research, the hard problems that these researchers are trying to investigate.

This underscores that it is just hard to install open source software, often, and get it to a state where it's properly configured and secured, and you can do work with it and import and export data. Recently Bret Davidson and Jason Casden wrote a piece in the code4lib journal, "Beyond Open Source: Evaluating the Community Availability of Software". Their suggestion was: What if you just took a stopwatch and saw how long it took a representative user to install software and do something useful with it? I think for a lot of us, we are aware that this number, for our projects, would be dismally high.

Similarly, when I was at the Wikimedia Foundation, we started the Visual Editor project, which makes it easier to edit Wikipedia articles. Before we started this, we often saw that skilled writers with useful content to contribute would get discouraged, because they knew English, they were web-savvy, they sometimes even knew HTML, but they didn't know this wacky weird markup language, wiki syntax, that no one else in the world used. In fact, sometimes this made them think that they were not allowed to edit -- people would click the Edit link, see this jumble of what looked like source code, and then Back-button right on out of there, for fear that they'd broken something, or that they were about to break something.

And what's worse, when we started introducing the what-you-see-is-what-you-get editor, the Visual Editor, some of the experienced editors pushed back with the argument that the syntax was a gatekeeping measure, that the ability to master this syntax was a really good proxy for whether someone was going to be a good writer and contributor in general. This is pretty nonsensical and has not been borne out as far as I can tell.

So, what is essential here? what is not?

With wikis, it's essential that everyone can edit an article -- that is part of the freedom of free culture. MediaWiki is meant to make it easy to edit. By default, when you set up a new MediaWiki installation, every user can edit every article. We aren't going to add a bunch of different permission and access control layers so that there are fifteen layers of privileges to determine who can edit what page. There's other wiki engines that'll do that, that have different core values, but it's inherent to MediaWiki that we default to freedom.

And that everyone can see every article's history, because that transparency makes everyone a more informed consumer. And there's more, I'm sure. But using the syntax is inessential. It's incidental complexity.

And I would argue that the most essential aspect of the command line is that people are empowered to control their machines and use them the way they want. It's a tool. And it's important that all users have the command line on GNU/Linux available, so they can chain together operations and learn to do development work, if they want, and because there are people who find it a much more accessible experience. But the command line is such a difficult, alienating experience to new users, it's like it gives them unusable freedom. (Hashtag #unusablefreedom .) So, making new users learn the command line in order to use open source software is an inessential weirdness. Having alternatives available, like the rich desktop environments that GNOME and KDE have made and Ubuntu helped make available, is great. As long as all the GUIs are also accessible to screenreaders.

REMINDER: I will be taking written questions at the end -- you can use pencil and paper, or you can tweet with the hashtag #osnewbie and I'll see it at the end of the talk.


Now another story, and it's actually about a rare failure by one of my favorite conferences. PyCon North America is a yearly community conference about Python. In scheduling PyCon 2014 and 2015, the organizers accidentally scheduled it over Passover, both times. And this means that a nontrivial number of observant Jews couldn't come.

And beyond that, consider how many of our conferences happen over Fridays, Saturdays, and Sundays. If going to a weekly Muslim, Jewish, or Christian religious service is important to somebody, then a weekend conference schedule is going to really crimp their style.

(Now, this is important to balance against the fact that some people can't miss that much work in order to attend a conference. Maybe the best approach is to be aware of who seems to be consistently catered to, what demographics aren't having any trouble showing up, and try to change it up a bit so you have some events, some communication channels, and so on that cater to the people you haven't had as much success in reaching. You can see an example of how I'm doing that in this talk -- I'm using written questions instead of oral Q&A, because it's a way to make some people comfortable who usually don't get to ask questions. And instead of using slides, I suggested we have the live captions, to help people who usually have trouble following a spoken talk.)

I'm not here to try to persuade anyone to join or leave any religion -- I'm a Hindu myself and I'm really grateful that we do not do that here, that in my nearly 20 years in the free software movement no one has tried to convert me. I'm glad our spaces are secular. That is essential to us being open for everyone. But in our aggressive ignorance of religion, and sometimes when we stand by and let anti-religion comments stand without challenging them, we sometimes cause snags for people who want to engage with us.

Sometimes this is in missing opportunities, like partnering with churches, temples, and mosques. Hey, they have communities full of people with free time who are interested in making the world a better place! A lot of them care about privacy from government surveillance, for very good reason! And they have free venues for meetings!

But, again, it's essential to respect people's personal autonomy and freedom. There are people in our communities who have been hurt by religion, been traumatized by religion, who currently face discrimination from religious communities. So of course we have to be mindful of that. So, for instance, if someone in your community isn't going to feel comfortable in a religious space then there's no reason to try to persuade them to do that bit of outreach.

In any case, I'd say that it's an inessential weirdness for us to stand by and allow anti-religious comments in our public spaces. One person who ran an online technical forum mentioned that, in its "off-topic" section, sometimes people said things that were casually sexist or Islamophobic. He said,

"I just kind of rolled my eyes and ignored them. About three years in to running the forum, I incidentally discovered that we had a few closeted women and Muslims in our membership. Suddenly those jokes that were white noise before made me acutely ashamed and I had to update the rules and enforcement to stop those posts going forward. If you had asked me the year before what I thought the community's most serious issues were in expanding and increasing engagement, a 'casual hostility to certain demographics' wasn't even on my radar." -- Matt, Crooked Timber comment thread

More things I wish I could have talked about

I wanted to go into these in depth, so there are topics I mentioned in my abstract that I do think contain inessential weirdnesses but that I don't have time to discuss in depth in this time slot, like open source communication norms, and how our community acts regarding pop music, patriotism, small talk, professional sports, and the primacy of in-person conferences, and the user interface of Git specifically, and assumptions about bandwidth & personal computer quality. I'm happy to discuss any of those during the Q&A or afterwards. This is an incomplete list of examples.

REMINDER: I will be taking written questions at the end -- you can use pencil and paper, or you can tweet with the hashtag #osnewbie and I'll see it at the end of the talk.


me in conversation in speaker's lounge - photo by O'Reilly MediaSo what does this imply for open source software advocates? Now I'm going to talk about some ways to watch out for these problems and reduce the harm they cause.

1. Look for code smells

These are some really rough heuristics to try to find snags that other people are hitting.

Take the same approach that a Software Reliability Engineer would take, and say, any time a user gets hassled or tripped up, that's a symptom of a problem that needs fixing. You treat every downtime, every pager call, as a bug report.

Look out for any advice your project is giving newcomers that has the word "just" in it. I think Greg Wilson calls this the passive-dismissive adverb.

Watch out for any place in your workflow where newcomers have to deal with simultaneous newness on multiple dimensions. Mako Hill has observed that Wikipedia was founded at the same time as a lot of other innovative free knowledge projects, but Wikipedia's the one that thrived and that's still around, because yeah, it was super weird and disorienting and innovative on the workflow level, but the thing it was aiming at, an encyclopedia, that was a vision all the participants understood. ["Almost Wikipedia: What eight early online collaborative encyclopedia projects reveal about the mechanisms of collective action."] You can only innovate on so many levels at the same time. This goes back to that woodworking example at the beginning. People will have a hard time learning a new language while they're also learning to do an entirely new kind of thing.

If you make an application you want people to use, use the Simply Secure guides on doing qualitative UX (user experience) research, such as seeing how users are using your product/application.

And another possibility -- I know this is a wacky idea -- but you can ask. You can reach out to individual people who attended one event and drifted away, and ask them what you could fix to be less unappealing. That doesn't always scale, it's artisanal data, but still, it'll give you some thoughts to work off of.

And having those thoughts, a list of some things to look at, helps with the next step.

2. Realistically assess yourself & your goals

Once you have an inventory of some things about your community that are putting off newcomers, you have some choices to make. What are you really committed to keeping in absolutely all your activities, and what do you think you could stand to tone down when you're trying to talk to newbies?

Discerning essential from inessential means being honest about what your real values are.

So, what are your goals? What are your values? You care about the Four Freedoms and about treating everyone with respect; beyond that, what are you particularly attached to? Who are you trying to reach out to, & what are the gaps between your culture & theirs? I haven't even gone into international, inter-language, and other differences you might want to traverse, but I can recommend to get some representative thoughts.

"Observe the cultural norms of people you'd like to work with, watch for signs of discomfort, and study what conveys respect and disrespect in their subculture." -- Leondar-Wright

This isn't about completely changing the entire core of your work. If you have a strong cultural practice and you're committed to it, own it but be nonjudgmental -- say "if you want [other approach] consider [other project]".

Acknowledge that different people want different things. And acknowledge that when you negotiate that with people who are different from you, that will probably require conversations, not just writing FAQs that live forever. [See this explanation of the success of the English Wikipedia's "Teahouse" for more on this.]

3. Find easy ways to build bridges

Sometimes you're going to find easy wins, which is great! There are easy add-ons you can do that overcome a barrier.

Some old-school people like Mailman mailing lists. Some new contributors really like web forums. If you upgrade to Mailman 3, you get one thing that acts like both, so everyone's happy!

If you have an IRC channel, you can do what OpenHatch did and have an automated welcome bot. It greets new people and gives them a couple tips, including the names of a few people they could reach out to for help who have been active recently. If you have a Slack, you can make a bot with the botkit framework to do something similar.

You can use pre-existing playbooks to run events like SpinachCon, so that new folks don't have to learn git or the command line to make their first contribution.

But usually those kinds of easy wins are not the whole story. If you are serious about building coalitions with people who are not like you, you will probably want to:

4. Build and maintain differentiated but connected spaces

Your project can support both experts-only spaces (where jargon and in-group practices are welcome, like really concise speech and Douglas Adams jokes) and mixed-experience spaces (where hospitality is emphasized and legitimate peripheral participation opportunities are available for learning). [Also see Mark Guzdial's and Greg Wilson's posts on this.]

These newcomer-friendly spaces are like tidepools, connected to the ocean, but calmer, where things can germinate in a gentler environment. For you, a tidepool might be a community that publicizes beginner-friendly events, where Windows users who prefer GUIs to command lines are welcome, where new people can make relationships through small talk, where there's an occasional installfest at a church.

This means that you would have to learn to be comfortable explaining, nonjudgmentally, that there are high-jargon spaces and low-jargon spaces, and helping steer conversations to where they ought to be.

These newcomer-friendly events and online spaces probably ought to have agreed-upon rules. Example: the Recurse Center rules (manual) to help everyone feel comfortable saying "I don't understand." And it's probably a good idea to regularly revisit and revise those rules to see if they've lost touch with any of the essential values and weirdnesses that the community needs to preserve.

And this isn't meant to suggest that we should condescend to newer contributors -- just listen to them, and do what it takes to support and encourage them in their open source software journey. Everybody's got something to learn from us and everybody's got something to teach us. So while teaching new learners, yeah, we should err on the side of clarity and listening, and call things by their proper names while also collaborating among people with different perspectives to build a common language -- and a common movement.

5. Acknowledge the costs

"Don't expect you can remain exactly as you are and be a bridge person" -- Leondar-Wright

Engineering is a game of tradeoffs. And yeah, there's a tradeoff here. You are going to reduce the amount of time that the outreach-centric folks spend in the pre-existing expert communities. Let's acknowledge that different spaces are genuinely, irreconcilably different.

Whenever you try out a kind of funnel or ladder that you hope will get you new users, new participants, new collaborators, not all of those people are going to work out. And every one of them who drops out is going to feel like a failure of the new plan. Like, "we spent all this time on making a GUI and negotiating with the local mosque to host a meetup and actually making smalltalk with people, and it's still a grind!" You're going to have demoralizing moments and it's going to feel even harder because you're trying something new that you're not good at yet. Which is where the learning happens.

Leondar-Wright says: "Figure out which of your weirdnesses are essential to you, and drop the inessential ones when you're doing cross-class outreach or coalition building. Be thoughtful about who your group sends to be the emissary to a culturally different group." So, that means that some of the people in your community who are not very good at adapting to other people's cultures should not be doing this work. And if they're trying to do this work and they're not good at it, they need to hear that, and that's a hard conversation to have.

Another cost is the cost of the weirdnesses you decide to keep.

If you decide to hold onto a weirdness, then acknowledge that in your outreach, you'll need to pay the cost of making new people comfortable with it. Develop good explanations and metaphors and help people understand why you've made the choices you've made.

Figure out what needs teaching in a standalone class. For instance: the nonprofit Software Carpentry teaches researchers and scientists of all kinds -- physicists, biologists, sociologists, anybody who has to manage and sort through data to do research -- they teach them basic research computing skills, like version control, the Unix command line, and better programming skills. And the Software Carpentry folks have created these workshops and boot camps, sort of as a coping mechanism for the weirdnesses of Git and the command line.

As a community, it looks like we are sort of doing this with Git by creating learning materials, and by making some workarounds. Look at the GitHub web UI as sort of a costly, unfree mitigation of the horribleness of Git's command-line UI. As with wikis: it's essential, with Git, that everyone can suggest improvements, everyone has access to the whole history, it's possible to search for specific changes or classes of changes. But learning to use the command line and the syntax is just not as essential as a first step.


So here's the tiny plug, which is that, through my firm, Changeset Consulting, I can help you with this -- with contributor outreach and with auditing and assessing and improving your current intake and onboarding process. But no matter whether you hire somebody or ask for volunteer help or do all this work yourself, this is going to be tough, but necessary work, for us to build a mass movement.

As Betsy Leondar-Wright says:

None of this is easy. It's one thing to briefly change ourselves for a job interview or for dinner with the in-laws, but it's painful to have to change ourselves in our own activist groups. But as civil rights activist and Sweet Honey in the Rock founder Bernice Johnson Reagan said about coalitions, "If you're comfortable, you ain't doing no coalescing."

I am asking you to stay safe and loved but to try installing discomfort. Everyone deserves safety. Safety is what makes it possible for us to function. But maybe we could take turns being uncomfortable, so the same people don't always have to be uncomfortable all the time. If you are recruiting for new Google Summer of Code interns, or you're on a newbies-friendly mailing list, and you see a barrier to entry, check whether you're acting like those old-school Wikipedians who thought the Visual Editor was keeping out the riffraff. Ask yourself: "Is this essential to our values, or is it more like adding another way in would make us uncomfortable?"

Just give it a spin. As the Open Source and Feelings Diversity Statement says:

"Sometimes we will need to step out of our comfort zones to make everyone feel welcome. We recognize that privilege is real and that the privileged have more bandwidth to be uncomfortable and help make our space more welcoming."

Thanks to Amy Hanlon, Anne DeCusatis, Leonard Richardson, Denver Gingerich, Betsy Leondar-Wright, Naomi Barrettara, Darius Kazemi, Brendan Adkins, Nick Murphy, Roan Kattouw, Meredith Patterson, Andromeda Yelton, and Kaitlin Thaney for their comments on drafts of this talk, and thank you to Mary Gardiner and Camille Acey for earlier comments on this topic.

Question & Answer

And I'm now ready to answer your written questions. [I received one question.]

Q: Does jargon exist for matters that cannot be understood with preexisting vocabulary?
A: I think the word there is jargon. I think that it's useful to remember that there are -- jargon isn't just about synonyms. It isn't just, you know, we say "quit" or "exit" where somebody else says "end." Jargon isn't just about different words for the same thing. Often one function of jargon is an encapsulated compressed thought that does have dependencies. You can think of trying to reach newbies as a dependency management exercise. How many new concepts and skills are you making them install in order to get to the point where they can do something useful and collaborate with you? And so, I could, you know, if you want some metaphors, I think that's a reasonable one to talk to other coders with. The chunk of thought that this questioner asks about, ideas that cannot be easily expressed or understood with the person's preexisting vocabulary until they learn new words and thoughts, I think "jargon" is a reasonable thing to start there.

Additional note: Thank you to White Coat Captioning for working with O'Reilly Media to provide CART services for this session. I've checked the transcript they provided and improved this post to reflect the question-and-answer session, as well as places where I said something better live than I had scripted for myself to say, and I've included in this post parts of the speech that I did not have time to deliver during my OSCON slot.

This talk is a revision of an earlier talk I delivered at LibrePlanet 2016; in particular, I cut the "small talk" section due to ableism concerns, and may someday expand that chunk of thought into another talk or essay.

about Sumana Harihareswara


RSS feed
LiveJournal feed
Spam As Folk Art microblog
Twitter feed

weblog powered by NewsBruiser
Bloggers' Rights at EFFSupport Bloggers' Rights

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.