Cogito, Ergo Sumana

picture of Sumana's head

Sumana Harihareswara's journal


(0) : Penguicon, Orwell, ETAOINSHRDLU, and Being Important: When I was eight or nine years old, I think my parents went through a chunk of "how do we support this weird kid?" planning and work. Around this time I remember coming across a book my parents had acquired, something like How To Deal With Your Gifted Child, the kind of book that has 70 pages of large-print line art-illustrated stories to read to your kid and discuss with them, followed by 40 pages of smaller-print nonfiction prose meant just for the adults. I read the whole thing, of course. Pretty hard to prevent a kid who loves reading from reading the whole book and finding use and joy where she can.

Another one of the paperbacks that made its way into our house around this time was about word puzzles, trivia about English, neologisms, and so on -- it had something to do with Mensa, I think. This is how I learned that the twelve most common letters in the English language are, in order, ETAOINSHRDLU.

Also I remember being given a collection of modern British short fiction and essays, for use in a supplemental tutorial or something -- this is how I read my first George Orwell, his essay "Shooting an Elephant", and my first D.H. Lawrence, his short story "The Rocking-Horse Winner", and my first taste of how truly dark Roald Dahl could get, "The Great Automatic Grammatisator".

The advice on dealing with myself, as a gifted child, helped some -- I got it into my head that an aversion to doing things that I wasn't already good at would be harmful, for instance, even if I couldn't prevent acquiring a bit of it anyway. Everyone who comes out of childhood has scorch and stretch marks. I'm glad I got an early start on Dahl, Lawrence, and Orwell, warning me about technology's effect on art, obsession's effect on childhood, and imperalism's effect on the oppressor, respectively. And though ETAOINSHRDLU caused me to regard "Wheel of Fortune" the way many programmers feel about Sudoku -- that it presents problems to humans that properly ought to be solved by computers -- and thus be a bit of a funless jerk for a while about a TV show that provides pleasure to many people, it's has proven useful in countless games of Hangman, and in an inadvertent audience participation moment during a play I saw in Manchester in 2014.

There's a bit in Sherlock Holmes: A Working Hypothesis where a lecturer, solving a Hangman-style puzzle and mocking the audience for our wrong answers, says something about the likelihood of the next letter. I blurted out something like "E, then T, then A, because the twelve most common letters in the corpus of English-language writing, in order, are ETAOINSHRDLU". The speaker teased me occasionally for the rest of the act, and I later learned that several other audience members inferred that I must be a castmember, a plant.

More and more frequently I find that other people in my communities treat me as though I must be one of the cast, not one of the audience. As though I am important. One way of looking at impostor syndrome is that it looks at two people with the same characteristics and pasts and treats one as less important, always the audience and never the cast, solely because it's the self. The How to Deal book had stories about kids who got swelled heads, and stories about kids who never believed they were good enough. "Shooting an Elephant" said: once you're in the cast, you have to follow the script or there'll be hell to pay. And ETAOINSHRDLU has long represented to me the power of double-checking whether something really is random, and finding patterns, and sharing them with others, empowering us. Which can break a kind of fourth wall between watching and acting.

In a little over a week, I'm a guest of honor at Penguicon, and one of my sessions will be a reprise of my LibrePlanet 2017 keynote, "Lessons, Myths, and Lenses: What I Wish I'd Known in 1998" (description, video, in-progress transcript). I'll give the audience a menu of topics and they'll select the ones I talk about, and the order. It'll be massively different from the LibrePlanet version because the audience will choose different topics or a different order, barring deliberate collusion. One reason I'm doing my Guest Of Honor talk this way is because there is too much to say, and this way each story or insight has a fighting chance to get said. But another is that I have given written-in-advance keynote speeches enough times before that it's in danger of becoming a habit, a local maximum. And -- perhaps this does not speak well of me -- I think this particular audience participation method also provides a release valve for the pressure of being the Important one in the room. Instead of performing as a cast of one, I turn everyone into a plant.

