Cogito, Ergo Sumana for 2020 September

# 01 Sep 2020, 01:45PM: Remedial Skills In Open-To-The-Public Working Groups:

I'm talking in this post about wikis, political clubs, open source projects, fanvidding exchanges -- any groups where people try to work together and are open to the public.

"No, what's that?"

Some people joining your groups don't know things you take for granted.

Years ago, while helping new applicants to Google Summer of Code get into working on (I think) MediaWiki or Zulip, I was talking with a person who was (at that time) a student in an Indian engineering college. He had run into trouble and was trying to debug a setup issue. He seemed to be asking for help but not systematically investigating what the problem might be.

So I said, let me give you some tips on troubleshooting. You've heard of the scientific method?

He said: no, what's that?

I gave him a link to the Simple English Wikipedia article on it -- and to the They Might Be Giants video for their song "Put It To The Test", on forming falsifiable hypotheses and testing them. I asked him to watch and read them and then tell me when he had done so. He did.

They Might Be Giants - Put It to the Test from They Might Be Giants on Vimeo.

I then said: so, you do that. You come up with a hypothesis for what might be the problem, and figure out how you would check to see if that is the case. You run the experiment, and you use the resulting data to refine your hypothesis -- if you're wrong, you try to come up with a new hypothesis. And then you either find and fix the problem, or if you get stuck, you at least have a bunch of data to give someone so they can help you better.

He said: THIS IS AMAZING! I'M GONNA USE THIS ALL THE TIME! And I was like IT IS! And then in a separate private conversation with colleagues, I was privately very angry with the educational system that had let him get that far without teaching him this!

[This is one of the experiences that led to me writing a fairly well-regarded blog post for new open source software contributors, on the scientific method, learning from and contributing to shared notes and logs, and self-reliance and interdependence.]

Lessons

Some lessons here for you:

1. Don't act surprised when people say they don't know something. Because (as I said a few years back) that’s just a dominance display. That's grandstanding. That makes the other person feel a little bit bad and makes them less likely to show you vulnerability in the future. It makes them more likely to go off and surround themselves in a protective shell of seeming knowledge before ever contacting you again.
2. Some gaps you can remediate. Sometimes it's as quick as the explanation and links I used above. Sometimes it's more involved, as with providing free English tutoring to your internship applicants. Sometimes remediation takes a lot more work, and you may not have time to provide it; see my suggestions in "How to Teach And Include Volunteers who Write Poor Patches" which include some lower-effort options, like the section "Using their knowledge and curiosity to improve the project in other ways."

   In open source projects, I think it's also okay to exclude unskilled people from a project based on "we do not have time to help them learn remedial skills, and this is not a suitable project for novices." If you are going to do this, explicit is better than implicit. You should try to forewarn contributors with explicit "not good for beginners/prerequisite skills are [list]" language in your README and CONTRIBUTORS files. And when you need to tell contributors that they aren't ready to participate in your group yet, you should offer them a redirect to a project more suitable to their skill level, you should take care not to insult them while redirecting, and you should tell them they'll be welcome back in the future after learning more of the prerequisites.

3. The scientific method is still as kickass a cognitive tool as it has ever been. It's amazing and empowering!

Thanks to Dr Linda McIver for the conversation that spurred this post.

---

# 03 Sep 2020, 11:27AM: On Accepting Nonzero Criticism, Even Hate: I'm thinking about how acceptance is not the same as resignation.

I was talking with a friend many, many months ago, and race stuff came up. He and I talked about a shared experience of talking to a stranger who has a marginalized identity, and having an anxious "don't [screw] this up, don't [screw] this up" voice in the back of one's head during the interaction. And one thing he said was that he doesn't want anyone to hate him.

And I found myself articulating something that I don't know whether I had before, which is: the optimal number of people who hate you is not zero, and if you aim for zero, you will never have that expectation met.

There will be good and bad things that happen to you that you do not in any way deserve (and "deserve" is a pretty dangerous word to let oneself use anyway along with "somehow" and "normal"). And so, sometimes, other people will be angry at you or hate you, and sometimes it's because of a specific thing you did, or because of your inherited unearned privilege or your position of power in an organization, and sometimes it's kind of out of nowhere because people get mad sometimes.

I think I have to be okay with the fact that, out of the 8 billion people on Earth, some of them kind of hate me. And then if I run into it, it's not a catastrophic surprise. It feels bad but I can have a bit of a windshield about it so the mud doesn't all get right on my face. As of a couple years ago, the place I ran into this the most was when I was called on my own cissexism or I saw "all cis people" complaints/generalizations -- the first time, it felt awful, and as of about a year ago, it just felt a little bad, mostly. As of right now, I think I'm most thin-skinned about whether or not I am doing okay at my job. Next year it'll be something else.

