Categories: sumana | Management and Leadership
# 05 Sep 2017, 03:38PM: From Conversation:
A few recent thoughts.
- The power of "instead": One of the transdisciplinary lessons from Agile is that it's harder for most people to specify "this is what I need" than to look at a suggested solution and talk through "here's why this doesn't work for me." Another way to see this: generating initial idea-seeds is a useful gift, even if we don't implement any of them, if discussing them leads to us figuring out what we really want. "Instead" is a goldmine.
- Margaret Killjoy's fiction: I was talking with friends about Margaret Killjoy's fiction the other night and realized I should gush about it someplace where more people will see.
In late 2016 and early 2017, the two books that remedied the political doom in my head were Cory Doctorow's Walkaway (you can read the accompanying novella Party Disclipine for free) and Rebecca Solnit's Hope in the Dark (I have not finished this yet but have found a lot of solace in it). Now I've found a third: Margaret Killjoy's novella The Lamb Will Slaughter the Lion. It's so perceptive "about the lure of authority" and about all the microreactions we have when we meet new acquaintances and decide how much to trust them, and thrilling (although if a bit of horror gore squicks you out, you might want to sit this one out). Like Killjoy's "Men of the Ashen Morrow" and "Everything that Isn't Winter" it's also a closely observed story about violence, loyalty, vulnerability, sacrifice, and the ways we try to influence each other when we don't have traditional capitalist/bureaucratic hierarchies to bring to bear.
In "Everything that Isn't Winter", our point-of-view character is a resident and guard of an egalitarian commune, itchy and melancholy about their own too-well-developed capacity for and comfort with violence. I found it refreshing to see the competence demonstrations, loyalty, sacrifice, tradecraft, and suspense I'd usually see in military SF deployed in a story about the defense of an egalitarian commune in the woods.
The Lamb Will Slaughter the Lion (available as an ebook for NYPL patrons to borrow via the SimplyE app for Android and iOS) particularly spoke to me in its attention to the subtleties of power and influence, especially in nonhierarchical organizations -- it brings the fantastic lens to "The Tyranny of Structurelessness". What does it feel like and what happens, within each of us and among us, when our inability to persuade others to take urgent collective action collides with the heartfelt desire to avoid dominating others?
Killjoy's fiction, like Walkaway and Party Discipline, shows us not just arguments people might say or think in the service of a freer life, but the forms those lives might take, the feelings and relationships that would emerge. Narrative gives us people to love and to imagine ourselves in community with. Recently I read lazenby's essay on the body as compared to art or love:
Art, as Ruskin wants it to be seen, is a co-equal portal of creation through which it is possible to glimpse a world that is something other than the vigorous hybrid of cleverness and sadism....
In rather the same way that art does not rely on the logic of power or the power of logic, its example allows us to see still other ways of thinking....
I attended a Regina Spektor concert a few weeks ago that felt numinous. Live music, like great narrative, is one of those magic things for me. If you have been feeling airless and sewn to the ground, I hope you find a chunk of magic somewhere that helps you.
- Wedding bells: My friends got married! Awwwww.
# (1) 07 Apr 2017, 03:36PM: 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: 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: 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 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).
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.
# (1) 04 Apr 2017, 12:37PM: 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
- Collect and suggest relevant learning resources, like certain talk recordings or freely available articles/exercises (e.g. The Architecture of Open Source Applications), and ask them to come back after they've watched/read/done them. Example: Zulip's collection.
- If developers have trouble writing good comments and commit messages, or diving into the codebase to find relevant files and commits, point them to my blog post "On the scientific method and usable history". It explains why it's important to do that, and gives them pointers.
- Ask more experienced contributors to pair program with them, both as leader and as follower. Here are a few tools to help.
- Run live coding exercises, over chat or video, where an experienced developer speaks aloud as she writes a bugfix, including all the little steps like searching for related commits, setting up and running tests, etc. This enables newer developers to learn a lot of tips that help them work faster and write higher-quality code. I've done this at Wikimedia with live video and we use Zulip for a live text approach (see Alicja Raszkowska's transcript and notes of one such session).
- If a big problem with their submissions is poor English writing skills, run some English tutoring sessions.
Dealing with poor patches themselves
Using their knowledge and curiosity to improve the project in other ways
This list is absolutely not the be-all and end-all for this topic; I'd like to know what approaches others use.
- 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.
Thanks to Noah Swartz for starting a conversation at Maintainerati that spurred me to write this post.
# 16 Mar 2017, 05:37PM: 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."
# (1) 31 Oct 2016, 11:47AM: 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.
# 27 Oct 2016, 11:06AM: 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.
# 04 Aug 2016, 03:51PM: Advice on Starting And Running A New Open Source Project:
Recently, a couple of programmers asked me for advice on starting and running a new open source project. So, here are some thoughts, assuming you're already a programmer, you haven't led a team before, and you know your new software project is going to be open source.
I figure there are a few different kinds of best practices in starting and running open source projects.
General management: Some of my recommendations are the same kinds of best practices that are useful anytime you're starting/running/managing any kind of project, inside or outside the software world.
For instance: know why you're starting this thing. Write down even just a one-paragraph or 100-word bulleted list description of what you are aiming at. This will reduce the chance that you'll look up one day and see that your targeted little tool has turned into a mess that's trying to be an entire operating system.
And: if you're making something that you want other people to use, then check what those other people are already using/doing, so you can make sure you suit their needs. This guards against any potential perception that you are starting a new project thoughtlessly, or just for the heck of it, or to learn a new framework. In the software world, this includes taking note of your target users' dependencies (e.g., the versions of Python/NumPy that they already have installed).
Resources I have found useful here include William Ball's book on theatrical direction A Sense of Direction, Dale Carnegie's How to Win Friends and Influence People, Fisher & Ury's Getting To Yes, Cialdini's Influence: The Science of Persuasion, and Ries & Trout's Positioning: The Battle for Your Mind.
Tech management: Some best practices are the same kinds of habits that help in managing any kind of software project, including closed-source projects as well.
For instance: more automated tests in/for your codebase are better, because they reduce regressions so you can move faster and merge others' code faster (and let others review and merge code faster), but don't sweat getting to 100%, because there's definitely a decreasing marginal utility to this stuff. Travis CI is pretty easy to set up for the common case.
I assume you're using Git. Especially if you're going to be the maintainer on a code level, learn to use Git beyond just push and pull. Clone a repo of a project you don't care about and try the more advanced commands as you make little changes to the code, so if you ruin everything you haven't actually set your own work back. Learn to branch and merge and work with remotes and cherry-pick and bisect. Read this super useful explanation of the Git model which articulates what's actually doing what -- it helps.
Good resources here include Brooks's The Mythical Man-Month, DeMarco & Lister's Peopleware, Heidi Waterhouse's "The Seven Righteous Fights", Camille Fournier's blog, and my own talk "Learn Tech Management in 45 Minutes" and my article "Software in Person". I myself earned a master's in technology management and if you are super serious about becoming a technology executive then that's a path I can give more specific thoughts on, but I'm not about to recommend that amount of coursework to someone who isn't looking to make a career out of this.
Open source management: And some best practices are the specific social, product management, architectural, and infrastructural best practices of open source projects. A few examples:
If you're the maintainer, it's key to reply to new project-related emails, queries, bug reports, and patches fast; a Mozilla analysis backs up our experience that a kind, fast, negative response is better than a long silent delay. Reply to people fast, even if it's just "I saw this, thank you, I'm busy, will get to this in a few weeks," because otherwise the uncertainty is deathly and people's enthusiasm and momentum drip away.
Make announcements somewhere public and easily findable that say something about the current state of your project, e.g., about whether it's ready to use or when to expect it to be. This could even just be someplace prominent in your README when you're just getting started. This is also a good place to mention if you're going to be at any upcoming conferences, so people can connect to you that way.
Especially when it comes to code, docs, and bug/feature/task lists, work in the open from as early as possible, preferably from the start. Treat private work as a special case (sometimes a useful one when it comes to communication with users and with new contributors, as a tidepool incubates growth that can then flow into the ocean).
I am sad, as a FLOSS zealot, to say that you should probably be on the closed-source platform that is GitHub. But yeah, the intake funnel for code and bug contributors is easier on GitHub than on any other platform; unless you are pretty sure you already know who all the people are who will use and improve this software, and they're all happy on GitLab or similar, GitHub is going to get you more and faster contributors.
You are adjacent to or embedded in other programming communities, like the programming language & frameworks you're using. Use the OSI-approved license that the projects you're adjacent to/depending on use, to make reuse easier.
It's never too early to think about governance. As Christie Koehler of Authentic Engine warns, to think about codes of conduct, you also gotta think about governance. (The Contributor Covenant is a popular starting point.) If you can be under the umbrella of a software-related nonprofit, like NumFOCUS, that'll help you make and implement these choices.
Top reading recommendation: Karl Fogel's Producing OSS is basically the bible for this category, and the online version is up-to-date with new advice from this year. If you read Producing OSS cover-to-cover you will be entirely set to start and run your project.
Additionally: Fogel also co-wrote criteria for assessing whether a project "is created and managed in a sustainably open source way". And I recommend my own blog post "How To Improve Bus Factor In Your Open Source Project", the Linux Foundation CII criteria (hat-tip to Benjamin Gilbert), "build your own rockstars" by one of the founders of the Dreamwidth project, and "dreamwidth as vindication of a few cherished theories" by that same founder (especially the section starting "our development environment and how we managed to create a process and culture that's so welcoming").
Obligatory plug: I started Changeset Consulting, which provides targeted project management and release management services for open source projects and the orgs that depend on them. In many ways I am maintainer-as-a-service. If you want to talk more about this work, please reach out!
# 23 May 2016, 10:02AM: Two OSCON Conversations, And A Trip Report Between Them:
Conversation the last night of OSCON, reconstructed from memory:
"So, Neil Young --"
"Man, what a white guy name."
"Are you impugning Neil Young? That man sells organic eggs at the farmer's market in my hometown!"
"Are you sure they're organic? You sure he doesn't just get them from Sysco?"
"Sysco doesn't even sell organic eggs."
"Uh, actually Sysco does sell organic eggs."
"Yeah right. I bet it's, like, orgänic, with an umlaut, so it can get around the FDA rules on calling things 'organic'."
"Yeah, and that's also how they get around the rules on Appellation Contrôlée."
"Anyway, Neil Young has a son who really likes model trains, and so he does model train stuff, and he actually has multiple patents related to model trains."
"Patents? Is he part of the Open Invention Network? Is this a defensive patent portfolio against Big Train?"
"You mean Supertrain?"
In honor of late-night wackiness, I have not actually fact-checked whether Neil Young has any model train patents, or whether he or Sysco sell organic eggs. Caveat lector et caveat emptor.
My last visit to OSCON was in 2011, when I had worked for the Wikimedia Foundation for under a year, and wanted to build and strengthen relationships with the MediaWiki and PHP communities. I remember not feeling very successful, and thinking that this was a conference where executives and engineers (who in many cases are not terribly emotionally passionate about open source) meet to hire, get hired, and sell each other things.
These days, it turns out, OSCON is basically aimed at me! Because I am an executive trying to sell my services (e.g. get hired on an as-needed basis) to engineers and executives who make or depend on open source -- including the passionate ideologues, the burned-out used-to-be-passionate folks, the pragmatists, and all manner of other types. Changeset Consulting was novel, relevant, and interesting to approximately everyone I spoke with. Also, in the intervening five years, I've grown in skill, stature, reputation, and network. So I had something interesting to say, and O'Reilly accepted a talk proposal of mine for the first time. I saw scores of acquaintances, friends, peers, and colleagues in the halls and session rooms this year; I know and am known, which helps me feel at home.
I'm grateful to Audra Montenegro at O'Reilly Media for her speaker support. She worked with O'Reilly to cover my flight plus two hotel nights in Austin, making it possible for me to attend OSCON. She and other O'Reilly folks paid and worked with White Coat Captioning to provide CART (live captions) for my talk, at my request. And I was concerned that talking about inessential weirdnesses and inclusivity in open source upped my risk of harassment, so she arranged for some extra security for me. I'm also grateful to Andy Oram, my session chair, for his careful pre-conference prep (including checking on my pronouns -- she/her, thanks!), and for running a written Q&A session at my request.
I shall carry with me several memories of this OSCON, such as:
- Breaking the no-electronics rule of the quiet room/relaxation lounge (since I was the only one using it) to finish revising my talk and blog about good code review
- Staying with some lovely relatives in the suburbs for a few days and drinking spinach juice with them each morning (my uncle is in charge of making it, and sometimes he adds grape or orange juice, and sometimes something else, and sometimes it's just spinach. It's a surprise. "Every day's a new day," he said to me)
- Helping my high schooler cousin revise a skit, and deploying my stand-up comedy wisdom, e.g., use over-the-top worshipful admiration as a kinder substitute for straight-up mockery
- Being the only person in the pool at the Software Freedom Conservancy party (foolish choice on my part; it was pretty cold)
- Meditating on a loved one during an exercise in Cate Huston's talk on technical interviewing, and feeling the lovingkindness throughout the whole room
- Listening to an enthralling performance by rapper Sammus
- Becoming increasingly convinced that continuous integration/continuous delivery is hitting an inflection point that source control hit several years ago, i.e., soon it will be a must-have for software-making communities and not having it will be embarrassing
- Chatting with OSCON acquaintances in an Austin hotel lobby and being interrupted by a drunk white woman who called me "Mindy Lahiri" (a fictional character from The Mindy Project)
- Opting out of the millimeter-wave scanner at the Austin airport and witnessing a person wearing an EFF shirt not opt out!
But here's a conversation that I particularly find stays with me. I was on the expo floor, talking with an acquaintance, and a stranger joined our conversation. I'll anonymize this recollection and call him Cyclopes.
He heard about the consulting services I offer, which focus on short-term project management and release management for open source projects and for companies that depend on them -- maintainership-as-a-service, in short.
Cyclopes: "Can you come to my company and tell us that the way we're doing deployments is all wrong, and tell them we should do it my way?"
Sumana: "Well, if your company hires me, and I assess how you're doing deployments and I think it's wrong, and I agree with the approach you want, then yes."
Cyclopes: "Great!" [explains his preferred deployment workflow, with justification, and says that it's like bashing his head against a brick wall for him to try to convince the rest of his company to do it]
Sumana: [lightheartedly] "So it sounds like what you really want is more a sockpuppet or an actor! Which might be cheaper!"
Cyclopes: "Hmmmm! You know, that is kind of what I want!"
[we three jest about this]
Sumana: "But, in all seriousness, like, you could go aboveboard with this. You know, you have options -- fraud and deception, or actually trying to persuade the other people in your org .... or, this is a wild guess, have you kind of burned bridges by being really abrasive, and now they won't listen to you?"
Cyclopes: "Yeaaaaaaaaah that might be what's happened."
Sumana: "OK! That totally happens and you weren't the first and you won't be the last."
Cyclopes: "Like, I've sent some pretty flame-y emails."
[acquaintance nods in sad agreement; we are all sinners here]
Sumana: "Oh man, the emails I've sent. I am so embarrassed when I look back. But you can come back from this. You really can. If you demonstrate to those people in your org that you really want to repair those relationships with them, they will respond. Like, if you say to them, 'I know I burned bridges before, I'm sorry about it, can we talk about this problem,' and you actually try to listen to them about what they need and what their context is, what they're worried about and what problems they're trying to solve, they will work with you, so you can figure out something that works for everybody. There's a book about this, about negotiation, that's a really short, quick read, it helped me a lot: Getting to Yes by Fisher and Ury."
Cyclopes: "Let me write this down." [notes book title and author on the back of my business card]
Sumana: "There you go, some free consulting for you. It's totally possible."
Cyclopes: "I think I could use that, I'm ripe for that kind of personal transformation in my life."
Sumana: "Great! Please, seriously, let me know how it works out."
Memory is unreliable, but I cannot forget the speed of my diagnosis, nor that this guy literally said that he was ripe for the kind of personal transformation I was prescribing. It's no model train patent but I think I'm happy anyway.
# 21 Mar 2016, 04:58PM: What Is Maintainership?:
Yesterday, at my first LibrePlanet conference, I delivered a somewhat impromptu five-minute lightning talk, "What is maintainership? Or, approaches to filling management skill gaps in free software". I spoke without a script, and what follows is what I meant to say; I hope it bears a strong resemblance to what I actually said. I do not know whether any video of this session will appear online; if it does, I'll update this entry.
What is Maintainership?
Or, approaches to filling management skill gaps in free software
Sumana Harihareswara, Changeset Consulting
LibrePlanet, Cambridge, MA, 20 March 2016
Why do we have maintainers in free software projects? There are various different explanations you can use, and they affect how you do the job of maintainer, how you treat maintainers, how and whether you recruit and mentor them, and so on.
So here are three -- they aren't the only ways people think about maintainership, but these are three I have noticed, and I have given them alliterative names to make it easier to think about and remember them.
Sad: This is a narrative where even having maintainers is, fundamentally, an admission of failure. Jefferson said a lot of BS, but one thing he said that wasn't was: "If men were angels, we would have no need of government." And if every contributor contributed equally to bug triage, release management, communication, and so on, then we wouldn't need to delegate that responsibility to someone, to a maintainer. But it's not like that, so we do. It's an approach to preventing the Tragedy of the Commons.
I am not saying that this approach is wrong. It's totally legitimate if this is how you are thinking about maintainership. But it's going to affect how your community does it, so, just be aware.
Skill: This approach says, well, people want to grow their skills. This is really natural. People want to get better, they want to achieve mastery, and they want validation of their mastery, they want other people to respect their mastery. And the skill of being a maintainer, it's a skill, or a set of skills, around release management, communication, writing, leadership, and so on. And if it's a skill, then you can learn it. We can mentor new maintainers, teach them the skills they need.
So in this approach, people might have ambition to be maintainers. And ambition is not a dirty word. As Dr. Anna Fels puts it in her book Necessary Dreams, ambition is the combination of the urge to achieve mastery of some domain and the desire to have your peers, or people you admire, acknowledge, recognize, validate your mastery.
With this skills approach, we say, yeah, it's natural that some people have ambition to get better as developers and also to get better at the skills involved in being a maintainer, and we create pathways for that.
Sustain: OK, now we're talking about the economics of free software, how it gets sustained. If we're talking about economics, then we're talking about suppply and demand. And I believe that, in free software right now, there is an oversupply of developers who want to write feature code, relative to an undersupply of people with the temperament and skills and desire to do everything else that needs doing, to get free software polished and usable and delivered and making a difference. This is because of a lot of factors, who we've kept out and who got drawn into the community over the years, but anyway, it means we don't have enough people who currently have the skill and interest and time to do tasks that maintainers do.
But we have all these companies, right? Companies that depend on, that are built on free software infrastructure. How can those with more money than time help solve this problem?
[insert Changeset Consulting plug here]. You can hire my firm, Changeset Consulting, to do these tasks for a free software project you care about. Changeset Consulting can do bug triage, doc rewriting, user experience research, contributor outreach, release management, customer service, and basically all the tasks involved in maintainership except for the writing and reviewing of feature code, which is what those core developers want to be doing anyway. It's maintainer-as-a-service.
Of course you don't have to hire me. But it is worth thinking about what needs to be done, and disaggregating it and seeing what bits companies can pay for, to help sustain the free software ecology they depend on.
So: sad, skill, sustain. I hope thinking about what approach you are taking helps your project think about maintainership, and what it needs to do to make the biggest long-term impact on software freedom. Thank you.
# 23 Feb 2016, 04:00PM: Leadership Crisis at the Wikimedia Foundation:
This week, the Wikimedia Foundation, the main organization supporting Wikipedia and several other free knowledge projects, is at the peak of a leadership crisis more than a year in the making. Molly White's timeline of the crisis is a useful guide to the facts, and I feel compelled to speak publicly for the first time about the problem, and share my personal perspective, with a bit of context to help non-Wikimedians understand.
I left the Wikimedia Foundation in September 2014 after four years. I mentioned the reasons then, in that post, around learning new things and working on projects with less of a public spotlight. I'm happy with my new direction, Changeset Consulting LLC, but still have so many fond memories of working with fantastic people and making a difference.
I left WMF thinking that it was fine -- in fact, that's a reason I felt okay about deciding to leave a place I cared about so much, because I thought WMF could cope without me. As I perceived it, former Executive Director (nonprofit-speak for "CEO" basically) Sue Gardner had led the organization to a stable enough place that she felt free to move on. For years, when I was at Wikimedia Foundation, our top priority was reversing the decline in the number of active Wikipedia contributors and other Wikimedia contributors; Sue Gardner articulated this priority and ensured everyone knew what we were aiming at and why. Lila Tretikov, the new executive director, was settling in and I perceived WMF to be on the right track, iteratively moving closer to reversing the editor decline, with solid management and plans in place to keep positive momentum going. I thought the conflicts and stumbles from summer 2014 were normal temporary pains, not unusually worrying.
A few months after I left, when I caught up with old Foundation colleagues, I started hearing wariness about the new high-level management (the ED and some other newer executive hires). The worries progressed into stronger and stronger concerns, getting more and more disturbing. For instance, in November 2015, a committee that disseminates Wikimedia funds to budget other Wikimedia institutions (such as chapters) wrote a scathing critique:
...the [Funds Dissemination Committee] laments that the Wikimedia Foundation's own planning process does not meet the minimum standards of transparency and planning detail that it requires of affiliates applying for its own Annual Plan Grant (APG) process....
The FDC is appalled by the closed way that the WMF has undertaken both strategic and annual planning, and the WMF's approach to budget transparency (or lack thereof).
I nearly could not believe my eyes when I saw this. For those of you who don't follow these bureaucracies, let me assure you that the FDC does not throw around words like "appalled" lightly. (Followup on the FDC recommendations.)
Early this year, it became public knowledge that the conflicts within the Foundation had led to an employee survey with a 93% response rate. The results included:
I have confidence in senior leadership at Wikimedia: 10% agree
It is a miracle if 90% of Wikimedia Foundation personnel agree on anything beyond the fact that WMF's commitment is to "a world in which every single human being can freely share in the sum of all knowledge." And to be clear, "confidence in senior leadership" here means that the employees trust that the C-level executives have the basic competence to run the organization. This isn't about agreeing or disagreeing on particular choices of method; when I was at WMF, the Executive Director and the Chief ____ Officers made decisions that some employees disagreed with, but they explained their reasoning, they encouraged feedback and responded to it (example), and we fundamentally knew they were aiming to collaborate with us in achieving the mission. It sounds like some big pieces of that trust are now missing.
1. In late December the Board of Trustees dismissed a well-liked community-elected trustee, Dr. James Heilman, for reasons that remain somewhat mysterious...
3. Revelations about newly appointed Board trustee Arnnon Geshuri's involvement in an illegal anti-poaching scheme while at Google has drawn community outcry
4. Besides failing to vet Geshuri, the WMF's increasing tilt toward the Silicon Valley and focus on (perhaps) the wrong technology projects have come into sharper relief
So, Arnnon Geshuri. You know that scandal where it came to light that big Silicon Valley tech firms were colluding to suppress wages and reduce employee mobility with illegal "no-poaching" agreements? With evidence including super damning emails? Guess who sent some of that email, perpetuating that pact? Arnnon Geshuri. The WMF Board of Trustees appointed him as one of the trustees. He's since stepped down but the incident damaged already-shaky trust between the Board and the larger Wikimedia community.
And as of last week it's clear that the situation's gotten even more dire. Fantastic colleagues are voting with their feet and leaving (and do you know how hard it is to find and hire the right people for an org this weird and this important?). People who would rather walk with rocks in their shoes than throw their coworkers under the bus are compelled to speak in public about dysfunction at the top: Ori Livneh, Anna Stillwell, and Greg Grossmeier, for instance, and Brion Vibber, who was the first employee the Foundation ever hired. Faidon Liambotis, Principal Operations Engineer at the Foundation & a longtime Debian Developer. Gayle Karen Young, former WMF Chief Talent & Culture Officer, who has a world-class ability to fuse compassion and systems-level thinking in the management of people processes, writes publicly about "dysfunction at the top" and "the enormous toll" it's taking on the staff. Erik Möller, who served on the Board of Trustees before he served as WMF second-in-command for more than seven years and then left in April 2015, a guy who has seen a thousand Wikimedia thunderstorms come and go and could probably charge for calm-as-a-service, says that "the situation is very much out of control" and "this is a crisis". This is not just the ordinary grumblings of a transparent organization. This is dire.
Executive Director Lila Tretikov said on Monday that Wikimedia has now managed to stem the editor decline. Möller replies and asks: is that so? and reviews the current stats, which do not reflect this claim.
But overall, it seems premature of speaking of "stemming the decline", unless I'm missing something (entirely possible).
There have been a thousand thunderstorms before. The Image Filter, SOPA, the transition from Toolserver to Tool Labs, Narrowing Focus, paid editing, the first VisualEditor rollout, the India Education Program, I could keep going and the point is that we Wikimedians have big ideas and big passionate arguments and we know some things about how to get through them. The movement, thank goodness, is bigger than the Foundation. The volunteers, the chapter staff, the teachers and photographers and coders and editors and everyone in the hundreds of subcommunities in our ecology have some buffers against the ripples coming out of the Foundation. There's frustration, sometimes, in how hard it can be for one subcommunity or organization to persuade or lend a hand to another, but right now it's a good thing because there is short-term resilience in that loosely federated structure.
This has been a singularly destructive time, but we still have time to keep the leadership problem from further damaging the Wikimedia movement.
As I said back in September 2014,
One of the things I admire about Wikimedia's best institutions is our willingness to reflect and reinvent when things are not working.
I don't know what the answer is.
The choice between exit and voice is conditioned on loyalty. We know that Wikimedians have been exercising the "voice" option; the Board and the ED have heard these criticisms loud and clear. And we know they've witnessed the stream of talented employees exiting, their steel-clad loyalty finally succumbing to the pressure. If unaltered, this is the kind of dynamic that leads to schisms and forks. I would hate for the movement to have to pay that kind of cost but, unless the Wikimedia Foundation Board of Trustees and Executive Director change course, I think that's a potential outcome.
# 19 Feb 2016, 06:50PM: What Should We Stop Doing? (FLOSS Community Metrics Meeting keynote):
"What should we stop doing?": written version of a keynote address by Sumana Harihareswara, delivered at the FLOSS Community Metrics Meeting just before FOSDEM, 29 January 2016 in Brussels, Belgium. Slide deck is a 14-page PDF. Video is available. The notes I used when I delivered the talk were quite skeletal, so the talk I delivered varied substantially on the sentence level, but covered all the same points.
I'd like to start with a story, about my excellent boss I worked for when I was at the Wikimedia Foundation, Rob Lanphier, and what he told me when I'd been on the job about eight months. In one of our one-on-one meetings, I mentioned to him that I felt overwhelmed. And first, he told me that I'd been on the job less than a year, and it takes a year to ramp up fully in that job, so I shouldn't be too worried. And then he reminded me that we were in an amazing position, that we would hear and get all kinds of great ideas, but that in order to get anything done, we would have to focus. We'd have to learn to say, "That's a great idea, and we're not doing it." And say it often. And, he reminded me, I felt overwhelmed because I actually had the power to make choices, about what I did with my time, that would affect a lot of people. I was not just cog # 15,000 doing a super specialized task at Apple.
So today I want to talk with you about how to use the power you have, in your open source projects and organizations, and about saying no to a lot of things, so you can focus on doing fewer things well -- the Unix philosophy, right? I'll talk about a few tools and leave you with some questions.
Tool 1: Remember to say no to the lamppost fallacy
The lamppost fallacy is an old one, and the story goes that a drunk guy says, "I dropped my keys, will you help me look for them?" "OK, sure. Where'd you drop them?" "Under that tree." "So why are you looking for them under this lamppost?" "Well, the light is better here."
A. Quantitative vs qualitative in the dev data
The first place we ought to check for the lamppost fallacy is in overvaluing quantitative metrics over qualitative analysis when looking at developer workflow and experience. Dave Neary said, in the FLOSSMetrics meeting in 2014, in "What you measure is what you get. Stories of metrics gone wrong": Use qualitative and quantitative analysis to interpret metrics.
When it comes to developer experience, you can be analytical while both quantitative and qualitative. And you rather have to be, because as soon as you start uncovering numbers, you start asking why they are what they are and what could be done to change that, and that's where the qualitative analytical approach comes in.
Qualitative is still analytical! Camille Fournier's post, "Qualitative or quantitative but always analytical", goes into this:
qualitative is still analytical. You may not be able to use data-driven reasoning because you're starting something new, and there are no numbers. It is hard to do quantitative analysis without data, and new things only have secondary data about potential and markets, they do not have primary data about the actual user engagement with the unbuilt product that you can measure. Furthermore, even when the thing is released, you probably have nothing but "small" data for a while. If you only have a thousand people engaging with something, it is hard to do interesting and statistically significant A/B tests unless you change things drastically and cause massive behavioral changes.
This is applicable to developer experience as well!
For help, I recommend the Wikimedia movement's Grants Evaluation & Learning team's table discussing quantitative and qualitative approaches you can take: ethnography, case studies, participant observation, and so on. To deepen understanding. It's complementary with the quantitative side, which is about generalizing findings.
B. Quantifiable dev artifacts-and-process data versus data about everything else
Another place to check for the lamppost fallacy is in overvaluing quantifiable data about programming artifacts and process over all sorts of data about everything else that matters about your project. Earlier today, Jesus González-Barahona mentioned the many communities -- dev, contributor, user, larger ecosystem -- that you might want to research. There's lots of easily quantifiable data about development, yes, but what is actually important to your project? Dev, user, sysadmin, larger ecology -- all of these might be, honestly, more important to the success of your mission. And we also know some things about how to get better at getting user data.
For help, I recommend the Simply Secure guides on doing qualitative UX research, such as seeing how users are using your product/application. And I recommend you read existing research on software engineering, like the findings in Making Software: What Really Works and Why We Believe It, the O'Reilly book edited by Andy Oram and Greg Wilson.
Tool 2: know what kind of assessment you're trying to do and how it plays into your theory of change
Another really important tool that will help you say no to some things and yes to others is knowing what kind of assessment you're trying to make, and how that plays into your hypothesis, your theory of change.
I'm going to mess this up compared to a serious education researcher, but it's worth knowing the basics of the difference between formative and summative assessments.
Formative assessment or evaluation is diagnostic, and you should use it iteratively to make better decisions to help students learn with better instruction & processes.
Summative assessment is checking outcomes at the conclusion of an exercise or a course, often for accountability, and judging the worth/value of that educational intervention. In our context as open source community managers, this often means that this data is used to persuade bosses & community that we're doing a good job or that someone else is doing a bad job.
As Dawn Foster last year said in her "Your Metrics Strategy" speech at the FLOSSMetrics meeting:
METRICS ARE USEFUL Measure progress, spot trends and recognize contributors.
Start with goals: WHY FOCUS ON GOALS? Avoid a mess: measure the right things, encourage good behavior.
Here's Ioana Chiorean, FLOSS Community Metrics meeting, January 30th 2015, "How metrics motivate":
Measure the right things... specific goals that will contribute to your organization's success
Dave Neary in 2014 in "What you measure is what you get. Stories of metrics gone wrong" at the Metrics meeting said:
be careful what you measure: metrics create incentives
Focus on business and community's success measurements
And this is tough. Because it can be hard to really make a space for truly formative assessment, especially if you are doing everything transparently, because as soon as you gather and publish any data, people will use it to argue that we ought to make drastic changes, not just iterative changes. But it might help to remember what you are truly aiming at, what kind of evaluation you really mean to be doing.
And it helps a lot to know your Theory of Change. You have an assessment of the way the world is, a vision of how you want the world to look, and a hypothesis about some change you could make, an activity or intervention you could perform to move us closer from A to B.
There's a chicken and egg problem here. How do you form the hypothesis without doing some initial measurement? And my perhaps subversive answer is, use ideas from other communities and research to create a hypothesis, and then set up some experiments to check it. Or go with your gut, your instinct about what the hypothesis is, and be ready to discard it if the data does not bear it out.
For help: Check out educational psychology, such as cognitive apprenticeship theory - Mel Chua's presentation here gives you the basics. You might also check out the Program/Grant Learning & Evaluation findings from Wikimedia, and try out how the "pirate metrics" funnel -- Acquisition, Activation, Retention, Referral, Revenue, or AARRR -- fits with your community's needs and bottlenecks.
Tool 3: if something doesn't work, acknowledge it
And the third tool is that when we see data saying that something does not work, we need to have the courage to acknowledge what the data is saying. You can move the goalposts, or you can say no and cause some temporary pain. We have to be willing to take bug reports.
Here's an example. The Wikimedia movement likes to host editathons, where a bunch of people get together and learn to edit Wikipedia together. We hoped that would be a way to train and retain new editors. But Wikipedia editathons don't produce new long-term editors. We learned:
About 52% of participants identified as new users made at least one edit one month after their event, but the percentage editing dropped to 15% in the sixth months after their event
And, in "What we learned from the English Wikipedia new editor pilot in the Philippines":
Inviting contribution by surfacing geo-targeted article stubs was not enough to motivate or help users to make their first edits to an article. Together, all new editors who joined made only six edits in total to the article space during this experiment, and they made no edits to the articles we suggested.
Providing suggestions via links to places users might go for help did not appear to sufficiently support or motivate these new editors to get involved. 50 percent of those surveyed later said they didn’t look for help pages. Those who did view help pages nevertheless did not edit the suggested articles.
But over and over in the Wikimedia movement I see that we keep hosting those one-off editathons. And they do work to, for instance, add new high-quality content about the topics they focus on, and some people really like them as parties and morale boosters, and I've heard the argument that they at least get a lot of people through that first step, of creating an account and making their first edit. But that does not mean that they're things we should be spending time on, to reverse the editor decline trend. We need to be honest about that.
It can be hard to give up things we like doing, things we think are good ideas and that ought to work. As an example: I am very much in favor of mentorship and apprenticeship programs in open source, like Google Summer of Code and Outreachy. Recently some researchers, Adriaan Labuschagne and Reid Holmes, raised questions about mentorship programs in "Do Onboarding Programs Work?", published in 2015, about whether these kinds of mentorship programs move the needle enough in the long run, to bring new contributors in. It's not conclusive, but there are questions. And I need to pay attention to that kind of research and be willing to change my recommendations based on what actually works.
We can run into cognitive dissonance if we realize that we did something that wasn't actually effective. Why did I do this thing? why did we do this thing? There's an urge to rationalize it. The Wikimedia FailFest & Learning Pattern hackathon 2015 recommends that we try framing our stories about our past mistakes to avoid that temptation.
Big 'F' failure framing:
- We planned this thing: __________________________
- This is how we knew it wasn't working: __________________________
- There might have been some issues with our assumption that: __________________________
- If we tried it again, we might change: __________________________
Little 'f' failure framing:
- We planned this thing: __________________________
- This is how we knew it wasn't working: __________________________
- We think that this went wrong: __________________________
- Here is how to fix it: __________________________
For help with this tool, I suggest reading existing research evaluating what works in FLOSS and open culture, like "Measuring Engagement: Recommendations from Audit and Analytics" by David Eaves, Adam Lofting, Pierros Papadeas, Peter Loewen of Mozilla.
I have a much larger question to leave you with.
One trend I see underlying a big chunk of FLOSS metrics work is the desire to automate the emotional labor involved in maintainership, like figuring out how our fellow contributors are doing, making choices about where to spend mentorship time, and tracking a community's emotional tenor. But is that appropriate? What if we switched our assumptions around and used our metrics to figure out what we're spending time on more generally, and tried to find low-value programming work we could stop doing? What tools would support this, and what scenarios could play out?
This is a huge question and I have barely scratched the surface, but I would love to hear your thoughts. Thank you.
Sumana Harihareswara, Changeset Consulting
# 09 Aug 2015, 10:52PM: How To Improve Bus Factor In Your Open Source Project:
Someone in one of my communities was wondering whether we ought to build a new automated tool to give little tasks to newcomers and thus help them turn into future maintainers. I have edited my replies to him into the How To Build Bus Factor For Your Open Source Project explanation below.
In my experience (I was an open source community manager for several years and am deeply embedded in the community of people who do open source outreach), getting people into the funnel for your project as first-time contributors is a reasonably well-solved problem, i.e., we know what works. Showing up at OpenHatch events, making sure the bugs in the bug tracker are well-specified, setting up a "good for first-timers" task tag and/or webpage and keeping it updated, personally inviting people who have reported bugs to help you solve them, etc. If you can invest several months of one-on-one or two-on-one mentorship time, participate in Google Summer of Code and/or Outreachy internship programs. If you want to start with something that's quantitative and gamified, consider using Google Code-In as a scaffold to help you develop the rest of these practices.
You need to quickly thank and give useful feedback to people who are already contributing, even if that feedback will include criticism. A fast first review is key, and here's a study that backs that up. Slide 8: "Most significant barrier to engaging in onramping others is unclear communications and unfriendly community. Access to the right tools has some effect." Slide 26:
"Contributors who received code reviews within 48 hours on their first bug have an exceptionally high rate of returning and contributing. (And "Github, transparency, and the OTW Archive project" discusses how bad-to-nonexistent code review and bad release management led to a volunteer dropping out of a different open source project.)
Contributors who wait longer than 7 days for code review on their first bug have virtually zero percent likelihood of returning.
Showing a contributor the next bug they can work on dramatically improves the odds of contributing."
In my opinion, building bus factor for your project (growing new maintainers for the future) is also a solved problem, in that we know what works. You show up. You go to the unfashionable parts of our world where the cognitive surplus is -- community colleges, second- and third-tier four-year colleges, second- and third-tier tech hubs, boring enterprise companies. You review code and bug reports quickly, you think of every contributor (of any sort) as a potential co-maintainer, and you make friendly overtures to them and offer to mentor them. You follow OpenHatch's recommendations. You participate in Google Summer of Code and/or Outreachy internship programs.
Mentorship is a make-or-break step here. This is a key reason projects participate in internship programs like GSoC and Outreachy. For example, Angela Byron was a community college student who had never gotten involved in open source before, and then heard about GSoC. She thought "well it's an internship for students, it'll be okay if I make mistakes". That's how she got into Drupal. She's now a key Drupal maintainer.
Dreamwidth, an open source project, started with two maintainers. They specifically decided to make the hard decision to slow down on feature development, early on, and instead pay off technical debt and teach newcomers. Now they are a thriving, multimaintainer project. "dreamwidth as vindication of a few cherished theories" is perhaps one of my favorite pieces on how Dreamwidth did what it did. Also see "Teaching People to Fish" and this conference report.
Maintainers must review code, and that means that if you want someone to turn into a maintainer in your project, you must help them learn the skill of code review and you must help them get confident about vetoing and merging code. In my experience, yes, a good automated test suite does help people get more confident about merging changes in. But maintainers also need to teach candidates what their standards ought to be, and encourage them (many contributors' first thought when someone says "would you want to comaintain this project with me?" is "what? me? no! I'm not good enough!"). Here's a rough example training.
If you want more detailed ways to think about useful approaches and statistics, I recommend Mel Chua's intro to education psychology for hackers and several relevant chapters in Making Software: What Really Works and Why We Believe It, from O'Reilly, edited by Greg Wilson & Andy Oram. You'll be able to use OpenHub (formerly Ohloh) for basic stats/metrics on your open source project, including numbers of recent contributors. And if you want more statistics for your own project or for FLOSS in aggregate, the open source metrics working group would also be a good place to chat about this, to get a better sense of what's out there (in terms of dashboards and stats) and what's needed. (Since then: also see this post by Dawn Foster.)
We know how to do this. Open source projects that do it, that are patient with the human factor, do better, in the long run.
# (1) 25 Dec 2014, 12:48AM: Good And Bad Signs For Community Change, And Some Leadership Styles:
So let's assume you want to improve a particular community, and you've already read my earlier pieces, which I am now declaring prerequisites: "Why You Have To Fix Governance To Improve Hospitality", "Hospitality, Jerks, and What I Learned", and "Learn Tech Management in 45 Minutes" (all the way through the Q&A). And let's assume that you care about the community having a good pathway to inclusion, and that the community is caring or collaborative, rather than cordial, competitive, or combative.
When I look at an open stuff community, here are some factors that
make me optimistic:
- people with social capital in the project, whom other participants respect, support my goals in private conversation
- even better: such people have reached out to me, of their own
initiative, about it
- even better than that: such people are already taking real action
- I have personal relationships with at least one influential project leader
- I am in the private spaces where project leaders talk
- either the project's still new and the norms are in flux, or there's a new initiative or subcommunity where I can influence norms or even amend the rules of the game before they jell and harden
- the founder of the project exercises charismatic/inertial authority and either does not support my goals, or is too afraid of conflict to take real action
- per Selena Deckelmann's advice, "If someone is treating you with contempt, or you are using contempt in arguments, that's a big warning sign."
- there is a private space where important conversation happens and I'm not invited
- I, or someone else who shares my goals, has been unsuccessful in
getting the community to do something small towards my goals. For instance, assuming my goal is improving gender diversity in a male-dominated workplace, I haven't been able to get them to adopt a first code of conduct, or improve a CoC to have real enforcement provisions, or participate in a women-centric job fair, or make a token effort towards diversity in guest speakers.
- not just the rules of the game, but the dominant worldview, and perhaps the major actors, haven't changed in, say, more than three years
To achieve change in this kind of situation, you have to have enough social skills to be able to make relationships, to notice whether contempt has made an appearance, to grok the subtle stuff. A systems approach (leader as engineer) will get you part of the analysis and part of the solution; you also need relatedness (leader as mother). Requisite variety. In the face of a problem, some people reflexively reach more for "make a process that scales" and some for "have a conversation with ____"; perhaps this is the defining difference between introverts and extroverts, or maybe between geeks and nongeeks, in the workplace.* We need both, of course - scale and empathy.
A huge part of my job for the last four years was struggling with the question: how do you inculcate empathy in others, at scale, remotely? How do you you balance genuine openness to new people, including people who think very differently from you, with the need for norms and governance and, at times, exclusion?
Huh, I wonder whether this is the first blog entry I've ever tagged both with "Management and Leadership" and "Religion".
# (1) 21 Dec 2014, 11:10PM: Why You Have To Fix Governance To Improve Hospitality:
Fundamentally, if you want to make a community hospitable,* you need to work not just on individual rules of conduct, but on governance. This is because
- the particular people implementing rules of conduct will use their judgment in when, whether, and how to apply those rules, and
- you may need to go a few levels up and change not just who's implementing rules, but who's allowed to make rules in the first place
Wait, how does that work?
In my Wiki Conference 2014 keynote address (available in text, audio, and video), and in my PyCon 2014 poster about Hacker School, I discuss how to make your community hospitable. In those pieces I also mention how the gatekeeping (there is an initiation/selection process) and the paid labor of community managers (the facilitators) at Hacker School help prevent or mitigate bad behavior. And, of course, the Hacker School user manual is the canonical document about what is desired and prohibited at Hacker School; "Subtle -isms at Hacker School" and "Negative comments" have more ruminations on how certain kinds of negativity create a bad learning environment.
Sometimes it's the little stuff, more subtle than the booth babe/groping/assault/slur kind of stuff, that makes a community feel inhospitable to me. When I say "little stuff" I am trying to describe the small ways people marginalize each other but that I did not experience at Hacker School and thus that I noticed more after my sabbatical at Hacker School: dominance displays, cruelty in the guise of honesty, the use of power in inhospitable ways, feeling unvalued, "jokes", clubbiness, watching my every public action for ungenerous interpretation, nitpicking, and bad faith.
You can try to make rules about how things ought to be, about what is allowed and not, but members of the incumbent/dominant group are less accustomed to monitoring their own behavior, as the Onlinesmanship wiki (for community moderators) reminds us:
Another pattern of the privileged: not keeping track of the line between acceptable and unacceptable behavior. They only know they've crossed the line when someone in authority tells them so. If this doesn't happen, their behavior stays bad or gets worse....
Do not argue about their intentions. They'll swear they meant no harm, then sulk like fury because you even suggested it. In most cases they'll be telling the truth: the possibility that they were giving offense never crossed their minds. Neither did any other scenario, because unlike real adults, they take no responsibility for getting along with others. The idea that in a cooperative work situation, getting along with one's fellow employees is part of the job, is not in their worldview.
This too is a function of privilege. They assume they won't get hit with full penalties for their first offense (or half-dozen offenses), and that other people will always take on the work of tracking their behavior, warning them when they go over the line, and explaining over and over again what they should have done and why. It's the flip side of the way people of the marked state get hit with premature negative judgements (stupid, dishonest, sneaky, hysterically oversensitive) on the basis of little or no evidence.
And, in any community, rules often get much more leniently interpreted for members of the dominant group. And this is even harder to fight against when influential people believe that no marginalization is taking place; as Abi Sutherland articulates: "The problem with being lower on an unstated social hierarchy is that marginal judgment calls will
reliably go against you. It's an excusable form of reinforcement."**
Changing individual rules isn't enough. After all, individual rules get made by particular humans, who -- here, instead of babbling about social rule system theory at you, I'll give you a sort of sidebar about three successive levels of governance, courtesy of my bachelor's degree in political science:***
- Actors: The actual set of people who run an organization or who shape agendas, on any given day, have particular ideas and policies and try to get certain things done. They implement and set and change regulations. Actors turn over pretty fast.
- For example, in its five-year history, Hacker School has had employees come and go, and new participants have become influential alumni.
- Dominant worldviews: More deeply and less ephemerally, the general worldview of the group of people who have power and influence (e.g., Democrats in the executive branch of the US government, sexists in mass media, surgeons in operating rooms, deletionists on English Wikipedia) determines what's desirable and what's possible in the long term. Churn is slower on this level.
- For example, dominant worldviews among Hacker Schoolers**** include: diversity of Hacker Schoolers, on several axes, helps everyone learn more. Hiding your work, impostor syndrome, too much task-switching, and the extrinsic motivation of job-hunting are common problems that reduce the chances of Hacker Schoolers' success. Careers in the tech industry are, on balance, desirable.
- Rules of the game: What is sacred? What is so core to our identity, our values, that breaking one of these means you're not one of us? The rules of the game (e.g., how we choose leaders, what the rulers' jurisdiction is) confer legitimacy on the whole process. Breaking these rules is heresy and amending them is very hard and controversial.***** Publicly disagreeing with the rules of the game costs lots of political capital.
- For example, the rules of the game among Hacker Schoolers, as I see them, include: the founders of Hacker School and their employees have legitimate authority over admissions, hiring, and rule enforcement. Hacker School is (moneywise) free to attend. Admission is selective. A well-designed environment that helps people do the right thing automatically is better than one-on-one persuasion, which is still better than coercion.
(Where do the four Hacker School social rules fall in this framework? I don't know. Hacker School's founders encourage an experimental spirit, and I think they would rather stay fluid than accrete more and more sacred texts. But, as more and more participants have experienced a Hacker School with the four social rules as currently constituted, I bet a ton of my peers perceive the social rules as DNA at this point, inherent and permanent. I'm not far from that myself.)
(I regret that I don't have the citation to hand, and would welcome the name of the theorists who created this model.)
So, if you want a hospitable community, it's not enough to set up a code of conduct; a CoC can't substitute for culture. Assuming you're working with a pre-existing condition, you have to assess the existing power structures and see where you have leverage, so you can articulate and advocate new worldviews, and maybe even move to amend the rules of the game.
How do you start? This post has already gotten huge, so, I'll talk about that next time.
* I assume that we can't optimize every community or activity for hospitality and learning. Every collaborative effort has to balance execution and alignment; once in a while, people who have already attained mastery of skill x just need to mind-meld to get something done. But if we want to attract, retain, and grow people, we need to always consider the pathway to inclusion. And that means, when we accept behavior or norms that make it harder for people to learn, we should know that we're doing it, and ask whether that's what we want. We should check.
**See the second half of "One Way Confidence Will Look" for more on the unwillingness to see bias.
*** I am quite grateful for my political science background -- not least because I learned that socially constructed things are real too, which many computer science-focused people in my field seem to have missed, which means they can't mod or make new social constructs as easily. Requisite variety.
**** A non-comprehensive list, of course. And I don't feel equal to the more nuanced question: what beliefs do the most influential Hacker Schoolers hold, especially on topics where their worldview is substantially different from their peers'?
***** The US has a very demanding procedure for amending the Constitution. India doesn't. The US has had 27 amendments in 227 years; India, 98 in 67 years. I don't know how to interpret that.
# 28 Nov 2014, 06:48PM GMT+5:30: Normal's Just A Setting On The Dryer:
(Title from some lost-to-the-ages sage, I think.)
I recently said to a friend that I'm pretty on-board with "Labels are for mailing things" and "Normal's just a setting on the dryer" (also said as "Normal: of or pertaining to someone named Norm"). I also shy away from calling things "real", from using the minimizing adverb "just", from saying that "everyone" does or is or doesn't or isn't something.
Today I was thinking about the assumptions that US children of immigrants make, about the fact that we know that "normal" is relative. When I'm in Mysore, it's as normal to sidestep cow poop on the road as it is to avoid clicking on phishing links in my email.
Evidence is mounting that several people consider me a role model and a leader. (And yes if you thought "that must be something Sumana is resistant to acknowledging, to herself or publicly" then you are accurate in your predictions!) So I'm mulling that. Role models demonstrate that something is possible, for, lo, here is an existence proof. And leaders get to influence perceptions of what's normal, and what's bullshit.
# 08 Oct 2014, 08:01AM: How I made a tidepool: Implementing the Friendly Space Policy for Wikimedia Foundation technical events:
Back when I worked at the Wikimedia Foundation, I used the Ada Initiative's anti-harassment policy as a template and turned it into the Friendly Space Policy covering tech events run by WMF. I offer you this case study because I think reading about the social and logistical work involved might be inspiring and edifying, and to ask you to please donate to the Ada Initiative today.
I was working for Wikimedia Foundation for ~8 months before I broached the topic of a conference anti-harassment policy with the higher-ups - my boss & my boss's boss, both of whom liked the idea and backed me 100%. (I did not actually ask HR, although in retrospect I could have.) My bosses both knew that Not So Great things happen at conferences and they saw why I wanted this. They said they'd have my back if I got any flak.
So I borrowed the Ada Initiative's policy and modified it a little for our needs, and placed my draft on a subpage of my user page on our wiki. Then I briefly announced it to the mailing list where my open source community, MediaWiki, talks. I specifically framed this as not a big deal and something that lots of conferences were doing, and said I wanted to get it in place in time for the hackathon later that month. Approximately everyone in our dev community said "sure" or "could this be even broader?" or "this is a great idea", as you can see in that thread and in the wiki page's history and the talk page.
I usually telecommuted to WMF, but I happened to be in San Francisco in preparation for the hackathon, and was able to speak to colleagues in person. My colleague Dana Isokawa pointed out that the phrasing "Anti-harassment policy" was offputting. I agreed with her that I'd prefer something more positive, and I asked some colleagues for suggestions on renaming it. My colleague Heather Walls suggested "Friendly Space Policy". In a pre-hackathon prep meeting, I mentioned the new policy and asked whether people liked the name "Friendly Space Policy," and everyone liked it.
So I made it an official Policy; I announced it to our developer community and I put it on wikimediafoundation.org.
This might have been the end of it. But a day later, I saw a question from one community member on the more general community-wide mailing list that includes other Wikimedia contributors (editors/uploaders/etc.). That person, who had seen but not commented on the discussion on the wiki or on the developers' list, wanted to slow down adoption and proposed some red tape: a requirement that this policy be passed by a resolution of the Wikimedia Foundation's Board of Trustees (so, basically, the ultimate authority on the topic).
But approximately everyone on the community-wide list also thought the policy was fine -- both volunteers and paid WMF staffers. For instance, one colleague said:
"If a policy makes good sense, we clearly need it, and feedback about the text is mostly positive, then we should adopt it. Rejecting a good idea because of process wonkery is stupid.
Sumana is not declaring that she gets to force arbitrary rules on everyone whenever she wants. She is solving a problem for us."
My boss's boss also defended the policy, as did a member of the Board of Trustees.
"Perhaps you misread the width of this policy. Staff can and generally do set policies affecting WMF-run processes and events."
I didn't even have to respond on-list since all these other guys (yes, nearly all or all guys) did my work for me.
I was so happy to receive deep and wide support, and to help strengthen the legitimacy of this particular kind of governance decision: consensus, including volunteers, led by a particular WMF staffer. And, even though I had only proposed it for a particularly limited set of events (Wikimedia-sponsored face-to-face technical events), the idea spread to other affiliated organizations (such as Wikimedia UK) and offline events (Wikimania, our flagship conference -- thank you, Sarah Stierch, for your work on that!). And the next year, a volunteer led a session at Wikimania to discuss a potential online Friendly Space Policy:
"Explore what elements are essential for you in such a policy and what we can do collectively to adopt such a policy for Wikipedia and other Wikimedia websites."
So perhaps someday, all Wikipedia editors and other Wikimedia contributors will enjoy a safer environment, online as well as offline! I feel warm and joyous that the discussion I launched had, and is having, ripple effects. I felt like I took a gamble, and I looked back to see why it worked. A few reasons:
- The Ada Initiative's template. I cannot imagine writing something that good from scratch. Having that template to customize for our needs made this gamble possible at all.
- I started the discussion in January 2012; I had joined Wikimedia Foundation (part-time) in March 2011. So I had already built up a bunch of community cred and social capital.
- In early 2012, open source citizens saw more and more reports of hostile behavior at conferences; people saw the need for a policy.
- I added "or preferred Creative Commons license" to the big list of attributes (gender, disability, etc.), which gave the document a touch of Wikimedia-specific wit right at the start of the policy.
- I balanced decisiveness and leadership with openness to others' ideas.
- Honestly, I narrowly focused the policy to an area where my opinion carried weight and I held some legitimate authority (both earned and given), phrased my announcement nonchalantly and confidently, and ran the consensus process pretty transparently. I believe it was hard to disagree without looking like a jerk. ;-)
(If you can privately talk with decisionmakers who have have top-down authority to implement a code of conduct, then you can use another unfortunate tool: point to past incidents that feel close, because they happened to your org or to ones like it.)
By implementing our Friendly Space Policy, I created what I think of as a tidepool:
"...places where certain people can sort of rest and vent and collaborate, and ask the questions they feel afraid of asking in public, so they can gain the strength and confidence to go further out, into the invite-only spaces or the very public spaces....spaces where everybody coming in agrees to follow the same rules so it's a place where you feel safer -- these are like tidepools, places where certain kinds of people and certain kinds of behavior can be nurtured and grown so that it’s ready to go out into the wider ocean."
With the help of the Ada Initiative's policy adoption resources, you can make a place like that too -- and if you feel that you don't have top-down authority, perhaps that no one in your community does, then take heart from my story. If you have a few allies, you don't have to change the ocean. You can make a tidepool, and that's a start.
# (1) 13 Aug 2014, 03:48PM: Case Study of a Good Internship:
I'm currently a mentor for Frances Hocutt's internship in which she evaluates, documents, and improves client libraries for the MediaWiki web API. She'll be finishing up this month.
I wanted to share some things we've done right. This is the most successful I've ever been at putting my intern management philosophy into practice.
- A team of mentors. I gathered a co-mentor and two technical advisors: engineers who have different strengths and who all promised to respond to questions within two business days. Frances is reading and writing code in four different languages, and is able to get guidance in all of them. The other guys also have very different perspectives. Tollef has worked in several open source contexts but approaches MediaWiki's API with learner's mind. Brad has hacked on the API itself and maintains a popular Wikipedia bot that uses it. And Merlijn is a maintainer of an existing client library that lots of Wikimedians use. I bring deep knowledge of our technical community, our social norms, and project management. And I'm in charge of the daily "are you blocked?" communication so we avoid deadlocks.
- Frequent communication. Any time Frances needs substantial guidance, she can ping one of her mentors in IRC, or send us a group email. She also updates a progress report page and tells our community what she's up to via a public mailing list. We have settled into a routine where she checks in with me every weekday at a set time. We videochat three times a week via appear.in (its audio lags so we use our cell phones for audio), and use a public IRC channel the other two weekdays. We also frequently talk informally via IRC or email. She and I have each other's phone numbers in case anything is really urgent.
- Strong relationship. I met Frances before we ever thought about doing OPW together. I was able to structure the project partly to suit her strengths. We've worked together in person a few times since her project started, which gave us the chance to tell each other stories and give each other context. I've encouraged her to submit talks to relevant conferences, and given her feedback as she prepared them. Frances knows she can come to us with problems and we'll support her and figure out how to solve them. And our daily checkins aren't just about the work -- we also talk about books or silliness or food or travel or feminism or self-care tips. There's a healthy boundary there, of course, since I need to be her boss. But our rapport makes it easier for me to praise or criticize her in the way she can absorb best.
- Frances is great. I encouraged her as an applicant; from her past work and from our conversations, I inferred that she was resourceful, diligent, well-spoken, analytical, determined, helpful, and the kind of leader who values both consensus and execution. I know that many such people are currently languishing, underemployed, underappreciated. A structured apprenticeship program can work really well to help reflective learners shine.
I got to know Frances because we went to the same sci-fi convention and she gave me a tour of the makerspace she cofounded. Remember that just next to the open source community, in adjacent spaces like fandom, activism, and education, are thousands of amazing, skilled and underemployed people who are one apprenticeship away from being your next Most Valuable Player.
- Scope small & cuttable. Frances didn't plan to make one big monolithic thing; we planned for her to make a bunch of individual things, only one of which (the "gold standard" by which we judge API client libraries) needed to happen before the others. This came in very handy. We hadn't budgeted time for Frances to attend three conferences during the summer, and of course some programming bits took longer than we'd expected. When we needed to adjust the schedule, we decided it was okay for her to evaluate eight libraries in four languages, rather than eleven in five languages. The feature she's writing may spill a few days over past the formal end of her internship and we're staying aware of that.
- Metacognition. As Jefferson said, "If men were angels, we would have no need of government." But we're flawed, and so we have to keep up the discipline of metacognition, of figuring out what we are bad at and how to get better. I asked Frances to self-assess her learning styles and have used that information to give her resources and tasks that will suit her. Early in the internship I messed up and suggested a very broad, ill-defined miniproject as a way to learn more about the MediaWiki API; since then I've learned better what to suggest as an initial discovery approach. Halfway into the internship we realized we weren't meeting enough, so we started the daily videochat-or-IRC appointment. I have let Frances know that I can be a bad correspondent so it's fine to nag me, to remind me that she's blocked on something, to ask other mentors for help. And so on. We've learned along the way, about each other and about ourselves. My mom says, "teaching is learning twice," and she's right.
Setting up an internship on a strong foundation makes it a smoother, less stressful, and more joyous experience for everyone. I've heard lots of mentors' stories of bad internships, but I don't think we talk enough about what makes a good internship. Here's what we are doing that works. You?
(P.S. Oh and by the way you can totally hire Frances starting in September!)
Edited 2 October to add: Frances listed "[s]ome particularly useful approaches and skills" that made her internship work.
# 23 Jul 2014, 10:01AM: What Is To Be Done?:
When I worked at Salon.com I got to work with Scott Rosenberg. I never reported to him and barely got to collaborate with him directly, more's the pity, but I did get to witness him in meetings. He would listen for most of the meeting, then speak up, insightfully and concisely summarize others' viewpoints, and then say what he thought and why. (He was also the first person at Salon to predict that Schwarzenegger would win the governorship.) And he wrote Dreaming in Code, a book I frequently recommend to help non-programmers understand the infelicities and headiness of software engineering.
These days Scott is targeting his insight into our industry, long-term perspective, experience as theater critic and tech manager, and delightful prose at the issue of "being ourselves in a post-social world" -- or, life after Facebook. I love how he's working on it and I look forward to watching his work. And hey, I am still not on Facebook, so maybe I already live in Scott Rosenberg's future! I AM A TIME TRAVELER. WHOOOO. SPOOKY NOISES.
Anyway. Thinking about Scott's influence on me makes me think about management. I'm taking a break from formal management at my job right now, but I'm still on the board of directors of the Ada Initiative, and besides that there's my interest in influencing my communities informally. As Frances Hocutt put it,
when I talk about leadership and influence I am not talking about coercion or manipulation. I define influence as the ability to connect with others, and discover that their goals are also your goals.
(Hocutt and Rosenberg are also both saying interesting things about authenticity and leadership, by the way, in case you want to go read about that on their sites.)
A few years ago, I read the Project Gutenberg text of Florence Nightingale's On Nursing, and I thoroughly recommend it. Nightingale focuses on executive energy, attention, and putting the proper processes into place such that patients (employees) have the resources and quiet they need to get better (do their work). Once you get to a certain administrative level, instead of solving problems ad hoc you have to think strategically. As she puts it, a manager's question is, "How can I provide for this right thing to be always done?" You know, scaling.
One of the best thinkers on that particular question as it applies to the software industry is Camille Fournier, whom I hope to work with someday. She writes interestingly about autonomy, mastery, and introspection, making it easy for people to do the right thing, choosing to ignore easy problems, becoming the boss, and growing new engineering leaders. You can also watch or read her !!Con talk "How To Stay In Love With Programming" on the !!Con site.
And in case you want to play a game, try the manual text adventure "Choose Your Own Troika Program For Greece" (author's note) by Daniel Davies.
One of the motivations for the post was a discussion I had with @PabloK on twitter about the Greek negotiations, in which he said, rather succinctly, that the purpose of protest was to change the space of what was politically possible. I think this is a crucial point; although it is important to make a good faith attempt to understand the constraints that people work under (which is why I wrote the post), it is equally important not to regard those constraints as necessarily being imposed by Ultimate Reality.
(As long as I'm mentioning wacky takes on European financial crises I have to link to John Finnemore's analogy monologue.)
I am being super digressive today, thinking about the fact that I'm grateful for the chorus of thinkers and activists who sing so I can go take a breath, thinking about my choice to manage and lead adults and to probably not bear or raise children, thinking about how it gets tiringly abstract sometimes to always be setting up leveragable scalable systems, and thinking about the joy of mentoring future leaders. If I had to try to tie all of this together, I would say that the power of leadership is the power to change the constraints that people work under. And that I see a lot of my friends not-very-willingly constrained by Facebook, and I'm looking forward to seeing that go away.
# (6) 14 Jul 2014, 11:24AM: Why Job Titles Matter To Me:
A friend asked for help in thinking about job titles and job descriptions, and said she was specifically interested in how to think about them and whether they matter at all. I gave her some thoughts, from my experience, and thought I might share them here.
I think job titles *do* matter, in a few different dimensions. Here are the three major ones.
- giving correct expectations about you (your skills, your expertise, your influence within your org, your seniority, your independence as a decision-maker) to people outside your company/org, who use that metadata as a hint to treat you appropriately (invite you to give talks, recruit you, ask you suitable questions when they meet you, introduce you to other resources, ask for introductions, offer to sell things to your org or buy things from your org or otherwise partner with your org, praise or criticize your org)
(A subset of these goals: demonstrating for future recruiters/employers a particular career progression on your résumé.)
- giving correct expectations about you to people inside your org who don't already know you, e.g., new hires and Human Resources, so they treat you appropriately (assume you know/don't know certain skills and domains, take your advice seriously, invite you to the right brownbags and hackdays, put you on certain career ladders, ask whether you'd be interested in taking on a new project)
- hint to yourself about what you should focus on or what you/your org values (e.g., "senior" implies mentorship/stewardship, "reliability" or "performance" or "happiness" tells you what goal to focus on, "researcher" or "manager" or "analyst" or "nurturer" tells you what methods/skillsets you should be employing) -- this should be Part Of A Complete Breakfast, I mean, Job Description
Some people find that job titles do not matter to them. I posit that those people believe, or act as though they believe, that it is unimportant to provide additional easily-graspable metadata about their own work-selves to strangers or colleagues (I could imagine lots of reasons that this would feel unimportant) -- or that they already know what they need to be working on and do not need additional guidance-reminders.
In the current US software industry, sometimes you run across deliberately informal titles - God/Guru/Ninja/Wizard/Grunt/Thing-doer/Goddess/Mistress/etc. I don't quite feel up to the task of laying out the particular signals one THINKS one is sending, and the signals one actually IS sending, with those job titles. This feels like Kate Losse territory. Here, as with so many other human relationships, you might run into the very natural desire to make a joke out of it to elide all the tension and status play. And I understand that. When I got married, Leonard and I had a HARD TIME getting used to the words "husband" and "wife"! To ease into them, we mispronounced them or banged them together with other words, so, e.g., he was a "funband" and I was a "funwife". I feel like new formal job titles can be like that too, uncomfortable, like "one size fits all" clothes.
Sometimes silly job titles signal to others, "we value whimsy/insider cliquishness more than we value clear communication about tasks and roles with people outside our internal culture."
So if someone dismissively says that job titles don't matter, I suggest you tack on a silent "to them right now" when you interpret their statement.
# (2) 23 Apr 2014, 04:54PM: A Change Of Roles:
I did open source community management for MediaWiki for about three years. At first, in 2011, I was an individual contributor (see my February 2012 post "What Does A Volunteer Development Coordinator Do?"). After several months I became the team lead, and then about two years ago Wikimedia Foundation promoted me and I started managing my team. Dozens of people hit reply-all to congratulate me in messages I still treasure. (You have a "yay" folder too, right?)
I hired our new bug wrangler and our new volunteer coordinator. I got Wikimedia Foundation participating in the Outreach Program for Women paid internships, and we got way better at new developer intake in general. I introduced the Friendly Space Policy for WMF technical events (and we sure ran a lot of them). I introduced some innovations that took, and a few that didn't. When you fix one bottleneck you notice the next one -- that's the nature of bottlenecks -- and so we worked on harder and harder problems.
By external measures I was doing really well. But my management style does a lot better face-to-face, and I found it tiring to try to manage logistics and emotional nuance almost entirely via text - managing up, down, and sideways. And community management is often a customer service job with big gobs of emotional labor (example). By late 2013, I'd sort of plateaued; I wasn't learning as much and as fast as I wanted.
Hacker School gave me an opportunity to reset and to look at Wikimedia with new perspective, and to reawaken my interest in hands-on technical contribution and learning. I came back to a WMF that had just renewed its search for a FLOSS-savvy technical writer with programming skills. And, fortunately, my colleague Quim Gil was willing to make his interim position permanent, and keep on leading the team. So, as of about a month ago, I'm Senior Technical Writer at the Wikimedia Foundation.
And it's great. I've taken our Requests for Comment process in hand, started drafting improved architecture guidelines (not there yet) and our first unified set of performance guidelines, and started planning improved API documentation. And I've been learning bunches. I've learned enough to summarize REST and SOA and HTML templating systems as they relate to MediaWiki. I've learned how our caching layers work and how the new parser works. And I get to translate what I learn into prose and visuals to teach others, and I get to mentor intern Frances Hocutt as we both learn about the MediaWiki web API. For the last several weeks I've concentrated on understanding big things like how SOA will change our architecture, but post-PyCon I'm raring to code more; I'm looking forward to pair programming with Frances.
I feel so fortunate to have such a strong team. (This is one reason you hire people who could replace you - it gives you more room to change.) And I'm grateful to be at Wikimedia Foundation, an organization that nurtured and promoted me, gave me a three-month sabbatical to go to Hacker School, and helped me find different valuable work to do when I came back changed.
The two big problems I worked on as MediaWiki's community manager: inculcating empathy in others, and designing processes that scale. I made a dent in both, and I'll come back to them, and to management in general, in some future when I'm yet another Sumana, changed again.
# 06 Jan 2014, 07:37PM: Tourists:
What do you know about pipe organs?
Several years ago, all I knew about organs I'd learned from a few pages in Cryptonomicon comparing them to vacuum-tube computers. And I liked their sound. I was a regular attendee at the Community Church of New York at the time, and CCNY featured organ music in its Sunday service.
One day I heard that they were fundraising for organ upkeep. To help people see what needed doing and why, someone led a small group of us on a guided tour of the organ. I got to see how its parts related to each other, how all the inputs turned into the sound we enjoyed.
Any sysadmin or manager trying to persuade others to invest in long-term infrastructure should consider a similar tactic. Give your stakeholders a tour of your system's anatomy, so they can appreciate it.
# 02 Nov 2013, 02:25PM: Emboss:
I recently came across Lauren Bacon's "The Accidental Boss: Making Peace with Power" again, and it reminded me: We don't talk enough about power. We don't talk enough about how hard it is to transition from individual contributor to manager, and to delegate the tasks that you really love, that might even constitute your identity. We talk about delegating, but we don't talk enough about the inner emotional security you need to develop in order to hire and trust people smarter than you.
And we certainly don't talk enough about the necessary skill of constructively managing your anger in the workplace.
We say that anger is poison or that anger is righteousness, but have you had a role model who showed you how to manage your anger? Have you learned when to wait before sending that pissed-off email? How did you learn that?
And those intersect, of course. Sometimes I disagree with my subordinates or my superiors, but I believe I always work with them constructively and I don't let my mood get in the way of hashing out the issues and finding a decision. But what if I'm wrong?
Argh gender. We women get disproportionately less training, formal and informal, in handling personal power and in using anger. And I have to do that double-checking multiple times a week, predicting how others would react to any given reveal of my power or anger.
Jono Bacon publicizes the risk of burnout. Those middle stages include substantial anger, irritability, and anxiety. How do you know when your anger is a healthy, legitimate response to a wrong? How do you know when your anger is getting in your way?
(Oh, and those of us who grew up with parents who didn't deal with their own anger responsibly have even more trouble with this. Double argh.)
What do we have? Where are we talking about these things? Sunday sermons, "Chain of Command" and "Lower Decks" from Star Trek: The Next Generation, the odd thoughtful BDSM-related blog post or fanfic, a few essays about Obama's leadership style, leadership coaching seminars, activist retreats? Is this what the Harvard Business Review is for?
I have gotten into the habit of reviewing my anger with a trusted colleague or friend. "Foo happened and bar happened and he said x and I said y... I feel frustrated/resentful/unappreciated/patronized, and basically angry, and it's distracting me... what do you think? am I being reasonable?" Advantages: fewer damaging blowups. Disadvantages: sometimes I lose the opportunity to respond to a problem in the moment, and when I do respond, the other person thinks I'm holding a grudge.
Skill acquisition is hard, yo.
# 09 Nov 2012, 08:36AM: Mission:
I decided to transcribe the speech in which newly reelected US President Barack Obama thanks his campaign staff and reflects on his own experience as a community organizer. I hope this helps nonnative English speakers and the Deaf. (.srt file available for download even! I'm not sure how to tell YouTube to use this instead of its superlatively awful automatic captions.) But I really just wanted to get his words right so I could talk about them.
In June 2008, the new Democratic Presidential candidate, Barack Obama, gave a speech to his campaign staff that Leonard and I watched. I was a project manager at a webdev shop, thinking about what "politics" means and admiring Obama's campaign for its "transparency, trust, boldness, and long-term investment and empowerment of non-bosses". I thought about Obama's viral leadership model: he doesn't just want to be that kind of leader, he wants to make you that kind of leader. And I loved the audacity of only doing effective things.
Four years and change later, I've become more and more like his audience, and like him. I became a community organizer, albeit in open source rather than electoral politics. I work to train contributors to mentor each other and to run events. I argue that we shouldn't do ineffective things, even if they're tradition. And in his 2008 speech, when he says:
Now everybody is counting on you, not just me. I know that's a heavy weight. But also what a magnificent position to find yourself in, where the whole country is counting on you to change it, for the better. Those moments don't come around very often....
he might as well be talking to me, about the stress and the opportunity of working for Wikimedia.
"And the work that I did in those communities changed me much more than I changed the communities," Obama says. That is the virtue of doing this work not in pairs, as missionaries do, but alone, as Genly Ai does in Ursula K. Le Guin's The Left Hand of Darkness:
Alone, I cannot change your world. But I can be changed by it. Alone, I must listen, as well as speak. Alone, the relationship I finally make, if I make one, is not impersonal and not only political: it is individual; it is personal, it is both more and less than political. Not We and They; not I and It; but I and Thou.
I also loved his explanation, "And it taught me something about how I handled disappointment, and what it meant to work hard on a common endeavor. And I grew up. I became a man during that process." What a tremendously hopeful conception of masculinity and adulthood, to be say that "I became a man" by growing a disciplined empathy.
And here my thoughts go in too many directions to capture: how contributors get ignored if we aren't The Right Sort, and how we fight back (and David Brooks, surprisingly, captures a useful nuance); you can no longer diss women and get away scot-free in national US politics; maturity, sustainability, and self-soothing; "I am here because of Ashley."
But back to the thank-you speech: let me excerpt the most moving part.
You know, I try to picture myself when I was your age. And I first moved to Chicago at the age of 25, and I had this vague inkling
about making a difference. I didn't really know how to do it. I didn't have a structure. And there wasn't a presidential campaign at the time that I could attach myself to. Well, Reagan had just been reelected.
And was incredibly popular. And so I, I came to Chicago knowing that somehow, I wanted to make sure that my life attached itself to helping kids get a great education, or helping people living in, in poverty to get decent jobs and be able to work and have dignity. To make sure that people didn't have to go to the emergency room to get healthcare. And, you know, I ended up being a community organizer out in the South Side of Chicago with some, a group of churches who were willing to hire me. And I didn't know at all what I was doing....
And so when I come here and I look at all of you, what comes to mind is: it's not that you guys actually remind me of myself. It's the fact that you are so much better than I was.
In so many ways! You're, you're smarter and you're better organized. And, you, uh, you're more effective. And so I'm absolutely confident that all of you are gonna do just amazing things in your lives. And you'll be what Bobby Kennedy called the ripples of hope that come out when you throw a stone in a lake. That's gonna be you!
You know, I'm just looking around the room and I'm thinking: wherever you guys end up ... you're just gonna do great things!
And, and that's why even before last night's results, I felt that the work that I had done, um, in running for office, had come full circle.
[Obama's voice chokes with emotion]
Because what you guys have done means that the work that I'm doing is important. And I'm really proud of that. I'm really proud of all of you.
[Obama tears up]
For the first time, I saw famously cool, self-controlled Barack Obama tear up. This is what gets at him, in his bones: empowerment.
I should check in again in another four years, and ask how I'm measuring up.
# 19 Jun 2012, 06:17AM: Conference Seasoning:
You know you're traveling too much when you completely stop updating the "where I'm going to be" feeds (example).
Regardless: I'll be in San Francisco starting late today, and then in Portland on Monday the 25th, the day before I give the opening keynote address at Open Source Bridge. My tentative title: "Be Bold."
Wikimedians are giving several other talks during the conference:
The Wikimedia Foundation is also sponsoring the Friday unconference day, and will host a hacking table that day as well as (I hope) the Tuesday "Hacker Lounge Project/Community Night."
Then, I'll be in Washington, DC, July 10th-15th for Wikimania, especially the pre-conference Hackathon. I'm happy to announce that WMF is partnering with OpenHatch to make the pre-Wikimania hackathon even more useful. OpenHatch is planning and running the novice-focused half of the event, with trainings and projects to help people learn how to hack Wikimedia technology.
I'm leading at least two talks at Wikimania:
I say "at least two" because who knows whether folks will rope me into moderating a panel, or doing some stand-up comedy.
# (1) 19 Jun 2012, 05:54AM: Challenge:
Wikimedia Foundation is hiring a leader for volunteer software testing. I have ideas on what this person should do and how to do it* -- indeed, this position reports to me -- but more than that, I have ideas about what kind of person I need to find.
I need someone who has skills in open source contribution, who gets the wiki and open source way. Even if the person lives in San Francisco -- which they don't have to -- they have to collaborate well remotely, with volunteers and other colleagues. And I seek someone who has the focus and analytical skill one needs to test software, and the hospitable and generous temperament one needs to encourage and teach newbies.
I've been bookmarking lists of suggestions for ways to test, like You Are Not Done Yet and Falsehoods Programmers Believe About Names and its sequel on time. We've already started running online events for new testers. If talking like this is scratching an itch for you, even if you've never had a job title as a software tester, please apply. At least we'll have an interesting conversation.
* Had I worlds enough and time, I would start a retraining school that turned underpaid copyeditors into versatile and sought-after software testers. Proofreaders can already follow instructions and communicate effectively and deploy critical thinking skills while nitpicking, so they just need some guidance in learning some domain knowledge. (One of the great benefits of the modern technology industry is that it provides productive and lucrative channels for pedantry.) I do not have the time to do this for profit, but perhaps my Engineering Community Team can use this kind of arbitrage to recruit and train volunteers, give them some skills to put on their résumés, and get some more quality assurance.
# (5) 23 May 2012, 11:45PM: A Local Maximum:
By the way, I got promoted. It's quite an honor.
Wikimedia Foundation's new Engineering Community Team, which I lead, is a renaming of the TL;DR group. We've written a draft summary of our goals for July 2012-June 2013. There's so much to be done! (Of course, we're hiring.)
In open source, we share our vulnerabilities and our milestones, so of course my boss announced my promotion to a public mailing list. I was surprised and delighted when colleagues and contributors in my community responded to that announcement with congratulations, privately and publicly. It is as though they believe I am doing a good job! Take that, impostor syndrome.
I'm thinking about the thirty years of influences that got me here. As a teen, I volunteered for the Peace and Justice Network of San Joaquin County, and met my mentor John Morearty, whom I saw this past weekend. Before I knew Sam Hatch, and before I knew Seth Schoen, even, I knew John, a teacher who took his values seriously and was always ready to teach. He led volunteer communities that aimed for inclusiveness and viral change. He modeled grit, open-mindedness, and compassion, and I saw in his example that another world was possible, another mode of being. He wrote a fascinating memoir that you should check out, if you like twisty life stories.
John had twin sons, Mike and Brian. I got to meet Mike on Sunday. On Monday he got write access to Wikimedia Labs, Git, and Gerrit. I find this confluence pleasant yet dizzying, like the bushels of jasmine in John's garden. There's so much to be done, and the abundance of my world may yet provide. As John reminded me this weekend, we cannot build the new systems we need; we must cultivate them.
# 26 Mar 2012, 05:53PM: Announcements and Reading:
I'll be keynoting the Open Source Bridge conference this year (late June, Portland, Oregon, USA). It's an honor to be asked to give a keynote address to this exciting and inspiring conference.
"<body> <img> -- the anxiety of learning and how I am beating it" is my newest post at Geek Feminism.
Enjoyed in the last several weeks: Naomi Kritzer's "Scrap Dragon," a short story in the January/February issue of The Magazine of Fantasy and Science Fiction. "Recognizing Gabe: un cuento de hadas," a short story in Strange Horizons by Alberto Yáñez. "Things Greater than Love" by Kate Bachus, another story in Strange Horizons. Past Lies, a graphic novel by Christina Weir, Christopher Mitten, and Nunzio DeFilippis.
# (1) 10 Jul 2011, 01:22AM: "Learn Tech Management" Essay/Notes:
Final notes, including an audio recording and an edited & annotated transcript, for my standing-room-only talk "Learn Tech Management in 45 Minutes" from this year's Open Source Bridge.
And I wanna also tell you that I am gonna talk a little bit about kind of managing up and managing down, but really more of what I'm talking about is managing up, because I think a lot of us have had at least some experience of managing other people and helping them understand what to do, but managing up is where it gets all mysterious, and people wear suits, and they talk about terms we don't understand.
And I think of this as kind of harm reduction. This talk that I'm giving right now. It's a little bit of the gentle art of self defense. Because, you know, you might be an engineer who has to deal with management and fight for your project, or you might want to take leadership of your open source project, and you might want to write proposals for what people should do or why they should give you a grant. Or you might accidentally turn into a manager at your firm. It might be foisted upon you.
And so I hope that some of the stuff in this talk will take you from, like, 0th percentile up somewhere else, and give you a bunch of keywords that you can look up on Wikipedia, the world's free, open source encyclopedia.
Subheaders include "Why do projects fail?", "Evil list", "Suit-friendly presentations", "Lenses", and "Q&A about measuring intangibles".
Much thanks to Christie Koehler for getting me that audio, and to Mirabai Knight of StenoKnight CART Services for transcribing my talk. Thanks to Reid Beels for the CC BY-NC-SA photo.
# (2) 29 Jun 2011, 07:01PM: Open Source Bridge 2011:
I had a wonderful time at this year's Open Source Bridge conference. Last year at OSBridge, I presented "The Second Step: HOWTO encourage open source work at for-profits" and had a great time. So this year I spoke on technology management, with the fairly ambitious title "Learn Tech Management in 45 Minutes". Addie Beseda reported such a high turnout that people were standing in the hall outside the door listening to the talk, which blows my mind. Audio and polished notes coming soon; slides & nearly complete notes available now.
Because we released MediaWiki 1.17.0 (after 11 months of development and review!) while I was in Portland, I also led an unconference session on "What's new in MediaWiki 1.17 and How You Can Help". People volunteered to help us with PostgreSQL support, testing, design ideas, bug triage, the parser, and more. And I got to talk about the new release with Ward Cunningham, who invented the wiki. That has got to be a Sumana career highlight.
I also performed some geeky stand-up comedy, and people liked that. So that's nice.
Sessions I attended:
DNSSEC @ Mozilla -- way over my head, which is fine.
- A Dozen Databases in 45 Minutes -- I found this very useful in helping me understand, among other things, why one would privilege availability over consistency. Thanks to speaker Eric Redmond for some memorable metaphors.
- Drupal Distributions, an Open Source Product Model made me think about the danger of fragmenting sub-communities within a larger FLOSS community.
- The open source communities panel -- I did not pay enough attention to this, as I was finishing up work on my talk. I do remember some people disagreeing about qualitative versus quantitative release management decisions and about how to recruit and mentor new participants; sadly I don't have any useful recollections.
- Selena Deckelmann led "How to Ask for Money", which I think many people will find useful. Some of their lessons: "Find a fundraising mentor," "Hire a graphic designer", "Your network is bigger than you think," "Ask again anyway," and "Do what you say you'll do. And if you don't, communicate why - now."
- Dawn Foster's fantastic "Online Community Metrics: Tips and Techniques for Measuring Participation" was -- to all the community managers in the room -- worth the price of admission on its own. Hit the slides (per her blog post) for great pointers to MeeGo's statistics, MLStats for mailing list analysis, irssistats for IRC analysis, and more. And I have some additional notes at the talk's OSB wiki page.
- The Birds of a Feather session for Google Summer of Code proved educational; students, alumni, mentors, projects' administrators, and Google's GSoC administrators discussed challenges and opportunities. I learned that GSoC organizational administrators can email Carol Smith at Google to request possible travel stipends for their GSoC students to attend conferences, and possibly to look at previous mentors' evaluations to decide whether to keep them another year. Also, FLOSS projects report great success with the tactic of requiring applicants to do small tasks to prove they're serious and to set up those students to succeed, and mentors and org admins did not seem to think that this would unfairly weight admissions towards students who were already going to go into open source anyway.
- "Snooze, the Totally RESTful Language": hilarious, because Markus Roberts led it. My dents from the session:
- # In Markus Roberts's #osb11 talk "Snooze, the Totally RESTful Language". Leonard, you never told me REST was a meaningless acronym. BETRAYAL
- # Demo fail. "Anyone here have a laptop?" "What, you want me to go to localhost *for* you?" #osb11
- # "I think there's a market for this, especially if we convince people that there is one." ... "Are you incepting?" #osb11
- # Markus is now just riffing on soaking up consumer surplus, Bitcoin, NoSQL, pig Latin, & the joy of boundaries. #osb11
- Elizabeth Naramore spoke on technical debt (slides). One item that really struck me is her experience that sometimes chipping away at little tech debts won't get you the momentum & buy-in you need. You need a big thought-provoking goal.
- "Inviting Contributors to Open Source Webdev through Virtualization" by Les Orchard told me that not just Dreamwidth, not just Wikimedia, but also Bugzilla and addons.mozilla.org are trying this concept. Four makes a trend! I hope they all compare notes. I also learned of a tool to sanitize real data dumps, to get useful test databases that community developers can use.
In between, I saw new friends and old, talked up MediaWiki, told people about the zillion open positions for which Wikimedia Foundation is hiring, played Dance Dance Revolution, ate great food, and enjoyed the inimitable atmosphere of a great conference.
A few ego-stroking notes: Open Source Bridge's Melissa Chavez also interviewed me for an eight-minute video. And, with Asheesh Laroia and Igal Koshevoy, I was named one of three Open Source Citizens by the conference organizers. Thank you for the honor; I will wear my scarf with pride!
(Thanks to the Wikimedia Foundation for the plane flight, to the conference for letting me in free as a speaker, and to my friends Brendan and Kara for hosting me. Thanks to Reid Beels and John Parker for their photos, which are CC BY-NC-SA. Thanks also to Josh Triplett for his photo.)
# 23 Jun 2011, 10:12AM: Learn Tech Management In Probably Fewer Than 45 Minutes:
I've put up slides and pretty rough notes from the talk I gave yesterday at Open Source Bridge, Learn Tech Management in 45 Minutes. I quote Langdon Winner and then Marx & Engels, summarize the efficient markets hypothesis as "we're not stupid," and give a list of spin tactics you can use to get or keep budget for a project. Audio & nicer notes to come soon.
# (1) 09 Jun 2011, 02:04PM: Portland and San Francisco Travel This Month:
I'm going to be in San Francisco next week for in-person collaboration with my Wikimedia colleagues. Then, June 19-25, I'm at the Open Source Bridge conference, presenting Learn Tech Management In 45 Minutes.
It took me two years to get a master's in tech management. I save you $40K and give you the short version.
Managing innovation, intellectual property and employment law, corporate finance, building a business plan — my master’s degree in technology management gave me some grounding in a bunch of suit stuff. I’ll teach you a little of each of these, plus insights from my management experience and fish-out-of-water anecdotes. Aspiring executives welcome; ties optional.
It would be lovely to have time to hang out with acquaintances and friends in either location; contact me!
# (5) 03 May 2011, 10:40AM: New Job, New Email Address:
As of this month, I'm a full-time contractor for the Wikimedia Foundation, serving as Volunteer Development Coordinator. My boss at WMF, Rob Lanphier, has just posted a welcome note that makes me sound all fancy.
In case you were wondering about my other clients from earlier this year: my paid work on GNOME Marketing, for the launch of GNOME 3.0, has ended, and I've also ended my work as fundraising coordinator for QuestionCopyright.org (passing it on to someone who has more time and relevant experience).
It might be disorienting to only have one job! I shall probably get used to it.
# (1) 01 May 2011, 09:45PM: PICC 2011:
My performance at the Professional IT Community Conference went all right. Consistent light laughter, some long belly laughs and several bits of applause. Sheeri Cabral and Tom Limoncelli really hit it out of the park on Slideshow Karaoke (best practices). Thanks to The League of Professional System Administrators for inviting me, and especially to Matt Simmons and William Bilancio for organizing my attendance and appearance.
A few things I recommended at PICC:
# 11 Apr 2011, 03:38PM: GNOME Contractor Status Update: Launch Week & Next Steps:
(Also posted to marketing-list.)
My last email, on April 1st, mentioned that "my main TODOs today, this weekend, and early next week are to follow up on press contacts, the eReleases blast, and GNOME Journal." So I did that; that day, I got the eReleases press release out, and it went to more than a thousand publications. And then here's a list of what I did last week on GNOME:
- Corralled answers for journalists. A few journalists asked me followup questions after the press release, so I got answers from other GNOME people, wrote answers, replied to the reporters via email and phone, and put these answers on the wiki (Talking Points).
- Managed the GNOME Journal launch. Nagged the last few authors, edited articles for content and style, uploaded them, fought with Textpattern, continued planning to move us to WordPress, and sent out the publication announcement. I'd still love for people to continue publicizing this, since there are many interesting nuggets that I haven't seen picked up by the larger press.
- (Started planning the next two issues of GNOME Journal, including hopes for a 3.x roadmap article in case anyone wants to write it.)
- Did a teensy bit of web testing and feedback regarding gnome3.org. Great job!
- Went to the Linux Foundation Collaboration Summit. There, I talked up GNOME 3 to reporters and other interested Linux folks, and made contact with some KDE people and started talking about publicity for the upcoming desktop summit. It sounds like we should be working to drum up attendance now, by planning special events, trumpeting rare speakers, and publicizing the unique benefits of attending GUADEC & the Desktop Summit.
- Attended the marketing/PR training at the Linux Foundation Collaboration Summit (thanks for setting it up, Dave!). I sure did learn a lot, from strategies for resource-constrained projects (build relationships with five key reporters) to tips for being interviewed. I will link to Cloer's slides and add my notes when she puts them up.
Undone: I didn't put tasks in Bugzilla because they were moving too fast and I was in San Francisco, many timezones away from Allan in Bangalore, and couldn't coordinate effectively. Lesson for next time: do it early if we're going to do it at all. Similarly for setting up interviews with key GNOME developers; I dropped the ball there.
Now that we've launched, I talked with Allan about how to best use the rest of our contracts (we're booked to work on GNOME till the end of April). We think our priorities for the rest of April are:
(a) reach out to not-so-news-driven (more in-depth-reporting) journalists about aspects of the release that didn't get covered on launch day -- once we get some bites, prep developers who have volunteered, and get them interviewed
(b) write up lessons learned & ideas for next time
(c) infrastructure building & maintenance: update the wiki, consolidate audiovisual and textual resources, and otherwise help prep for future marketing, including press releases, talking points, etc. for the launches of GNOME 3 within distributions that will come out in the next weeks & months
So I'm going to make some progress on each of those this week. Specifically, I aim to reach out to two reporters, braindump a few lessons learned privately, and confer with Allan Day and Vincent Untz about resource consolidation. And I'm planning on pushing GNOME Journal's next issue forward, in collaboration with Paul Cutler, but that's not part of my contract since it's not GNOME 3-specific. :-)
# (3) 01 Apr 2011, 04:21PM: GNOME 3 Marketing: A Snapshot:
The story of this week, for me and GNOME marketing, is primarily the story of a press release. I collected quotes, revised it in response to feedback on marketing-list, added press contacts to our CiviCRM installation and emailed the press release to them (at least twenty contacts, with more to come). It should show up tomorrow on gnome.org once the "we're delaying six months" April Fool's press release runs its course. We're now getting responses from interested journalists and I'll be answering their questions and helping them set up interviews with some key developers.
Also, I heard a success story from another open source marketer about ereleases, so I plan on editing the press release down to 500 words and paying $200 (the nonprofit rate) for their press release publicity service this afternoon.
By the way, in a previous status report I mentioned looking into Collabtive. It's terrible and I won't make us use it. For tasks involving responding to press contacts, we are using CiviCRM. I will be checking with Allan after the hackfest to see whether the remaining tasks would benefit from being placed in Bugzilla; I had aimed to do that before I fell ill.
This week we also had the second User Day. I did not publicize it as far ahead of time as I wish I had, but we did get some participation and answer some users' questions. Thanks to all the hosts!
After a discussion with Sri and Diego, I added "Approaches That Work" to the GNOME 3.0 talking points. If you need to talk with a skeptic about GNOME 3, we're hoping you can get some ideas, tips, and answers to common skepticisms there.
I also did some nagging, editing, writing, and organizing around GNOME Journal's GNOME 3 issue, which we hope to put out this weekend.
So my main TODOs today, this weekend, and early next week are to follow up on press contacts, the ereleases blast, and GNOME Journal. Thanks to everyone in Bangalore who's at the hackfest and working on the release!
# (2) 22 Mar 2011, 08:45PM: A Slightly Disjointed (Due To A Five-Day Cold) Musing On Open Source, Fear, Motivation, And Witnessing:
I was introducing C. to a set of QuestionCopyright friends and acquaintances, and they were joking about indoctrinating her, and she was curious to hear what free culture is all about. So she wondered why I reflexively suggested that the others wait a bit, tell her next time.
They did give C. the introductory spiel, and conversation was pleasant and edifying, and nothing terribly awkward ensued. She has developed a substantial interest of her own, now, in the theory and practice of free culture. But why did I have that reflex? I felt around for it and grasped something. It makes it harder, I said, once you know these things and care about them. Becoming a free culture/free software person is like becoming a vegan.
No, G. replied -- at least people know what vegans are.
We happy few.
Here I was, a fulltime free culture/free software consultant, feeling an unaccustomed reluctance to give someone else the sunglasses, to witness.
There are self-constraining ideologies like veganity or chastity that modern society at least theoretically understands, even if some cohorts scoff. Then there are the practices that always require an introduction. When I explain how I met Leonard, I often start with the thirty-second "what is open source" explanation, because it's all of a piece. But my "what is open source" intro focuses on pragmatism -- many eyes making bugs shallow -- rather than free software values.
I think I'm a moderate sort of open source gal, an ovo-lacto vegetarian. There's an iBook running Mac OS tucked off in a drawer, and all these Linux boxen in our house surely have nonfree binaries driving bits of hardware. No Facebook but I surely use many cloud services that violate the Franklin Street Statement. I hang out with copyright abolitionists, Debian users, and other free culture/free software folks who make me feel namby-pamby. And then I go to dinner with someone who makes me feel like a Jain. Or I find myself saying, as I said a week ago, that developing on a closed platform is like trying to fall in love with someone who won't talk to you.
Our love is part of what energizes us, moves us to act. In FLOSS, volunteers do things for two basic reasons: either because we enjoy doing them for their own sake, or because the task needs doing and we want to do our bit. We see some goal the task will help us reach, or fear an outcome the task will help us prevent. [By the way, it's useful to have experienced that, because it's useful to assume those two as the means of persuasion whether my colleague's paid or not. As a leader, I should either set up tasks people will genuinely enjoy (and get the scutwork out of the way), or help my colleagues see a straight line from the task to a glorious future. Show them how what we're doing leads to something they want. This is my pet theory of How To Lead Knowledge Workers and your mileage may vary.] And -- as a zillion social scientists will tell you -- even if we momentarily burn out on caring about a goal for its own sake, we don't want to let the team down. We don't want to let our buddies down.
As we were talking about GNOME marketing, Andreas once asked me what I found special, what personally spoke to me about GNOME. I rambled: object code is compiled from source code, but the source code is compiled, too -- compiled from people, from time, from love. Every time I look at my desktop, every feature and every bug comes from someone, someone with a name and a face, and sometimes I can even remember. Hey, I remember when she added that feature to Empathy. Oh, right, I know he's working on that bug. It's like all of Planet GNOME is helping me out, every day. It's like my whole community's right there, on my desktop, every time I open the laptop lid.
I don't want to keep my friends blissfully ignorant of this. Is there a more loving human impulse than the joy of sharing? I'm sorry, C. I'm sorry I was afraid of making your life harder. I remembered the local minimum and forgot the greater maxima awaiting you. Why keep us a "happy few" when we can be an ecstatic many? And yes, it's harder, to learn our principles and try to walk this path alone -- but the whole point of our principles is that our multitude, our diversity, our union, our communion is far richer and more sustaining than individual hoarding ever could be.
# (5) 02 Mar 2011, 04:54AM: Wikimedia:
Now that my new bosses have told the world: yes, I'm also now consulting for the Wikimedia Foundation, the nonprofit that supports Wikipedia and other free knowledge initiatives. To grossly simplify, I'm coordinating software development (mostly MediaWiki improvement) that isn't by WMF staffers, primarily concentrating on the upcoming Berlin hackathon and this year's Google Summer of Code participation.
Thank you, nostalgia: in December, I was looking up my old high school classmate Christine Moellenberndt, and discovered she was a new hire, then looked at the current job openings, and applied.
I told my mom about it and it went something like:
"Mom, I'm working for the nonprofit that does Wikipedia! ... No, not them, they're different. Wikipedia is a big free encyclopedia that's online for anyone to use. Wikileaks is a ... well, they're a bunch of people who like to get and publicize secrets -- anyway, that's not us."
And no, this holiday season my photogenic face will not be on banner ads entreating you to give. As far as I know.
# (1) 26 Feb 2011, 09:52AM: Careering:
Since I last mentioned my career, I have turned into a consultant. I have a few gigs; let me tell you about two of my clients.
QuestionCopyright.org is a nonprofit that aims "to educate the public about the history of copyright, and to promote methods of distribution that do not depend on restricting people from making copies." I'm QCO's Fundraising Coordinator, meaning that I write and coordinate grant proposals. I also write a tiny bit for the QCO website. Case in point: "Three glimpses: Transformative work, public domain music, and ethics".
The GNOME Foundation, the nonprofit that supports the GNOME desktop, has hired me as one of two contractors to manage marketing for the launch of GNOME 3.0. Allan Day and I will be (to oversimplify) ensuring that Linux users know what's new in this release and why it's awesome.
More on those and my other work when I can!
# (3) 01 Feb 2011, 08:47AM: When Am I Ever Going To Have To Use This?:
Yesterday, while negotiating with potential clients, I used:
- You know, standard reading, writing, and interpersonal speaking skills (many courses, school newspaper, speech & debate, Academic Decathlon)
- Basic algebra to work out some price quotes (elementary school math classes)
- US and world geography (K-12, history classes)
- The wheelbarrow anecdote from Benjamin Franklin's autobiography to make a point about open source contributions as a marketing tool (eleventh grade American Literature)
- Political science concepts of authority and legitimacy, in determining a client's needs regarding open source leadership (college)
- Knowledge of Unix-style design (started in college, especially at the Open Computing Facility)
- The innovation S-curve, and cautionary tales of platforms that never got uptake from customers and vendors (master's in tech management)
All that school comes in handy sometimes!
# (7) 23 Aug 2010, 09:45PM: Two Tips On Convincing Managers & Executives To Invest In Your Technology Projects:
From a years-old job-advice email to a friend. The sort of knowledge that Rachel Chalmers or Karl Fogel finds obvious but that some of us still haven't quite integrated into our day-to-day communications and long-term strategies:
You need to be able to express your suggestions to your boss in terms of financial incentives and losses.
A few things I've picked up during a recent class in "Technology in the Business Environment" (when I was doing the master's in tech management at Columbia):
I) Management focuses on the things that drive the organization (directly making money), and tends to ignore things that support the organization's drivers. If you're directly making money, lowering the cost of producing the product/service, increasing management's control, increasing product quality, increasing the knowledge available to an important decisonmaker, or improving customer service, you can describe your work as a driver. Can you find a way to describe your high-level TODOs in one of those ways?
II) Here's a model of management's priorities for technology investment. The higher up this list you can get, the more attention you can grab from management.
- Revenue. Guaranteeing a financial return. Not just cutting costs, but actually MAKING money from customers.
- Increasing scarce productivity. If the demand for a product exceeds the supply, then this is attractive. [1 and 2 indicate that the company is growing, and interested in the future. A good sign!]
- Cutting costs. More popular in a struggling company.
- Competitive advantage -- this means the company is already behind its competitors and has lost first-mover advantage.
- Tech for the sake of tech -- pizzazz and leadership.
So can you explain "creating system-monitoring scripts, streamlining processes, and installing and configuring new programs on the server" so that they're way up on that list?
Let's say a system-monitoring script would take your service from 95% uptime to 99.9% uptime. That's #2. Maybe one of the high-level tasks you do will make it possible for your company to serve twenty units instead of fifteen (#2) or even start a whole new line of products (#1). But "It's more elegant/technically correct" is #5.
I welcome comments, tips, examples, disagreement, and cake.
# 24 Jun 2010, 03:40PM: The Second Step: HOWTO encourage open source work at for-profits:
At the excellent Open Source Bridge conference earlier this month, people seemed to enjoy my talk. The one-liner:
Even at pro-FLOSS businesses, logistical obstacles and incentive problems get in the way of giving back. I’ll show you how to fix that.
My session notes are now available. If you were there, please feel free to clarify them and add your notes or links to your notes elsewhere.
The very short version: a company does not upstream its patches, even though it should for long-term practical reasons, because of problems in four general categories. The company might lack a FLOSS culture. There might be legal confusion about what employees are allowed to do, and how to get permission. The project management workflow and timelines might not allow time for proper engineering. And the external project might have a terrible UI for new contributors.
Once you abstract these categories away from the specific problem of accidentally hoarded code rotting away, you see that they also apply to other problems of the type "I really know I should be doing foo but haven't gotten around to it."
I also added notes from my lightning talk on Thoughtcrime Experiments, in which I inadvertently invented a new social media marketing technique.
# (1) 10 May 2010, 10:29AM: GNOME & Conference Planning & Writing:
I'm back in New York City. Big priorities this week include:
# (2) 05 Feb 2010, 11:48PM: Another Change:
I'm no longer working with Collabora Ltd.
In the first several months after I joined Collabora in April 2009, I served as lead project manager, got the new website up, and started putting some new project management processes into place, especially in research and development. Then I shifted to personnel management, and created and began implementing a performance assessment system. All the while I gardened the wiki, aggregated and edited weekly internal reports to keep the company on the same page, blogged about our work, and generally gave people the information and the nagging they needed to make informed decisions. (In retrospect, I played facilitator, historian, and journalist a lot, plus mentor to 50+ Collaborans.)
Collabora's a different place than it was ten months ago; I helped move them from a startup to an enterprise footing. Management structures change as needs and capabilities become apparent, so the directors and new hires (including the awesome Martin Barrett) will carry this work forward, and I offer them my best wishes. I'm happy to talk more in detail about what I did at Collabora, especially if you're interested in what I can do for your organization.
In the near future, I'm taking some time to relax and take care of existing obligations before I incur new ones. Then, starting in late February or early March, I'll be volunteering fulltime on some open source/free culture projects for several months. I haven't yet decided which ones, or in what capacity, so feel free to recruit me.
# 22 Nov 2009, 10:29PM: Career Analysis Stuff:
You might be interested in my analysis of my career history in a longish Crooked Timber comment.
I'm very glad that I had so many different work experiences before making irrevocable choices, and that I delayed grad school till I had a specific purpose.
Tonight I thought a little about loyalty to one's workplace in a comment on Venkatesh Rao's thought-provoking business management post.
Loyalty to an organization? Identifying with an organization? For a fairly smart hard worker, who actually believes in the stated goals of the organization, it's fairly seductive, especially if they conflate their specific subcommunity with the institution as a whole.
I learned via Mel Chua that Gerald Weinberg, whose work has influenced my industry and my career profoundly, is very ill. My thoughts are with him.
# (1) 25 Sep 2009, 08:49AM: We Already Know The Title Of His Management Tips Book:
I used to watch Project Runway identifying with the contestants. Now I watch and think, "Tim Gunn is really good at phrasing criticism in a way that's likely to get across to the designer. I want to be that kind of manager."
# (1) 12 Sep 2009, 06:25PM: Wintour Guide:
I watched and enjoyed The September Issue with Elisa (who pseudoblogs as The Mad Fashionista and with whom I watch Project Runway). Some brief thoughts:
The September Issue is an office comedy ("comedy" in the sense that no one dies and the issue successfully comes out). And it's a portrait of a power couple. Editor-in-chief Anna Wintour and creative director Grace Coddington have worked together for decades, each admiring the other's talents but fairly relentless in the battle to pursue her own artistic vision. The creative tension between forward-looking Wintour and history-mining Coddington drives Vogue and the film. This film passes the Bechdel Test by leaps and bounds. It's lovely to watch unapologetically powerful women and learn how they use their power.
Coddington is marvelously resourceful in using any leverage or opportunities she finds. She gives lots of forthright-seeming interviews to the documentarians, so she gets to appear quite a lot in the film (contrast Wintour, whose famous reserve only goes away when she's at home with her daughter). Coddington asks Wintour for a larger budget for a project in front of the camera crew, and later grins that Wintour is more lenient on funds when she's on camera. And, most mischieviously, she gets the cameraman to appear in an inventive photo shoot for Vogue, and explicitly tells us that capturing and using him on film is a bit of revenge. Subverting their gaze and getting a witty, pretty spread is a nice twofer.
The film chronicles the development of the 2007 September issue of Vogue, which explains why everyone in the film is acting like the economy's fine. But even two years ago, was Vogue setting trends and making waves? Coddington credits Wintour with integrating celebrity culture into fashion culture faster than other mags did, but seventy years ago film stars' fashion choices got copycatted all over. Current events in fashion don't get discussed much, either; The September Issue doesn't mention blogs, or Project Runway, or Lucky, or counterfeit goods.
But there is a historical subtext in the film, a subtext that comes closest to the surface when Coddington stands motionless before elaborate Versailles gardens. The gardens are expensive and elaborate and required not just a wealthy patron but an entire edifice to support them (Si Newhouse is to Wintour as Wintour is to Coddington). Each photo shoot that Coddington orchestrates is as beautiful as a blossom. But any individual fashion that Coddington captures in her Vogue spreads is as ephemeral as a blossom. The gardens are still there, and still magnificent, and what are you doing that will last centuries?
Sherwood Anderson writes in Winesburg, Ohio of thoughts of mortality: "He knows that in spite of all the stout talk of his fellows he must live and die in uncertainty, a thing blown by the winds, a thing destined like corn to wilt in the sun." I reread bits of Winesburg the other day, and remembered that the really scary thing about that last image is the sun's betrayal.
Coddington calls herself a romantic. She loves old gardens and 1920s styles. And she remembers what got shot for a previous issue but didn't run, and notices when Wintour cuts a few spreads from the coming issue that represent USD$50,000 worth of work. She must know that she works for an enormous, ridiculous edifice. She must know that it's unsustainable, that her art form requires resources that only monarchies and this historically anomalous corporate media system can bring to bear. Anna and Coddington and Condé Nast are in a symbiosis to perpetuate a grand, dying art.
"High fashion" is a niche, like opera, regimented gardens, country dancing, &c., and getting niche-ier. Wintour says fashion is about what's next; does she know? The September Issue doesn't say.
# 03 Aug 2008, 10:33PM: Log:
L. Sprague de Camp's entertaining Lest Darkness Fall moves really fast. This is probably true even if you haven't just read a 900-page Neal Stephenson novel. I nearly mentioned Lest Darkness Fall in my brain candy recommendations to danah boyd, but fear it's not trashy enough.
William Ball's A Sense of Direction is fantastic and as soon as I return it to the library you should check it out. As I suspected, it has a mix of great inside baseball on directing plays (e.g., three pages on how to structure and practice curtain calls so that actors don't get their egos in a twist) and transferable advice on managing creative folk.
We learn in threes. The first step of learning is discovering; the second step of learning is testing; and the third step of learning is pattern-setting.
The actor will learn to relinquish his fear when he sees that the director never causes another actor to be frightened.
...a question from an actor is not a question. A question from an actor is an innocent bid to draw the director's attention to something unresolved. When the actor asks a question, a wise director doesn't answer the question. The answer to the question is not in the director; the answer to the question is in the actor. Answer the question by asking another question. Allow the actor to resolve the difficulty. He already has the best answer in mind before he asks the question.
Always begin rehearsal on time. There are some directors who like to gossip and joke and waste the first ten or twelve minutes. This awakens a sense of sloppiness in the actor and gives him the feeling that the work is not important.
For future reference, I'm also a fan of advice on pp 58-59, 66, 102-104, and 108 of the 1984 edition.
This weekend (among other activities) I went to a fun party, watched a lot of Babylon 5, saw a friend's wife and new baby, read the de Camp, ate Leonard's excellent sour cherry cobbler, walked around a lot, filed a bug or two on Miro, and rented movies to foist on my fellow jurors this last week of grand jury duty. All this and I still spent hours dinking around on the Web. So there, anxieties!
# 30 Jul 2006, 08:30PM: Marissa Mayer & I Both Use Pine:
Over the past week I've been to three different tech-related meetsup. I went to an EFF-NYC group, I helped host the Fog Creek open house, and I visited the Joel On Software discussion forum meetup in lieu of my traditional Saturday night SKP visit. It'll be a good yield if I get two lasting friends out of the whole trilogy. Today I played the hermit, rereading America: The Book and bits of Jane Eyre in between working on my column and playing Tetris with my husband.
I've spent half a year with Fog Creek now, and I know its strengths and weaknesses almost as well as I know my own. I've just downloaded a bunch of Audiofile songs and the music makes me pensive. I'm wondering what it'll take for me to become an IT leader with soul and cred.
Do I have to be a tall blue-eyed blonde with patents in artificial intelligence? Is it that or Fiorinadom? Is it possible to feel like a completely lost pioneer and a cliché sellout at the same time? That sort of thing.
By the way, the Joel on Software jobs board has been hopping lately, and my boss has been blogging at unusually high volume.
Anyway, back to my columns. One is about times I've been truly happy. I think the other is about practice, craftsmanship, and the tradeoffs one makes to live a satisfying life. But I'm not sure yet.
This work by Sumana Harihareswara 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 email@example.com.