To close out, my favorite chunk of Orwell, the ending of "Some Thoughts on the Common Toad":

At any rate, spring is here, even in London N.1, and they can't stop you enjoying it. This is a satisfying reflection. How many a time have I stood watching the toads mating, or a pair of hares having a boxing match in the young corn, and thought of all the important persons who would stop me enjoying this if they could. But luckily they can't. So long as you are not actually ill, hungry, frightened or immured in a prison or a holiday camp, Spring is still Spring. The atom bombs are piling up in the factories, the police are prowling through the cities, the lies are streaming from the loudspeakers, but the earth is still going round the sun, and neither the dictators nor the bureaucrats, deeply as they disapprove of the process, are able to prevent it.


(2) : Alternate Questions: Is it still in vogue for US tech companies to ask quantitative estimation/implausible-problem questions like "how many phone booths/piano tuners are there in Manhattan?" in hiring interviews, particularly for programming-related jobs? Fog Creek asked me one of those in 2005. There was even a book, How Would You Move Mount Fuji?: Microsoft's Cult of the Puzzle -- How the World's Smartest Companies Select the Most Creative Thinkers.* How many companies are still into that?**

I ask because I came up with a couple you could use, maybe for a digital humanities kind of position:

  1. How many people, throughout history, have actually been named "Flee-From-Sin"? I feel like you see this as a jokey Puritan first name in books like Good Omens or the Baroque Cycle, but was it a name that some non-negligible number of people actually had?
  2. Out of all the people currently within New York City limits, have more of them written a sonnet or a dating profile? What's the ratio?

* That's right, two subtitles. That's how you know you're getting a lot for your $16.00 MSRP.

** It's hard to tell these things sometimes even if you listen to lots of people discuss hiring and recruiting. "Five Worlds" and its decade-later ramifications apply to work culture, not just software development methodology. Stripe's engineering interview aims to "simulate the engineering work you'd do day-to-day" (link via Julia Evans) so I think you can expect your interviewer won't show up wearing a question-mark costume and screeching, "Riddle me this, Batman!" This software engineer, who's just been through scads of hiring interviews, doesn't mention puzzle questions. This level of detail ain't exactly on the "How to Become a Computer Programmer" page in the Occupational Outlook Handbook from the US Department of Labor -- but then again we already knew that the assessment vacuum in software engineering skills is a huge problem.

Filed under:


(1) : Inclusive-Or: Hospitality in Bug Tracking:

Lindsey Kuper asked:

I’m interested in hearing about [open source software] projects that have successfully adopted an "only insiders use the issue tracker" approach. For instance, a project might have a mailing list where users discuss bugs in an unstructured way, and project insiders distill those discussions into bug reports to be entered into the issue tracker. Where does this approach succeed, and where does it fail? How can projects that operate this way effectively communicate their expectations to non-insider users, especially those users who might be more accustomed to using issue trackers directly?
More recently, Jillian C. York wrote:

...sick of "just file a bug with us through github!" You realize that's offputting to your average users, right?

If you want actual, average users to submit bugs, you know what you have to do: You have to use email. Sorry, but it's true.

Oh, and that goes especially for high-risk users. Give them easy ways to talk to you. You know who you are, devs.

Both Kuper and York get at: How do we open source maintainers get the bug reports we need, in a way that works for us and for our users?

My short answer is that open source projects should have centralized bug trackers that are as easy as possible to work in as an expert user, and that they should find automated ways to accept bug reports from less structured and less expert sources. I'll discuss some examples and then some general principles.

Dreamwidth logo Dreamwidth: Dreamwidth takes support questions via a customer support interface. The volunteers and paid staff answering those questions sometimes find that a support request reveals a bug, and then file it in GitHub on the customer's behalf, then tell her when it's fixed. (Each support request has a private section that only Support can see, which makes it easier to track the connection between Support requests and GitHub issues, and Support regulars tend to have enough ambient awareness of both Support and GitHub traffic to speak up when relevant issues crop up or get closed.) Dreamwidth users and developers who are comfortable using the GitHub issue tracker are welcomed if they want to file bugs there directly instead.