This kinda comes back to: you can only control what you can control. My friend and I can aim to live our values and to consider criticism we receive, and to deal with the unfair criticism the way we deal with any other unfair bad thing that happens to us, and to bask in and enjoy good things and share them with others.

And this is one reason it's useful to celebrate those small invisible wins, including "I refrained from saying something unnecessarily inflammatory" or "I quietly got a job description changed", because then you have a bit more evidence that can help you deal with the "oh no what if there is someone out there who can't tell that I am Trying" anxiety. This is, I think, especially pertinent now, during the pandemic, when more of us are cut off from talking in person, so it's harder to get those little reassurances that we are liked, valued. (This also applies to a lot of wanting-to-be-liked-as-a-manager/vendor/client stuff I see or engage in.)

I don't have a quantified error budget for this kind of error and I'm not sure it makes sense to. But, like Amandine Lee, I want to fine-tune my fear response so that it serves me better, and part of that is accepting that nonzero rate of criticism.

That acceptance can be used as cover for entirely disregarding pushback -- a purity binary, a false dichotomy. I don't want to do that. Acceptance is not the same as resignation. I want to instead believe, and act as though, the error rate is nonzero, and will always be nonzero, but I can push to drive it asymptotically closer to zero.

But also I am kind of okay with the fact that, even on a day when I've lived my values, someone may hate me, and may lob an unfair criticism at me. Not all the way okay. But kind of okay with it, and aiming to be more okay with it.

Which for me is all tied up with, like, self-trust, emotional security, and a belief in the idea that I am fundamentally okay and can also change my mind about things in the future, that there is going to be a future, and so on. And that since I believe in, to quote the Unitarian Universalist principles, "the inherent worth and dignity of every person" .... that includes me, now and after I learn whatever I learn next.

---

# 03 Sep 2020, 11:48AM: Making Groups, Leading Them, Treating Others Well: Some writing I've appreciated in the past year, on leadership, and on understanding others and treating them well:

synecdochic's "dreamwidth as vindication of a few cherished theories":

His decision to take energy away from his marathon coding sessions and put it into creating a positive and collaborative environment is a major reason why DW development is what it is today, and it was more than worth the extra few weeks' delay in going from closed beta to open beta.

"The Spy Who Came Home: Why an expert in counterterrorism became a beat cop" by Ben Taub:

Espionage hinges on human relationships. "The best assets I ever ran weren't in it for money," Skinner said. "They had this urge to be part of something bigger. It wasn't patriotism -- they just wanted to be part of a high-functioning team.”

Mary Anne Mohanraj's acceptance speech for her Locus Special Award for Community Outreach & Development:

So we saw a need, we came together with a group of friends and like-minded folks we gathered on the internet, and we made a thing to fix it. One of the best aspects of our genre is that it is full of such people and the organizations they’ve built.

Ada Palmer's "A Better Way of Understanding the Debate Over Free Speech on Campus":

In the nationwide debate over campus free speech, a lot of apparent disagreement derives from failing to separate the objects of study, and the habitat where study takes place.....the conditions needed to cultivate hard thought and judgment are not the same for all students...

"Doing ethical research with vulnerable users" by Bernard Tyers shares moving stories of talking with compulsive gamblers (some of whom did not know they were compulsive gamblers at the start of their conversations).

Fred Clark, Slacktivist, writes about how to deal with the dishonest weights of post-transaction surveys in "All fives (ready or not, here I come)". "You are asked questions in a language of lies and are thus forced to respond in kind."

And I deeply appreciated this essay on categories, pain, and an approach to getting better at treating others well. (This is a religious sermon that focuses on humility/love/empathy; feel free to skip, of course.) "'You're not a thing at all,' or 'The political implications of Dunbar's Number.'" is a sermon that Doug Muder (the Weekly Sift guy) presented on May 12, 2019. It's about cooperation, stories, parts we play and expect, Tolstoy, Disney, gender, inadequate and obsolete scripts, and the ideal of the perfect rulebook. Also discussed on MetaFilter.

"We want to belong, but we also want to be individuals .... I think we need to recognize that no matter how necessary it might be to simplify our experience somehow, there's always going to be an injustice in putting people into categories and dealing with them through roles and scripts. That's an injustice that we both suffer and inflict on others."

I also liked the phrase "to come into right relationship with our own pain".

---

