Cogito, Ergo Sumana
Sumana oscillates between focus and opportunity

: She's Out:

Tomorrow is a highway broad and fair,
And we are the many who'll travel there.
Tomorrow is a highway broad and fair,
And we are the workers who'll build it there;
And we will build it there.

Come, let us build a way for all mankind,
A way to leave this evil year behind,
To travel onward to a better year
Where love is, and there will be no fear,
Where love is and no fear.

Now is the shadowed year when evil men,
When men of evil thunder war again.
Shall tyrants once again be free to tread,
Above our most brave and honored dead?
Our brave and honored dead.

O, comrades, come and travel on with me,
We'll go to our new year of liberty.
Come, walk upright, along the people's way,
From darkness, unto the people's day.
From dark, to sunlit day.

Tomorrow is a highway broad and fair
And hate and greed shall never travel there
But only they who've learned the peaceful way
Of brotherhood, to greet the coming day.
We hail the coming day.

("Tomorrow Is A Highway" -- words by Lee Hays, music by Pete Seeger)

We didn't know how it was going to turn out. We thought she'd be in prison for decades more. And then, even after President Obama commuted her sentence, I remained privately worried that something would happen, some snag or tragedy. Yesterday she got to have a hot slice of pizza -- so a few people gathered at my apartment and shared pizza and toasted her release. It was so good to have something to celebrate with friends.

I've been listening over and over to "Tomorrow Is A Highway". It's got some lovely stark lines, like "leave this evil year behind." Time and space have unified ; it doesn't say that we'll walk into the future, but rather, that the future is this journey, and there are only two time durations in this song, days and years -- tomorrow is a highway upon which we'll travel to a better year. And it's sort of a mix of prescriptive and descriptive, prophetically defining us as the people who are making this tomorrow. This song does not explicitly say "this might happen" or "we should hope for this to happen"; instead it combines "this will happen" and "let's make it happen". It's less a song of hope, and more a song of faith and promise and invitation.

It can be hard to let go of hope, and it can be hard to let go of dread. I can stop holding my breath now. She's out. We've moved from promise to fact.

I can't seem to find my copy of Ursula K. Le Guin's The Dispossessed at the moment -- did I lend it to you? In it, Shevek thinks a few times about how our conception of time and promises and intentions work together -- a coherent future doesn't just happen, it's intentional human actions that make a "road" and breaking promises denies and breaks that "road" connecting past, present, and future.

I have been feeling as though nothing is solid under my feet. And part of that is that I couldn't trust that she'd really get to be free. But now she is. And for the sake of my own forward motion I shall work as though the next stretch of the road exists too -- perhaps every step is in some measure a leap of faith.


: PyCon & WisCon: I just updated my "Talks" page -- I'll be at PyCon May 19-25, to represent Zulip at a booth and then to help run the Zulip development sprint. I will likely also have a new zine to share!

And then I'll fly straight from there to Madison for WisCon. I am not on any panels at WisCon this year but I'm the auctioneer for the auction benefiting the Tiptree Award. This year's auction includes a signed first edition hardcover of Octavia Butler's novel Wild Seed, an "Elect Alison Hendrix" pin from Orphan Black, an art print of "Aswang, at Night" by M Sereno, and a bunch more.

(As much as I love Open Source Bridge, I won't be there this year, and I won't be at Worldcon 75 (Helsinki) either, in case you're wondering.)


: OSCON, For a Single Day: I'm going to be at OSCON in Austin, Texas to represent Zulip in the Open Source Alley tomorrow (Thursday) 10am-4:30pm. Please consider coming by and getting a demo, or just talking with us about Python 3, mypy, and how we help new contributors (especially those who have a hard time setting up development environments on their own machines).


: Timesaving Negativism or Masculine Calumnies?:

"Do your lairstone relations HAVE to come over?" she snooted.

"Look, my uncles are almost done repairing their peatship, so happiest case, this is the last time for a long while."

"After all day patching up that thing, I suppose they'll need a nightcap."

"'Just a teardrop,'" he parroted.

"And then they'll intoxicate themselves into such a state of excitation --"

"I promise you, I understand your exasperation, but if my zombie uncles forget their precautions and catch another xenoparasite, this time it's on them to dig it up."

"Fine -- but you serve this time, I'm not a starwise waitress."


(This tiny short story inspired by Mark Dominus's list of awesome English anagrams and his !!Con talk on this topic.)

Filed under:


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


2017 May
MonTueWedThuFriSatSun
12345672
8910211121314
1516217182192021
22232425262728
293031    

4 entries this month.

Categories Random XML
Password:

[Show all]

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Permissions beyond the scope of this license may be available by emailing the author at sumanah@panix.com.