Dreamwidth also has a non-GitHub interface for feature suggestions: the suggestions form is the preferred interface for people to suggest new features for Dreamwidth. Users post their suggestions into a queue and a maintainer chooses whether to turn that suggestion into a post for open discussion in the dw-suggestions community, or whether to bounce it straight into GitHub (e.g., for an uncontroversial request to whitelist a new site for media embedding or add a new site for easy cross-site user linking, or at the maintainer's prerogative). Once a maintainer has turned a suggestion into a post, other users use an interface familiar to them (Dreamwidth itself) to discuss whether they want the feature. Then, if they and the maintainer come to consensus and approve it, the maintainer adds a ticket for it to GitHub. That moderation step has been a bottleneck in the past, and the process of moving a suggestion into GitHub also hasn't yet been automated.

Since discussion about site changes needs to include users who aren't developers, Dreamwidth maintainers prefer that people use the suggestions form; experienced developers sometimes start conversations in GitHub, but the norm (at least the official norm) is to use dw-suggestions; I think the occasional GitHub comment suffices for redirecting these discussions.

Zulip logo Zulip: We use GitHub issues. The Zulip installations hosted by Kandra Labs (the for-profit company that stewards the open source project) also have a "Send feedback" button in one of the upper corners of the Zulip web user interface. Clicking this opens a private message conversation with feedback-at-zulip.com, which users used more heavily when the product was younger. (We also used to have a nice setup where we could actually send you replies in-Zulip, and may bring that back in the future.)

I often see Tim Abbott and other maintainers noticing problems that new users/customers are having and, while helping them (via the zulip-devel mailing list, via the Zuliping-about-Zulip chat at chat.zulip.org, or in person), opening GitHub issues about the issue, as the next step towards a long-term fix. But -- as with the Dreamwidth example -- it is also fine for people who are used to filing bug reports or feature requests directly to go ahead and file them in GitHub. And if Tim et alia know that the person they're helping has that skill and probably has the time to write up a quick issue, then the maintainers will likely say, "hey would you mind filing that in GitHub?"

We sometimes hold live office hours at chat.zulip.org. At yesterday's office hour, Tim set up a discussion topic named "warts" and said,

I think another good topic is to just have folks list the things that feel like they're some of our uglier/messier parts of the UI that should be getting attention. We can use this topic to collect them :).

Several people spoke up about little irritations, and we ended up filing and fixing multiple issues. One of Zulip's lead developers, Steve Howell, reflected: "As many bug reports as we get normally, asking for 'warts' seems to empower customers to report stuff that might not be considered bugs, or just empower them to speak up more." I'd also point out that some people feel more comfortable responding to an invitation in a synchronous conversation than initiating an asynchronous one -- plus, there's the power of personal invitation to consider.

As user uptake goes up, I hope we'll also have more of a presence on Twitter, IRC, and Stack Overflow in order to engage people who are asking questions there and help them there, and get proto-bug reports from those platforms to transform into GitHub issues. We already use our Twitter integration to help -- if someone mentions Zulip in a public Tweet, a bot tells us about it in our developers' livechat, so we can log into our Twitter account and reply to them.

MediaWiki logo 1MediaWiki and Wikimedia: Wikipedia editors and other contributors have a lot of places they communicate about the sites themselves, such as the technical-issues subforum of English Wikipedia's "Village Pump", and similar community-conversation pages within other Wikipedias, Wikivoyages, etc. Under my leadership, the team within Wikimedia Foundation's engineering department that liaised with the larger Wikimedia community grew more systematic about working with those Wikimedia spaces where users were saying things that were proto-bug reports. We got more systematic about listening for those complaints, filing them as bugs in the public bug tracker, and keeping in touch with those reporters as bugs progressed -- and building a kind of ambassador community to further that kind of information dissemination. (I don't know how well that worked out; I think we built a better social infrastructure for people who were already doing that kind of volunteer work ad hoc, but I don't know whether we succeeded in recruiting more people to do it, and I haven't kept a close eye on how that's gone in the years since I left.)

We also worked to make it easy for people to report bugs into the main bug tracker. The Bugzilla installation we had for most of the time that I was at Wikimedia had two bug reporting forms: a "simple" submission form that we pointed most people to, with far fewer fields, and an "advanced" form that Wikimedia-experienced developers used. They've moved to Phabricator now, and I don't know whether they've replicated that kind of two-lane approach.

A closed-source example: FogBugz. When I was at Fog Creek Software doing sales and customer support, we used FogBugz as our internal bug tracker (to manage TODOs for our products,* and as our customer relationship manager). Emails into the relevant email addresses landed in FogBugz, so it was easy for me to reply directly to help requests that I could fix myself, and easy for me to note "this customer support request demonstrates a bug we need to fix" and turn it into a bug report, or open a related issue for that bug report. If I recall correctly, I could even set the visibility of the issue so the customer could see it and its progress (unusual, since almost all our issue-tracking was private and visible only within the company).

Debian logo An interface example: Debian. Debian lets you report bugs via email and via the command-line reportbug program. As the "how to use BTS" guide says,

some spam messages managed to send mails to -done addresses. Those are usually easily caught, and given that everything can get reverted easily it's not that troublesome. The package maintainers usually notice those and react to them, as do the BTS admins regularly.

The BTS admins also have the possibility to block some senders from working on the bug tracking system in case they deliberately do malicious things.

But being open and inviting everyone to work on bugs totally outweighs the troubles that sometimes pop up because of misuse of the control bot.

And that leads us to:

General guidelines: Dreamwidth, Zulip, MediaWiki, and Debian don't discourage people from filing bug reports in the official central bug tracker. Even someone quite new to a particular codebase/project can file a very helpful and clear bug report, after all, as long as they know the general skill of filing a good bug report. Rather, I think the philosophy is what you might find in hospitable activism in general: meet people where they are, and provide a means for them to conveniently start the conversation in a time, place, and manner that's more comfortable for them. For a lot of people, that means email, or the product itself.

Failure modes can include:

  • a disconnect among the different "places" such that the central bug tracker is a black hole and nothing gets reported back to the more accessible place or the original reporter
  • a feeling of elitism where only special important people are allowed to even comment in the main bug tracker
  • bottlenecks such that it seems like there's a non-bug-tracker way to report a question or suggestion but that process has creaked to a halt and is silently blocking momentum
  • bottlenecks in bug triage
  • brusque reaction at the stage where the bug report gets to the central bug tracker (e.g., "oh that's a duplicate; CLOSE" without explanation or thanks), which jars the user (who's expecting more explicit friendliness) and which the user perceives as hostile

Whether or not you choose to increase the number of interfaces you enable for bug reporting, it's worth improving the user experience for people reporting bugs into your main bug tracker. Tedious, lots-of-fields issue tracker templates and UIs decrease throughput, even for skilled bug reporters who simply aren't used to the particular codebase/project they're currently trying to file an issue about. So we should make that easier. You can provide an easy web form, as Wikimedia did via the simplified Bugzilla form, or an email or in-application route, as Debian does.

And FLOSS projects oughta do what the Accumulo folks did for Kuper, too, saying, "I can file that bug for you." We can be inclusive-or rather than exclusive-or about it, you know? That's how I figure it.


* Those products were CityDesk, Copilot, and FogBugz -- this was before Kiln, Stack Overflow, Trello, and Glitch.

Thanks to Lindsey Kuper and Jillian C. York for sparking this post, and thanks to azurelunatic for making sure I got Dreamwidth details right.


(2) : Changing How I Deal With Those Humiliating Teenage Memories: When I was in high school in Lodi, California, I worked on the school newspaper. It came out every two weeks; we gave it to the printer on Tuesday night or early Wednesday, I think, and we received and distributed it on Friday. So there was a deadline night every other Tuesday. For dinner, our tradition was to order calzones from a particular Italian place in Lodi; they didn't deliver, so one of the students who could drive would drive their car to go get the food.

One night I was the one who collected people's orders and made the call. But I lived in Stockton, some distance from Lodi. When finding the restaurant's phone number in the phone book, I absentmindedly chose the Stockton location and placed our order with the wrong restaurant. Catie* drove to the Lodi restaurant came back from her drive very unhappy and empty-handed; there wasn't time to go all the way to Stockton back and still hit the deadline for the printer, so we didn't get dinner that night.

Later that week, maybe the next day in the journalism room during lunchtime, I was about to go to the cafeteria, maybe to get my own lunch, but definitely also to get Catie's as well (she paid for her own lunch, it wasn't completely feudal). I think someone else said they could do it, but I still remember Catie snapping: "Hari can get me a burrito."

(Everyone at my high school newspaper called me by a shortened version of my last name, pronounced "Hairy". My journalism teacher called everyone by their last names, and had a devil of a time with mine, so on the third or fifth day of class my freshman year, I offered this solution. I have lost track of everyone I knew through that paper but I bet most of them would still think of me as Hari. I feel as though I ought to be embarrassed by this, or as though I should have been, but this is one of the ways social obliviousness protected me, for which I'm grateful.)

This happened twenty years ago and I still remember it. I especially remember it when I am taking care to order food from the restaurant location I intend, as I did last night.

The memory still has the power to wash chagrin over me. I can see why it does. I wasn't diligent about checking a detail, and so some of my team went hungry for a night,** and at least one of them was still irritated with me the next day. I feel a lot more embarrassed about that than I do about a nickname that didn't hurt anyone but me.

Several years ago, when I thought about this or similar past mistakes, I'd flush with feeling, humiliation coursing through me. I would subvocalize my self-loathing. Stupid.

Then I matured a bit, and my response changed. When I felt that rush of humiliation, I'd try to actively say, I love you, Sumana, and send myself some compassion. It helped me avoid going into a complete spiral of self-loathing, but it didn't stop the memories from coming back, unbidden, every so often.

Then I got enough distance to look back and see patterns. I grew to be different enough from teenage Sumana that I could see what she needed to learn -- like asking for help, resourcefulness, organization, resilience, dealing with failure. I'm better at those things than she was. And I can see ways that the people around me could have made better choices, too. I tried to make little moral lessons out of those still-piercing memories. As the saying goes, good judgment comes from experience, and experience comes from bad judgment.

But all of these approaches assume the pain of the memory is a problem to be solved. Today I'm going to try to lay that aside. What if I just accept and experience that pain? This is what I'm feeling right now. And then this too shall pass; I always do move on to thinking about something else, empirically. Maybe I will just keep on occasionally remembering this and feeling bad about it, maybe on the last day of my life I will remember this thing and feel bad, and that's okay.


* Not her real name.
** You know what, actually, we probably could have figured out a way to get some food that night anyway if we'd thought about it, call someone's parents or something.

Filed under:


: The Rumpelstiltskin Fallacy: I sometimes sum up the lesson of a liberal arts education as: socially constructed things are real, too. And you are not immune from their effects, no matter how smart you are or whether you've noticed that something's a social construction. It's not like Rumpelstiltskin, where once you've named the thing it has no power over you. In fact, approximately zero problems are like that; saying "well this looks like a ____ situation" is insufficient to fix it.

And consequently, socially constructed things are worth studying and working on and using and fixing and spending energy on.


(1) : How to Teach And Include Volunteers who Write Poor Patches: You help run an open source software community, and you've successfully signalled that you're open to new contributors, including people who aren't professional software engineers. And you've already got an easy developer setup process and great test coverage so it's easy for new people to get up and running fast. Great!

Some of the volunteers who join you are less-skilled programmers, and they're submitting pull requests/patches that need a lot of review and reworking before you can merge them.

How do you improve these volunteers' work, help them do productive things for the project, and encourage and include them?

My suggestions for you fall into three categories: helping them improve their code, dealing with the poor-quality pull requests themselves, and redirecting their energies to improve the project in other ways.

Teaching them to improve their code

Dealing with poor patches themselves

Using their knowledge and curiosity to improve the project in other ways

  • Ask these developers to write "discovery reports". They're already user-testing your developer onboarding process; ask them for their experiences, so you can find and fix pain points.
  • Ask them to run through some manual testing (example manual testing guide from Zulip), and to tell you how long certain kinds of tests took, so you can get bug reports and improve the docs.
  • Ask them to teach about your project in their communities -- to develop learning and presentation materials and speak at meetups. You may have just found your most enthusiastic marketer.
This list is absolutely not the be-all and end-all for this topic; I'd like to know what approaches others use.


Thanks to Noah Swartz for starting a conversation at Maintainerati that spurred me to write this post.


: A Small Language Note: I try not to say "don't get discouraged," because to me that sounds like telling someone not to cry or telling someone to calm down. It's a way of saying "stop feeling what you're feeling." Instead, I try to acknowledge that something is discouraging but also -- if the other person's ready to hear it -- that we can come back from that: your feelings are legitimate, and here are some ways to work with them.

Filed under:


(2) : Scifi Takes on Coen Brothers Movies: Leonard writes scifi novels, and one of them (that a publisher is currently considering) has the working title Situation Normal, a followup to the previous working title, Explosion of Honor. It's witty military scifi -- like Star Trek as directed by the Coen brothers, as I told some folks at MergeSort. A few of them didn't care for the title Situation Normal and didn't get a "this has humor" vibe from it, so I told Leonard.

"OK, here's a title suggestion. 'Bargo," I said. "It's, like, short for 'embargo' but it'll remind people of Fargo."

"I got some bad news for you. It did not remind me of Fargo. Also there is no embargo in the book."

"Oh there isn't?"

However we did start thinking of more scifi takes on Coen brothers movie titles:

  • Green Blood Simple
  • Intolerable Cruelty To Robots
  • The Man Who Wasn't There Because He Got Teleported
  • True Grid
  • A Serious Spaceman [or, A Sirius Man]
  • O Brother Where Art Thou? Venus
  • Hail, God-Emperor!
  • The Hudsucker Epoxy
  • The Amazing Colossal Lebowski
  • No Planet For Old Men
  • Inside Llewyn Davis [unchanged]
  • @bartonfink
  • Literally Raising Arizona
  • Burn After Scanning
  • The Ladyreanimators
(If you liked this, consider skimming "Tonight's Episode".)
Filed under:


: What Does An Award Do?: I posted on MetaFilter about the new Disobedience Award that MIT Media Lab is starting (nomination deadline: May 1st). And in the comments there, I stumbled into talking about why one might found an award, and thought it was worth expanding a bit here.

I think anyone who thinks for a second about awards -- assuming the judgment is carried out in good faith -- says, well, it's to reward excellence. Yup! But what are the particular ways an award rewards excellence, and when might an award be a useful tool to wield?

Let's say you are an organization and you genuinely want to celebrate and encourage some activity or principle, because you think it's important and there's not enough of it, particularly because there are so many norms and logistical disincentives pushing to reduce it. For example, you might want to encourage altruistic resistance. Let's say your organization already has a bunch of ongoing processes, like teaching or making products or processing information, and maybe you make some changes in those processes to increase how likely it is that you're encouraging altrustic resistance, but that isn't really apparent to the world outside your doors in the near term, and the effects take a while to percolate out.

So maybe you could set up an award. An award can:

  • get publicity for the idea that altruistic resistance is a thing to celebrate
  • help one specific person or group who's currently practicing altruistic resistance keep going, with money and attention, and make a big difference to their stamina and effectiveness
  • maybe bring attention to a list of finalists and help their work get more coverage
  • ensure the award administrators (and any judging committee involved) and, to a lesser extent, the reporters covering the award, will spend time thinking about the importance of altruistic resistance
  • cause a bunch of people to think "hmm, whom should I nominate?" and write a couple paragraphs about why their work is good and award-worthy (and, by causing that writing, also solidify the nominators' commitment to respecting and rewarding altruistic resistance)
  • demonstrate your institutional commitment to altruistic resistance, potentially sending a hard-to-ignore message to your future self to guide future decisions

And if an award keeps going and catches on, then people start using it as a shorthand for a goal. New practitioners can dream of winning the acclamation that a Pulitzer, a Nobel, a Presidential Medal of Freedom carries. If there's an award for a particular kind of excellence, and the community keeps records of who wins that award, then in hard moments, it can be easier for a practitioner to think of that roll call of heroes and say to herself in hard moments, "keep on going". We put people on pedestals not for them, but for us, so it's easier for us to see them and model ourselves after them.

So, all awards are simplistic summative judgments, but if the problem is that we need to balance the scales a bit, maybe it'll help anyway.

Nalo Hopkinson is doing it via the Lemonade Award for kindness in the speculative fiction community. The Tiptree Award does it for the expansion & exploration of gender. Open Source Bridge does it for community-making in open source with the Open Source Citizenship Award for "someone who has put in extra effort to share knowledge and make the open source world a better place."* It's worth considering: in your community, do people lack a way to find and celebrate a particular sort of excellence? You have a lot of tools you could wield, and awards are one of them.


* I realized today that I don't think the list of past Open Source Citizenship Award recipients is in one place anywhere! Each of these people was honored with a "Truly Outstanding Open Source Citizen" medal or plaque by the Open Source Bridge conference to celebrate our engagement "in the practice of an interlocking set of rights and responsibilities."


: Upcoming Talks: I happened upon the New York state Assembly's website last week,* and noticed an upcoming hearing about "Government oversight of forensic science laboratories" (PDF), hearing oral testimony by invitation only. I wondered: Who's on the list of witnesses? And will any of them talk about the danger of closed-source, unauditable code used in forensic science in the criminal justice system?

I followed up, and we got me, plus Rebecca Wexler, the author of that piece, invited to speak. We're testifying tomorrow, Wednesday, February 8th, in New York City. In preparation, I'm conferring with Karen Sandler of Software Freedom Conservancy (who was slotted to speak but now can't) and with acquaintances who work in government forensic labs.

I did speech and debate in high school so in some sense I have been preparing for this for twenty years.

A little further off:

Next week, I will participate in the WONTFIX Cabal (Maintainerati) unconference for open source maintainers on February 15, 2017, in San Francisco, California, USA.

I will give the closing keynote address at LibrePlanet, a free software conference, March 25-26, 2017, in Cambridge, Massachusetts, USA. Tentative title: "Lessons, Myths, and Lenses: What I Wish I'd Known in 1998."

I will be one of the Guests of Honor at Penguicon, an open source and science fiction convention, April 28-30 2017, in Southfield, Michigan, USA.


* via Lauren Sperber's blog post about "the New York State Reproductive Health Act to get abortion removed from New York State's Penal Code"


: On LiveJournal: I've posted to MetaFilter about some recent goings-on at LiveJournal; if you have an LJ account you should probably take a look.

Filed under:


: Yuletide 2016 Recommendations: Every year the Yuletide fanfic exchange delivers a bounty of fun transformative works concerning books, movies, songs, games, news stories, and other parts of our media landscape. I myself have, as they say, committed fanfic a few times, but right now I'm much more a reader and cheerleader than a fiction-writer. I have only started on this year's harvest but I already have some favorites to recommend:

A hopeful story, using "Expert judgment on markers to deter inadvertent human intrusion into the Waste Isolation Pilot Plant" (you know, "Sending this message was important to us. We considered ourselves to be a powerful culture.") to tell a ghost map story. (If you want more hope about far future human civilizations, try the fanvid "Dance Apocalyptic" which cheered me this year. And here's more fic about those waste markers.)

This fairy tale, about children and destiny, stands alone so you can read it even if you've never looked at the illustrations that inspire it.

There was once a land, long before and far away from these troubled times, where every child was born with a desire and a destination marked upon them, so that they might know what dwelt in their future. Upon their left hand, a symbol to represent what would give them the greatest happiness in their life. And upon their right hand, a compass that would lead them in the direction of where their desire might be found.

If you liked Hail, Caesar!, perhaps you wanted to revel in the loveliness of Hobie Doyle, who is an understated instance of the Captain Carrot/Middleman/Captain America/Agent Dale Cooper archetype.

The Ghostbusters get a call to a theater built in 1925, and Patty Tolan really shines.

"The War of the Worlds and All That" is a Jeeves and Wooster story that has aliens and mentions Gussie Fink-Nottle and the scripture knowledge prize Bertie won in school, and it's a bunch of fun. And if you're missing the sartorial scheming, enjoy "Jeeves and the Christmas Socks". (I grew up on Wodehouse and on the Fry and Laurie adaptations -- relatedly, here's a sweet story about Tony and Control.)

It's been a while since I read Jurassic Park but "A Strange Attractor in a Stable System" gets Ian Malcolm's voice so right.

If you enjoyed the 1941 movie Ball of Fire (particularly relevant to Wikipedians, incidentally), how about a crossover story that includes The Middleman? And, speaking of The Middleman, "The Extraterrestrial Elf Emergency" includes a paragraph I adore:

"We don't have Christmas on my planet," they said plaintively, through a translator box at the base of their throat. "All our holidays are about military victories and death. Christmas seemed fun."

This Mulan story makes the Disney movie make more sense in ways I had not even thought before.

If you enjoyed Good Omens then perhaps you will like one or more of the three different stories in which those characters enact their own version of "The Devil Went Down to Georgia".

I've never seen the 1944 film Gaslight but this story, set after the film, is about bravery and recovery and resilience and I drank it deep and felt nourished.

No, she thought. I must stop being afraid and bear this until it is done and then, then I'll consider what to do next.

I also enjoyed stories transforming Mrs. Piggle-Wiggle, Fresh Off The Boat, Arrested Development, Arrival, Baby-Sitters Club, and the Mahabharata. And I haven't finished this year's Yuletide yet. Thank you, authors and organizers!


: 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.

Filed under:


: 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): IWillVote.com 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:


(2) : 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!
bpython-interpreter.org

[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 example.py
Traceback (most recent call last):
    File "example.py", line 5, in 
        toprint = varname + "entries"
TypeError: unsupported operand type(s) for + : 'int' and 'str'
>>> varname
3
>>> type(varname)

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

Back cover of zine; transcription below

More: "A Few Python Tips"
harihareswara.net/talks.html
This zine made in honor of
MergeSort
NYC's feminist makerspace!
http://mergesort.nyc

CC BY-SA 2016 Sumana Harihareswara
harihareswara.net @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 codefile.py 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.

Example:

  • Expected result: doing run-dev.py 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...


: 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, ics.py, 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 create-fixed-ics.py 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.

Disclaimers:

  • 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, ics.py, 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]


about Sumana Harihareswara

Archives by year, archives by category


RSS feed
Dreamwidth feed
Identi.ca microblog
Twitter feed
Spam As Folk Art
Changeset Consulting

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.