# 08 Sep 2020, 10:13PM: Breaking Release Bottlenecks -- What Changeset Can Do: I did some volunteer work earlier this year, helping rejuvenate pipenv (a command-line tool that some people use to help handle Python packages they make and use). Here's what I did, how long it took, and how you can do the same.

Pipenv's maintainers had not released a new version since November 2018, and users were concerned (in many cases switching to competitors). In early March of this year, someone suggested that perhaps the official Python Packaging User Guide should stop recommending it. I saw that suggestion and went into the relevant Internet Relay Chat (IRC) channel to nudge one of pipenv's maintainers and to ask: what do you need? What's blocking you?

Dan Ryan ("techalchemy") knew what was blocking him:

techalchemy: if you're purely evaluating 'how do we release the code', yeah I might just be the main roadblock?
techalchemy: someone to yell at me to stop doing things that are not related to the goal?
techalchemy: lol
sumanah: let us assume that a successful release -- even as a pre-alpha -- is something that does not instantly break every user's life
techalchemy: yeah longer term planning though would require tech writing for sure and onboarding help, god do I struggle with that
techalchemy: have you heard me explain something...
sumanah: if you JUST want someone to yell at you to stop doing those unrelated things, just for about a month, then that can be cheaper .... would you actually _listen_ to that person?
techalchemy: historically speaking, I'd insist I was doing something important briefly but probably reassess, I do know what needs to happen
sumanah: :-) ok. So, how frequently do you need those checkins? like, 4 times a day, 5 days a week?
techalchemy: hopefully not that much, but I could see a few checkins being helpful especially if we were also onboarding some new people
sumanah: techalchemy: ~10 minutes of conversation, via IRC, 4 times a day, 5 days a week, for 3 weeks....

That would have worked out to about ten hours. We underestimated how long it would take Dan to address some nasty continuous integration bugs, so instead of three weeks it took three months. Over those months, I donated about 15 hours of my time, helping him release two betas, then a stable version in May. Given my current hourly rates, this constitutes a donation worth a few thousand dollars, which is infinitesimal compared to the value unlocked by expediting a pipenv release.

Dan needed someone to help him with prioritization, release management, and communications. So I:

• rewrote the release checklist and kept it updated
• updated GitHub issues and tweeted to keep users apprised, and to ask them for help testing the beta releases (including suggestions of specific cases to test, which I later adapted for pip)
• created draft outlines for him to fill in so he could write a status update and the beta release announcement for mailing lists/forums
• closed duplicate "is pipenv dead?" issues and updated a longer-term issue about maintainer needs, roadmap, etc.
• made a few documentation pull requests: nudged Dan and Ernest to move Pipenv docs from a nonfunctioning domain to pipenv.pypa.io, fixed a bunch of obsolete links, and edited Dan's "how to release" docs and made a pull request to move them into the repo and out of an ephemeral hackpad
• every few days, checked in with Dan via IRC or email (we also had a few videocalls) to help him stay on task

Phil Gyford noticed that initial IRC conversation and said:

It's kind of fascinating as an example of bottlenecks in open source development and the importance of project managers.

And Yoz Grahame replied:

I regularly have conversations like this, and it's a toss-up as to which of the two roles I play.

Yeah. An external perspective can help a lot. And, ideally, a project manager is a supportive accountability partner who helps with the bits you're not great at.

If you/your company depends on an open source project and you're getting annoyed or worried because the release cadence has slowed to a standstill, there's a strong chance you can turn that around. If someone on your team can spend a few hours complementing the existing maintainers and helping unblock them, that could save you a bundle compared to forking or switching dependencies. Try talking with the maintainers about what they need. And I do mean talking, as in, synchronous conversation via voice or chat, so you can build some trust and get the kind of conversation you see in the IRC log above.

Or: contact Changeset Consulting for a free initial 30-minute chat. Maybe it'll only cost you a few thousand dollars to get that bottleneck unblocked. Let's find out!

---

# 09 Sep 2020, 08:37PM: Cool Music Rec: Abundance: Last year, via a BBC Gaelic and Celtic music show, I discovered a rockin' instrumental tune with horns and strings. It is so rockin' that I wanted to know more! Despite not knowing Scottish Gaelic, I worked out that the song's "The Kelburn Brewer", and is a collaboration involving Natalie Haas and Alasdair Fraser and closes their CD "Abundance". Here's "The Kelburn Brewer" as a YouTube track. Gets going around 0:34, then picks up further about a minute in, then increases its jammin'-ness as it goes. Enjoy! You can also buy "Abundance" as unencumbered MP3s and I recommend this because you get a bunch of cheery instrumental music by indie artists on an indie label! And the instruments include kalimba! I had never heard of kalimba before!

---

# (1) 16 Sep 2020, 07:13AM: I Miss You, Friends And Strangers: I met you in a storytelling workshop taught by someone later discredited.

I met you in the front-row fandom for a now-defunct sketch comedy troupe.

I met you at a women's networking event where you were the only person I talked with who wasn't tedious.

I met you -- you remember that it was a Redditors' meetup, but it must have been cross-pollinated with something else, maybe a scifi thing?

I met you through work -- we were remote colleagues who saw each other several times a year, and then you moved to New York.

I met you through a meditation workshop you led.

I found your blog through a link from a friend, then met you at a scifi thing, maybe a Tor.com party or a Cory Doctorow reading.

You, I first met at a Tor.com party, I'm sure.

I met you at WisCon.

I met you through a friend I went to middle school with.

I met you when a colleague let me regularly cowork at the nonprofit where he and you worked.

I met you when we were at Recurse Center together.

We probably first met at an Electronic Frontier Foundation thing, maybe here, maybe in San Francisco.

I met you through your girlfriend, now wife.

I can't quite remember how we first met because we're connected in a few ways.

We met on the MTA when one of us recognized the other's stickers/t-shirt.

I met you through someone I met at WisCon.

I met you through Leonard's writing group.

I met you because we volunteer on Python packaging tools together.

I met you at the now-ended Open Source Bridge conferences.

I met you in a local political activism group.

I think I met you in a friend's storyreading circle.

I met you through fandom on Dreamwidth, and then invited you to a meal.

I met you through fandom on Dreamwidth, and then you recognized me at an N.K. Jemisin reading.

I met you at PyCon or Open Source Bridge, I think.

I met you through a Wikimedian friend.

I met you when we were undergraduate students together, twenty years ago.

I met you through the business you run.

I met you through the nonprofit you ran.

I met you through the ex you're now estranged from.

And so on.*

I have lived in New York City for ~15 years, and over that time I've grown several local friendships, some lighter and some stronger. I miss seeing you.

I was a kind of isolated teenager who had very few friends. I'll amend that. When I was in high school, I had one friend at the "talk on the phone about something other than homework" level. I invited people to come see a movie with me** for a birthday and no one came.

Over the decades since, I've become much more accustomed to making, having, and regularly seeing friends. In a September week last year I had breakfast with one friend and lunches with two friends, not counting the folks I saw at various clubs, groups, and events.

Every few weeks I contact some friends and arrange phone or videocalls. Some of you I haven't talked with in way too long and we're more acquaintances now. And I talk with people in other places a lot -- I have friends spread out so far. If my New York-area friends may as well be in other countries, a friend in Asheville may as well be in another solar system, for how impossible it feels to imagine that we'll see each other again.

For the past few months, my friend Mike Pirnat DJed a radio show on his old college radio station. His usual outro is Vera Lynn's "We'll Meet Again" (don't know where, don't know when). I've listened to it dozens of times now and only today am I realizing how I could read it as not descriptive but prescriptive.

Right now I am doggy-paddling to keep myself above water, and part of that is keeping up with the friends I have made, especially the local friends. But someday I want to meet a stranger and make friends with them again. That's a vision to look forward to.

* Sorry if I missed you - I'm sure that as soon as I hit Post I'll think of three more to add, and then three more....

**In retrospect, Beyond Rangoon was not the most appealing selection for most teens.

---

# 17 Sep 2020, 11:13AM: Guitars And Rock Climbing, But As Analogies For Less Glamorous And Immediately Appealing Actitivies: I was explaining to a friend a few days ago the thing I mention in my RC & MetaFilter post, about how I'm trying to avoid saying "community" when I might mean "constituency" or "group" or similar. And perhaps we should say "society" sometimes -- a group that shares some norms and heritage and places to talk with each other, but doesn't necessarily take responsibility for anything. And how the phrase "the open source community" is laughable.

But wait, they said, noting that in open source everyone has to operate by some shared rules, right?

Well, kinda, yes, I said, in that everyone's working with openly available code that's under an OSI-approved license. But they're in such different situations, and paid vs. unpaid is just part of it! Think about people who play the guitar. A rock star, a session musician, a music teacher, a member of a garage band, someone putting videos on YouTube as a kind of audition for stardom, a beginning student .... they all might be playing the same sheet music or tab, but they're really doing different things.

[The field guide to open source project archetypes that Open Tech Strategies and Mozilla are developing (PDF of the first edition) is an excellent framework for thinking about these different situations and how they structure open source projects' capabilities, who's in charge, and what you can expect.]

Then, yesterday, I was reading, then skimming, a deeeeeeeply domain-specific, detail-heavy blog post about how to implement something of particular interest to the author. And at the end, of course, they say that they're starting an open-source implementation, a prototype. And I felt as though I could see into the future -- this person creating a bit of an application, other people loving it, the project growing in popularity and importance to others, the creator wanting to step away and explore other stuff. And there the timeline fractures, depending on whether anyone took steps to get it under someone else's care, get a company to steward it or grow a vibrant collective around it.

There are a bunch of developers who want to do hard things the same way that mountain climbers want to climb hard mountains. And as a side effect of this sometimes they emit some open source artifacts, as pitons sunk into the mountainside, and if you want to follow the way they went, very closely, you can reuse those pitons. Which is great and useful.

But that is only a first step towards infrastructure -- towards robust, comfortable, safe, scalable systems. And I am the millionth person to complain on her blog about the asymmetry and fragility and just inherent ridiculousness of how much really important, widely-depended-on infrastructure in our industry is basically "reuse the leftover pitons from past explorers". But it is still complainworthy. I hereby complain. Complain! And there's a reason so many of us are doing things about it (as in my case recently and for the last five years).

---

# 17 Sep 2020, 12:36PM: Some Followups From LibrePlanet 2017: I see that back in March 2017, I made a draft of some followup notes for my LibrePlanet 2017 keynote "Lessons, Myths, and Lenses: What I Wish I'd Known in 1998" (schedule description, video, in-progress transcript). I'm going to barely annotate/format this and post it as more of a found artifact and less of a designed communications instrument.

Wampanoag people

The Infinite Wrench

Mel Chua, Alex Bayley, Ashe Dryden, Christie Koehler

Open Source Bridge 2012

Kevin Gorman & Chip Deubner

Geek Feminism

Hans Reiser

Jupyter, Library Simplified, Zulip & zulipbot & good code review, Software Carpentry (save a day of work a week for the rest of their working lives), Dreamwidth and dw-dev, Beautiful Soup, Archive of Our Own, GNU Mailman and what's new in Mailman 3

Seth Schoen

Yudhisthira

Joseph Reagle

Kannada

Vajra Chandrasekera

---

# 20 Sep 2020, 04:22PM: Availability This Week: Heads-up about availability: I'm attempting to take this week (Sept 21-25) off from client/Changeset work, doing lots of biking and reading and writing. Letting you know in case you email me about anything.

---

# 30 Sep 2020, 12:24PM: Changes Coming To Pip In October 2020: People who deal with Python: Changes are coming to pip, Python's package installation tool, in October 2020. Please share this migration guide and our video with your circles.

SHORT VERSION:

I'm working on improving the Python packaging toolchain, foundational work that will (in the long run) make the whole Python experience way less confusing. In the short term this may mess with some people's workflows, so we want lots of people to hear about it now.

The pip team made a 2-minute video to explain what's up:

We are also doing user experience studies, and want you to sign up if you ever do anything with Python (whatever your level of skill/experience).

Please boost this toot or retweet this tweet if you want to help us get the word out.

MORE DETAILS:

Computers need to know the right order to install pieces of software ("to install x, you need to install y first"). So, when Python programmers share software, like when they publish packages on the Python Package Index or internally in large companies, they have to precisely describe those installation prerequisites. And then pip needs to navigate tricky situations when it gets conflicting instructions.

Up until now, pip's been very inconsistent in handling this stuff, which makes it easy for your Python environment to get messed up. That's why we successfully applied for $407K in funding from Mozilla and the Chan Zuckerberg Initiative to finish and roll out a proper dependency resolver for pip. The goal is that pip will get better at handling that tricky logic, and easier for you to use and troubleshoot.

You can test the new behavior (in beta) right now by using an optional flag in pip 20.2. And in pip 20.3, coming in October, the new behavior will be the default.

Once you're using the new resolver, pip is going to be stricter and more consistent. So things won't mysteriously break as much, and we can add more features that lots of people want.

But! Right now, a ton of people unknowingly have Jenga towers of wobbly dependencies in their environments and will run into pain when we make the resolver stricter and more consistent. And this may lead to you getting stuck in troubleshooting, assuming that pip caused the problem, when actually the deeper cause is conflicts among how your upstreams specify requirements (TensorFlow just fixed a related thing, for example).

So: We're trying to get Python users to try out the beta of the new resolver that's available in the current stable release of pip (20.2), fix your own environments, report bugs in your upstreams in advance, and report bugs to us so we can fix them in the next couple weeks. We started spreading the word about this a few months ago. And now: video! People watch videos, I hear? I hope this helps.

---