Categories: sumana | Work:Wikimedia
# 10 Feb 2021, 12:08PM: New Wikimedia Code of Conduct:
"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."
And more of those efforts started and continued throughout Wikimedia spaces.
I left the Wikimedia Foundation in late 2014, but the work continued; in 2015 folks started a code of conduct for Wikimedia technical spaces that applies in both virtual and physical spaces.
Today I saw WMF's announcement that -- after a lot of research and consultation -- "The Universal Code of Conduct (UCoC) aims to provide a universal baseline of acceptable behavior for the entire Wikimedia movement and all its projects." The Board of Trustees has approved the new policy and now all the islands in the Wikimedia archipelago need to talk together about how to implement and enforce it.
Sometimes it's really nice to get to see your legacy.
# 01 Sep 2020, 01:45PM: Remedial Skills In Open-To-The-Public Working Groups:
I'm talking in this post about wikis, political clubs, open source projects, fanvidding exchanges -- any groups where people try to work together and are open to the public.
"No, what's that?"
Some people joining your groups don't know things you take for granted.
Years ago, while helping new applicants to Google Summer of Code get into working on (I think) MediaWiki or Zulip, I was talking with a person who was (at that time) a student in an Indian engineering college. He had run into trouble and was trying to debug a setup issue. He seemed to be asking for help but not systematically investigating what the problem might be.
So I said, let me give you some tips on troubleshooting. You've heard of the scientific method?
He said: no, what's that?
I gave him a link to the Simple English Wikipedia article on it -- and to the They Might Be Giants video for their song "Put It To The Test", on forming falsifiable hypotheses and testing them. I asked him to watch and read them and then tell me when he had done so. He did.
They Might Be Giants - Put It to the Test from They Might Be Giants on Vimeo.
I then said: so, you do that. You come up with a hypothesis for what might be the problem, and figure out how you would check to see if that is the case. You run the experiment, and you use the resulting data to refine your hypothesis -- if you're wrong, you try to come up with a new hypothesis. And then you either find and fix the problem, or if you get stuck, you at least have a bunch of data to give someone so they can help you better.
He said: THIS IS AMAZING! I'M GONNA USE THIS ALL THE TIME! And I was like IT IS! And then in a separate private conversation with colleagues, I was privately very angry with the educational system that had let him get that far without teaching him this!
[This is one of the experiences that led to me writing a fairly well-regarded blog post for new open source software contributors, on the scientific method, learning from and contributing to shared notes and logs, and self-reliance and interdependence.]
Some lessons here for you:
- Don't act surprised when people say they don't know something. Because (as I said a few years back) that’s just a dominance display. That's grandstanding. That makes the other person feel a little bit bad and makes them less likely to show you vulnerability in the future. It makes them more likely to go off and surround themselves in a protective shell of seeming knowledge before ever contacting you again.
- Some gaps you can remediate. Sometimes it's as quick as the explanation and links I used above. Sometimes it's more involved, as with providing free English tutoring to your internship applicants. Sometimes remediation takes a lot more work, and you may not have time to provide it; see my suggestions in "How to Teach And Include Volunteers who Write Poor Patches" which include some lower-effort options, like the section "Using their knowledge and curiosity to improve the project in other ways."
In open source projects, I think it's also okay to exclude unskilled people from a project based on "we do not have time to help them learn remedial skills, and this is not a suitable project for novices." If you are going to do this, explicit is better than implicit. You should try to forewarn contributors with explicit "not good for beginners/prerequisite skills are [list]" language in your README and CONTRIBUTORS files. And when you need to tell contributors that they aren't ready to participate in your group yet, you should offer them a redirect to a project more suitable to their skill level, you should take care not to insult them while redirecting, and you should tell them they'll be welcome back in the future after learning more of the prerequisites.
- The scientific method is still as kickass a cognitive tool as it has ever been. It's amazing and empowering!
Thanks to Dr Linda McIver for the conversation that spurred this post.
# 19 Apr 2019, 11:00AM: Design, and Friction Preventing Design Improvement, in Open Tech:
This month a Recurser I know, Pepijn de Vos, observed a concentration of high-quality open source software in the developer tools category, to the exclusion of other categories. With a few exceptions.
I understood where he's coming from, though my assessment differs. I started reflecting on those exceptions. Do they "prove the rule" in the colloquial sense that "every rule has exceptions," or do they "prove the rule" in the older sense, in that they give us an opportunity to test the rule? A few years ago I learned about this technique called "appreciative inquiry" which says: look at the unusual examples of things that are working well, and try to figure out how they've gotten where they are, so we can try to replicate it. So I think it's worth thinking a bit more about those exceptional FLOSS projects that aren't developer tools and that are pretty high-quality, in user experience design and robust functionality. And it's worth discussing problems and approaches in product management and user experience design in open source, and pointing to people already working on it.
FLOSS with good design and robust functionality: My list would include Firefox, Chromium, NetHack, Android, Audacity, Inkscape, VLC, the Archive Of Our Own, Written? Kitten!, Signal, Zulip, Thunderbird, and many of the built-in applications on the Linux desktop. I don't have much experience with Blender or Krita, but I believe they belong here too. (Another category worth thinking about: FLOSS software that has no commercial competitor, or whose commercial competitors are much worse, because for-profit companies would be far warier of liability or other legal issues surrounding the project. Examples: youtube-dl, Firefox Send, VLC again, and probably some security/privacy stuff I don't know much about.)
And as I start thinking about what helped these projects get where they are, I reach for the archetypes at play. I'll ask James and Karl to check my homework, but as I understand it:
Mass Market: NetHack, VLC, Firefox, Audacity, Inkscape, Thunderbird, youtube-dl
Controlled Ecosystem: Zulip, Archive Of Our Own
Business-to-business open source: Android, Chromium
Rocket Ship To Mars: Signal
Bathwater? Wide Open? Trusted Vendor? not sure: Written? Kitten!
The only "Wide Open" example that easily comes to mind for me is robotfindskitten, a game which -- like Written? Kitten! -- does one reasonably simple thing and does it well. Leonard reflected on reasons for its success at Roguelike Celebration 2017 (video). But I'd be open to correction, especially by people who are familiar with NetHack, VLC, Audacity, Inkscape, or youtube-dl development processes.
Design: Part of de Vos's point is about cost and quality in general. But I believe part of what he's getting at is design. Which FLOSS outside of developer tooling has good design?
In my own history as an open source contributor and leader, I've worked some on developer tools like PyPI and a linter for OpenNews, but quite a lot more on tools for other audiences, like MediaWiki, HTTPS Everywhere, Mailman, Zulip, bits of GNOME, AltLaw, and the WisCon app. The first open source project I ever contributed to, twelve years ago, was Miro, a video player and podcatcher. And these projects had all sorts of governance/funding structures: completely volunteer-run with and without any formal home, nonprofit with and without grants, academic, for-profit within consultancies and product companies.
So I know some of the dynamics that affect user experience in FLOSS for general audiences (often negatively), and discussed some of them in my code4lib keynote "User Experience is a Social Justice Issue" a few years ago. I'm certainly not alone; Simply Secure, Open Source Design, Cris Beasley, The Land, Clar, and Risker are just a few of the thinkers and practitioners who have shared useful thoughts on these problems.
In 2014, I wrote a few things about this issue, mostly in public, like the code4lib keynote and this April Fool's joke:
It turns out you can go into your
Wikimedia and pushback: But I also wrote a private email that year that I'll reproduce below. I wrote it about design change friction in Wikimedia communities, so it shorthands some references to, for instance, a proposed opt-in Wikimedia feature to help users hide some controversial images. But I hope it still provides some use even if you don't know that history.
init.cfg file and change the usability flag from 0 to 1, and that improves user experience tremendously. I wonder why distributions ship it turned off by default?
I wanted to quickly summarize some thoughts and expand on the
conversation you and I had several days ago, on reasons Wikimedia
community members have a tough time with even opt-in or opt-out design
changes like the image filter or VisualEditor or Media Viewer.
- ideology of a free market of ideas -- the cure for bad speech is more
speech, if you can't take the heat then you should not be here, aversion
to American prudishness etc., etc. (more relevant for image filter)
- relatedly "if you can't deal with the way things are then you are too
stupid to be here" (more applicable to design simplifications like Media
Viewer and VisualEditor)
- people are bad at seeing that the situation that has incrementally
changed around them is now a bad one (frog in pot of boiling water); see
checkbox proliferation and baroque wikitext/template metastasis
- most non-designers are bad at design thinking (at assessing a design,
imagining it as a changeable prototype, thinking beyond their initial
personal and aesthetic reaction, sussing out workflows and needs and
assessing whether a proposed design would suit them, thinking from other
people's points of view, thinking from the POV of a newcomer, etc.)
- relatedly, we do not share a design vocabulary of concepts, nor
principles that we aim to uphold or judge our work against (in contrast
see our vocabulary of concepts and principles for Wikipedia content,
e.g. NPOV, deletionism/inclusionism)
- so people can only speak from their own personal aesthetics and
initial reactions, which are often negative because in general people
are averse to surprise novelty in environments they consider home, and
the discourse can't rise beyond "I don't like it, therefore it sucks"
- past history of difficult conversations, sometimes badly managed (e.g.
image filter) and too-early rollout of buggy feature as a default (e.g.
VisualEditor), causes once-burned-twice-shy wariness about new WMF features
- Wikimedians' core ethos: "It's a wiki" (if you see a problem, e.g. an
error in a Wikipedia article, try to fix it); everyone is responsible
for maintaining and improving the project, preventing harm
- ergo people who feel responsible for the quality of the project are
like William F. Buckley's "National Review" in terms of their
conservatism, standing athwart history yelling "stop"
I haven't answered some questions: what are the common patterns in our success stories (governance, funding, community size, maintainership history, etc.)? How do we address or prevent problems like the ones I mentioned seeing within Wikimedia? But it's great to see progress on those questions from organizations like Wikimedia and Simply Secure and Open Tech Strategies (disclosure: I often do work with the latter), and I do see hope for plausible ways forward.
# (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.
# 10 Aug 2016, 10:17AM: Grief:
It's been a tough week. Wednesday of last week, I learned that Kevin Gorman had died. He was only 24 years old. I met Kevin through my work at the Wikimedia Foundation. He was a feminist activist who put a tremendous amount of energy into making Wikipedia a better resource for everyone. He added and improved articles, and he taught others, and he took on the emotional work of moderating and responding to voices that were arguing against feminists, and of fighting harassment (in all his communities). As he said on his user profile:
I dislike systemic biases; both those caused by our gender, racial, and geographic biases, and those caused by no abstract available bias and its kindred. One of my stronger interests on Wikipedia is making available online in a freely available format content that cannot be currently be found on the Wikimedia projects because of our systemic biases. I think that this is some of the most important work that can be done on Wikipedia at this time.
I had known that he'd been fighting various illnesses for some time, but I was still shocked to hear of Kevin's death; he was far too young. My condolences to his family and his friends and his many collaborators in free knowledge and justice. Kevin and I didn't have that many conversations but in every one I heard his deep passion for the work of improving our culture on all levels; he never ceased to be shocked at things that aren't right, and to channel that shock into activism and organizing. I will miss his dedication and I will remember his ideals.
He was only 24. As I handle more and more death I come to learn which deaths cause more painful griefs. I seem to believe, somewhere deep inside, that people younger than me really shouldn't die, that it breaks an axiom.
And then the next day I learned that Chip Deubner had died. Further shock and grief. I met Chip because we worked together at the Wikimedia Foundation; he was a desktop support technician, and the creator and maintainer of the audiovisual recording and conference systems, and then rose to manage others. And I can attest to his work ethic -- he cared about the reliability of the tools that his colleagues used to do their work, and he was that reliable himself, ready at a moment's notice to take on new challenges. He demonstrated a distinctive combination of efficiency and patience: help from Chip was fast, accurate, effective, and judgment-free. If anything, he was too reticent to speak up about his own frustrations. I was glad to see him grow professionally, to take on new responsibility and manage others, and I'm glad he was able to touch so many lives in his time on earth -- I only had a few memorable conversations with him, since he lived in the Bay Area and I mostly telecommuted from New York, but I know he enjoyed office karaoke and that many WMF folks counted him as a friend, and grieve him as one. He was a maintainer and a keeper and a maker of things, in a world that needs more such people. He will be in my thoughts and my prayers. (I wrote much of this in a guestbook that might decay off the web, so I'm publishing the words here too.)
Chip died of a brain tumor. He knew he was dying, months before, so he left his job and went back to his family home in Missouri to die. He died on July 9th. And I didn't know, and didn't have a chance to say goodbye, and I suspect this is because I am not on Facebook. Thus, for the first time, I am seriously considering joining Facebook.
Sometimes, in the stupor of grief, I find comfort in doing certain kinds of work -- repetitive, well-specified, medium-cognition work without much call for self-expression. So the article about Hari Kondabolu on English Wikipedia is a lot better now. I took it from 22 citations to 78, found an openly licensed photo to use, and even created the stub of a Telugu Wikipedia page. My thanks to the makers and maintainers of Citoid and the VisualEditor -- with these tools, it is a positive delight to improve articles, a far better experience than in 2011.
Hari Kondabolu turns his anger into comedy. I turn my grief into Wikipedia edits. We all paint with our pain. If we do it right and we're lucky, the stuff we make helps, even if it's just two inches' worth of help, even if it just helps ourselves.
# 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
# 19 Feb 2016, 06:10PM: Comparing Codes of Conduct to Copyleft Licenses (My FOSDEM Speech):
"Comparing codes of conduct to copyleft licenses": written notes for a talk by Sumana Harihareswara, delivered in the Legal and Policy Issues DevRoom at FOSDEM, 31 January 2016 in Brussels, Belgium. Video recording available. Condensed notes available at Anjana Sofia Vakil's blog.
Good afternoon. I'm Sumana Harihareswara, and I represent myself, and my firm Changeset Consulting. I'm here to discuss some things we can learn from comparing antiharassment policies, or community codes of conduct, to copyleft software licenses such as the GPL. I'll be laying out some major similarities and differences, especially delving into how these different approaches give us insight about common community attitudes and assumptions. And I'll lay out some lessons we can apply as we consider and advocate various sides of these issues, and potentially to apply to some other topics within free and open source software as well.
My notes will all be available online after this, so you don't have to scramble to write down my brilliant insights, or, more likely, links. And I don't have any slides. If you really need slides, I'm sorry, and if you're like, YES! then just bask in the next twenty-five minutes.
I will briefly mention my credentials in speaking about this topic, especially since this is my first FOSDEM and many of you don't know me. I have been a participant in free and open source software communities since the late 1990s. I'm the past community manager for MediaWiki, and while at the Wikimedia Foundation, I proposed and implemented our code of conduct, which we call a Friendly Space Policy, for in-person Wikimedia technical spaces such as hackathons and conferences.
I wrote an essay about this topic last year, as a guest post on the social sciences group blog Crooked Timber, and received many thoughtful comments, some of which I'll be citing in this talk.
I am also a contributor to several GPL'd pieces of code, such as MediaWiki and GNU Mailman, on code and non-code levels. And I am the creator of Randomized Dystopia, a GPL'd web application that helps you in case you want to write scifi novels about new dystopian tyrannies that abrogate different rights.
And I have been flamed for suggesting codes of conduct; for instance, one Crooked Timber commenter called me "a wannabe politician, trying to find a way to become important by peddling solutions to non-problems." Which is not as bad as when one person replied to me on a public mailing list and said, "Deja Vue all over again. I finally understand why mankind has been plagued by war throughout its entire history...." So maybe I'm the cause of all wars in human history. But I probably won't be able to cover that today.
II. The basic comparison
So let's start with a basic "theory of change" lens. When you're an activist trying to make change in the world, whether it's via a boycott, a new app, a training session, founding an organization, or some other approach, you have a theory of change, whether it's explicit or implicit. 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 pretty common theory of change among copyleft advocates and a couple of theories of change that are common to code of conduct advocates.
The GPL restricts some software developers' freedom (around redistributing software and around adding code under an incompatible license) so as to protect all users' freedom to use, inspect, modify, and hack on software.
The copyleft theory of change supposes that more people will be more free if we can see, modify, and share the source code to software we depend on, and so it's worth it to prohibit enclosure-style private takeovers of formerly shared code. Because in the long run, this will enable free software developers to build on each others' work, and incentivize other developers to choose to make their software free.
B. Codes of Conduct
Now, codes of conduct, antiharassment policies, friendly space policies: They restrict some people's behavior and require certain kinds of contributions from beneficiaries, so as to increase everyone's capabilities and freedom in the long run.
One pretty popular theory of change goes like this: we will make better software and have a greater impact if more people, and more different kinds of people, find our communities more appealing to work in. One thing making an unpleasant environment and driving away contributors, especially contributors with perspectives that are underrepresented in our communities, is hurtful misbehavior in community spaces. So we'll make the trade and say that it's worth it to restrict some behavior, in order to make the environment better so more, and more varied, people can do work in our communities, and thus make more free software and make it better.
And here's another related one, very similar to the one above, but focusing on the day-to-day freedom of community participants who are marginalized. If the constraint stopping me from, for instance, speaking in an IRC channel is that I strongly suspect I'll be harassed if they know I'm a woman, and that I don't have any reason to believe I can avoid or usefully complain about that harassment, how free am I to participate in that community? Is there perhaps a way to understand a certain level of safety as a necessary prerequisite to liberty?
I realize that this is probably the one room in the world where I have the highest chance of getting into a multi-hour "what does freedom mean" bikeshedding session, so I'm going to avoid focusing on the second model there and focus more on the first one, which emphasizes the end result of more free software.
So I am not assuming that everyone in this room is a copyleft advocate, but I am going to assume from this point forward that we in this room fundamentally understand the restrictive license argument, that we have a handle on the theory of change that it's operating on. And similarly, I'm sure there are people here who aren't so big on codes of conduct, but I'm going to assume that we fundamentally understand the theory of change behind that approach, regardless.
Now let's talk about similarities. Chris Webber calls both of these approaches "added process which define (and provide enforcement mechanisms for) doing the right thing." I agree. Without this kind of gatekeeping we see free rider incentives, on other people's software work and on other people's attention and patience and emotional labor.
They are written-down formalizations of practices and values that some community members think should be so intuitive and obvious that asking people to formally offer or accept the contract is an insult, or at least an unnecessary inconvenience. And so some people counterpropose sort-of-humorous policies, such as the "Do What the Fuck You Want to" software license and "don't be a jerk" codes of conduct.
They are loci of debate and fragmentation.
Some people agree to them thoughtfully, some agree distractedly as they would to corporate clickthrough EULAs, some disagree but click through anyway (acting in bad faith), some disagree and silently leave, some disagree and negotiate publicly, some disagree and fork publicly. Some people won't show up if the agreement is mandatory; some people won't show up UNLESS it's mandatory; some people don't care either way. And, by the way, good community management requires properly predicting the proportions, and navigating accordingly.
Both copyleft licenses and codes of conduct are approaches to solving problems that became more apparent along with different people realizing they have different expectations and needs, and consider different outcomes or processes to be "fair."
These kinds of codes and licenses usually cover specific bounded events and spaces or sites, and their scope covers interpersonal or public interactions. Codes of conduct usually don't cover conversations outside community-run spaces or the beliefs you hold in your head; open source licenses' restrictions usually kick in on redistribution, not use, so they don't constrain anything you do only on your own computer.
Neither one of these approaches can rely on self-enforcement. There is some self-enforcement of both, of course. There's a perception that -- as Harald K. commented on my blog post -- "licenses more or less police themselves (or in extreme instances, are policed by outsiders) whereas codes of conduct need an internal governing structure, a new arena where political power can be exercised." My personal understanding, which I share with people like Matthew Garrett, is that there's a ton of license-breaking happening, and we need to support existing organizations like the Software Freedom Conservancy to police that misbehavior and litigate to defend the GPL. As Conservancy head Karen Sandler points out in her December essay "From a lawyer who hates litigation", "I've seen companies abuse rights granted to them under the GPL over and over again. As the years pass, it seems that more and more of them want to walk as close to the edge of infringement as they can, and some flagrantly adopt a catch-me-if-you-can attitude." And you see enough individuals in our communities acting similarly that I don't think I need to belabor this point; codes of conduct are much more productive when they're actually, you know, enforced.
And both copyleft licenses and codes of conduct restrict freedom regarding certain acts, over and above what is restricted by the law, in the interest of a long-term good, which can in both cases be construed as greater freedom. As Belle Waring says to one skeptic in the Crooked Timber comments, paraphrasing their argument: "part of your reasonable resentment is, 'I don't want to be forced to do freedom-restricting things in support of a very uncertain outcome, just because the final proposed outcome is a good one.'" I will go into that bit of argument later.
But these kinds of agreements are different on a few different axes, which I think are worth considering for what they tell us about open stuff community values and about our intuitions on what kinds of freedom restrictions we find easier to accept.
One is that many codes of conduct focus on in-person events such as conferences, rather than online interactions. Many of the unpleasant incidents that caused communities to adopt CoCs -- or that communities see as "let's not let that happen here" warning bells -- happen at face-to-face events. And face-to-face spaces have a much longer history and context of ways of dealing with bad behavior than do online spaces. After all, a pretty widespread reading of the core function of government and law enforcement is that they keep Us Good Guys safe by stopping The Bad Guys from committing face-to-face (or knife-to-face or chair-to-face) assault.
But there's another axis I want to explore here: whether the behavior constraint feels like a contract or whether it feels like governance. Of course, we toss around phrases like "the social contract" and use the metaphor of contract to talk about the legitimacy of government, but to an ordinary citizen, contracts and governance feel like significantly different things. To oversimplify: to a non-lawyer like me, something that feels like a contract formalizes a specific trade, something discrete and finite and a bit rare. A copyleft license feels that way to me; it specifies that if I distribute a certain artifact -- which is something I would only do after some amount of thought and work -- I then also undertake certain obligations, namely, I must also redistribute the software's source code, under the same license. And, notwithstanding edge cases, it is often easy to examine the artifact, follow a decision procedure, and determine that I have complied with the terms of the license. If I meant to comply in the first place.
On the other hand, when we make rules constraining acts, especially speech acts, it feels more like governance.
Codes of conduct serve as part of a community's infrastructure to fulfill the first duty of a government — to protect its citizens from harm — and in order to make them work, communities must develop governance processes. That is to say, "governance" is what we call it when we're explicit about who gets to make and implement rules that affect everyone in a community, and how we choose those people or get rid of them. And a governance body does not necessarily have to be a legal entity. For instance, in MediaWiki governance, there's an architecture committee that decides on large technical architectural changes, and it has no standing in the eyes of the United States government.
It takes work to evaluate whether actions have complied with rules, and that work might require asking questions of suspects, bystanders, and targets. Enforcing a code of conduct, even a narrowly scoped anti-harassment policy, often requires that someone act on behalf of a community to do this, and to implement the outcome -- be it informed by retributive, rehabilitative, transformative, or some other justice model. And it feels more like governance than contract to me if a rule applies to actions I take many times a day without deliberate planning -- such as saying something in my project's live internet chat room.
One way of thinking about this is: is there some kind of authority that the community acknowledges as having legitimate power over everyday behavior, over and above existing government with a capital G? Because, again, licenses affect certain coding and architectural decisions, but they don't preclude, for instance, everyday discussion. In fact, the social and digital infrastructure it takes to make robust and usable software, including our bug reports, our automated tests, our conversation on mailing lists, and so on, is often not covered by any particular open license -- if it were, maybe we'd be seeing a different level of pushback even from developers who are happy with copyleft as applied to their code.
F. Shortcomings of the contract model
But I think another interesting thing that happens when you compare a governance model to a contract model, regarding approaches we take to improving behavior in our communities, is seeing how governance wins. It takes a lot of work, but it has a lot of advantages.
Contracts are binary where ongoing dialogue and governance can be more flexible and responsive. If I were going to be really annoying I would compare them to compiled bytecode and to interpretable scripts. Contracts have to sort of self-contain the tests for what the contract permits, mandates, and prohibits, whereas governance mechanisms and bodies can use more general standards, which might change over time. To quote one of the commenters on my essay, Stephenson-quoter kun:
contracts explicitly restrict acts which are simply unpardonable -- not sharing the source code to your modified version of a GPL-licensed project, sexually assaulting someone at a conference -- because everyone agrees that those things are wrong and we feel confident that we can agree up-front that there can never be any extenuating circumstances in which those things are actually OK. Governance, however, can serve to 'nudge' people away from bad behaviours – poor coding standards, rudeness on mailing lists -- by giving us a standard to measure those things against without enumerating every possible violation of the standard. A governance procedure can take context into account, and is much more easily subject to improvement and revision than a contract is.
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: 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.
Changing these habits requires a change of culture, and that kind of deliberate change in culture requires people who take up the responsibility in stewarding the culture.
And a governance approach has a lot more ability to affect culture than a contracts-only approach does.
2. Contracts give us an illusion of equality and self-containedness
As Tim McGovern said in the comments to my Crooked Timber post:
contracts have taken over as a primary way of negotiating relationships: a EULA is a replacement for a legal understanding of the relationship between two parties who are doing business. I don't, in other words, sign a EULA when I buy a pair of socks -- or even when I buy a car (Teslas excepted) because the purchase relationship is legally defined; even the followup on what can and can't be in your warranty is legally defined. But companies would rather be bound by an agreement they write than a body of law based on either commonlaw or constitutional concepts, or legislation.
Contracts presume an equality between the parties; in theory, both sides can take a breach of contract to court. In practice, of course, a EULA is a contract that masks radical inequality in power between the parties.... Governance requires wrestling with equality in a real way, on the other hand, and voluntarily submitting to an authority constituted in some fashion (over time, by people, etc.), as opposed to preserving a contractual illusion of equality.
3. Contract pretends you have choices
I recommend that, if you haven't, you check out the article "Mothering versus Contract" by Virginia Held, from Beyond Self-Interest in 1990. It suggests that perhaps we should fundamentally conceive of our interactions with others as following a paradigm of motherhood rather than of contract -- one truth this approach acknowledges is that by default most interactions in your life are opt-out rather than opt-in, if there's any opting or choice at all.
Yes, there's the freedom to fork. But realistically, if you want to get things done, you have to collaborate with others, and we need to accede to other people's demands, in terms of interface compatibility, learning and speaking fluent English, and all sorts of other needs. A FLOSS project with a thriving ecology of contributors is far more valuable than a nearly identical chunk of code with only a couple of voices available to help out, and thus the finite amount of human attention limits our ability to make effective forks. We're more inderdependent than independent, and acknowleding that as a fundamental truth complicates the contracts-y libertarian narrative potentially beyond usefulness.
I hope that my analysis helps give some vocabulary and frameworks for understanding arguments around these issues, and that we can use them to develop more effective arguments.
A. Freedom tradeoff comparisons
The first step might be — if you're trying to get your community to adopt a code of conduct, you might benefit by looking at other freedom-restricting tradeoffs the community is okay with, so you can draw out that comparison.
Or with UX (user experience) -- design is the art of taking things away, and when you're advocating for better user experience, which often involves reducing the number of visible ways to do things, consider comparing your approach to one of the freedom tradeoffs that your interlocutor is already okay with, such as the fact that your community has standardized on a single version control system. A single way for that kind of user to interact.
And if you're trying to build a code of conduct consensus in your community, it might help to start by talking, not about day-to-day beavior, but about artifacts that people think of as artifacts. Talk about the things we make, like slide decks for presentations, articles on your wiki. That can get people on the same page as you, in case they're not yet ready to think of the community itself as an artifact we make together.
C. Theory of change
If you're an advocate for a new initiative, licensing, code of conduct, or something else, understand your own theory of change, and build mental models to help you understand the people who disagree with you. Understand what part of the theory of change they disagree with, and gather data to counter it.
And, incidentally, this lens will also help you appreciate other complementary approaches that will help you achieve your goals. As Mike Linksvayer says: "Of course I think that copyleft advocates who really want to ensure people have software freedom rather than just being enamored of a hack should be always on the lookout for cheaper and/or socialized enforcement (as implied above, control of distribution channels that matter, and state regulation)."
So why might people oppose codes of conduct? Here are a few ideas:
- they might disagree on whether the goal makes sense
- or on whether codes of conduct, when enforced, make the situation more conducive to diverse populations and to net growth in community -- have your research close at hand!
- or on what the biggest problems you're facing are, and whether they're community recruitment and retention
As Chris Webber notes, "there's an argument that achieving real world social justice involves a certain amount of process, laying the ground for what's permitted and isn't, and (if you have to, but hopefully you don't) a specified direction for requiring compliance with that correct behavior." The addendum is that, as Alberto Brandolini said "The amount of energy necessary to refute bullshit is an order of magnitude bigger than to produce it."
So part of the mental model you're trying to understand is what the person you're arguing with is trying to maximize, and another part is whether you agree on how to maximize it.
Paul Davis, the Ardour BDFL, commented on my Crooked Timber post, "The dilemma for a mid-size project like mine is that the overhead of developing and maintaining a CoC seems like just another thing to do amidst a list of things that is already way too long, and one that addresses a problem that we just don't have (yet)." He said he's more worried about technical, architectural decisions causing developer loss.
So, for instance, you could argue with Paul: what genuinely causes developer loss? And what priorities should you have, given your goals?
D. A fresh set of governance needs and questions
CoC adoption drives the adoption of explicit governance mechanisms, as Christie Koehler has recently explored in depth in her post "The complex reality of adopting a meaningful code of conduct" .... but we have many open questions that the legal and policy community within free and open source could really help with.
For instance, it's great that we have people like Ashe Dryden and organizations like Safety First PDX helping develop standards and advising organizers on developing and enforcing codes of conduct, but should we actually be centralizing this kind of reporting, codification and enforcement across the FLOSS ecosystem? Different subcommunities have different needs and standards, but just as OSI has helped us stave off the worst possibilities of license proliferation, maybe we should be avoiding the utter haphazardness of Code of Conduct proliferation.
And -- given how interconnected our projects are -- what if single open source projects are the wrong size or shape or scope for this particular aspect of stewardship and governance?
I'd very much appreciate thoughts on this from other folks in future devroom talks or blog posts -- if you tell me this is the kind of thing we talk about on the FLOSS Foundations mailing list then maybe I'll have to bite the bullet and go ahead and subscribe.
IV. Other thoughts + Conclusion
A. Comments on my CT piece
The comments on my Crooked Timber piece had many fine insights, on enforcement, culture, exit, voice and loyalty, fairness, and the consent of the governed. They're worth reading.
B. Hospitality to liberty spectrum
In addition to the contract-governance contrast, I think it's also worth thinking about the spectrum of liberty versus hospitality. The free software movement really privileges liberty, way over hospitality. And for many people in our movement, free speech, as John Scalzi put it, is the ability to be a dick in every possible circumstance. Criticize others in any words we like, and do anything that is not legally prohibited.
Hospitality, on the other hand, is thinking more about right speech, just speech, useful speech, and compassion. We only say and do things that help each other. The first responsibility of every citizen is to help each other achieve our goals, and make each other happy.
I think these two views exist on a spectrum, and we are way over to one side, the liberty side, as a community, and moving closer to the middle would help everyone learn better and would help us keep and grow our contributor base, and help make it more diverse. And to the extent that comparing codes of conduct to copyleft licenses helps some people put new initiatives in perspective, balancing the relationship between rights and responsibilities, perhaps that can also help shift our culture into one that's more willing to be hospitable. I hope.
C. This feels like a potentially insoluble problem
William Timberman said in Crooked Timber comments, "how does a socialist persuade a libertarian that coherence and the common good is sometimes a legitimate constraint on individual freedom?" And the answer is that I don't know, but I hope it is a soluble problem, and I hope I've opened up some avenues for exploration on that topic. Thank you.
# 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.
# 05 Mar 2015, 04:16PM: The Triumph Of Outreachy:
Right now, y'all can apply to the Free and Open Source Software Outreachy internships, formerly OPW -- the deadline is March 24th. Copy the flyer below to spread the word! And March 24th is also the deadline for your organization to sponsor internships -- if your employer has deep pockets, use this template to ask them for some cash.
As of last month, Outreach Program for Women is now Outreachy, and Outreachy will move from the GNOME Foundation to being a member project of Software Freedom Conservancy on May 1. This step makes sense, as Outreachy serves the entire FLOSS community and SFC is specifically set up to provide financial, legal, and administrative support to member projects, whereas GNOME Foundation's core goal is to advance GNOME. I'm grateful to the GNOME Foundation for launching and supporting OPW as it grew!
Celebrating in detail
Outreachy has now taken several pretty wow steps over the course of its 9-year history (see the original announcement and a 2009 retrospective). This is not complete, but:
- from one-time to repeating, and then to consistently running twice a year
- from only mentoring GNOME projects to mentoring GNOME + Twisted, and then to mentoring for dozens of FLOSS projects (and Sarah Sharp, the original Linux org admin, handing off that responsibility and coming to co-administer Outreachy as a whole)
- from 6 participants in the first round to 44 in the round that's ending in a few days
- from Hanna Wallach and Chris Ball volunteering to run it, to Marina Zhurakhinskaya running it as a volunteer, to Outreachy being part of Zhurakhinskaya's job, so candidates, interns, mentors, and admins get more consistent support and leadership
- from GNOME oversight/administration to the Software Freedom Conservancy
- adding a travel fund, explicitly documenting it and encouraging participants to use it
- adding a career development advisor (me at first, then delegated to someone with more career advising experience)
- from language of "women/females only" that was potentially trans-exclusive to more inclusive language ("anyone who was assigned female at birth and anyone who identifies as a woman, genderqueer, genderfluid, or genderfree regardless of gender presentation or assigned sex at birth")
- from "Women's Summer Outreach Program" through various name permutations :)
- from fighting only sexism to fighting other oppressions as well, by partnering with Ascend
- from zillions-of-emails application processes to a unified web app
- weathering a trumped-up controversy about a temporary GNOME finances problem
- adding the full variety of software engineering tasks as potential projects, e.g., design, release management, translation, etc., not just coding
- adding a mentored first contribution as an application step (other open source internship programs are copying this)
Empowering everyone involved
When I saw, in mid-2012, that OPW had included a non-GNOME project, and that OPW had succeeded in getting the percentage of women at GNOME's yearly conference from ~4% (2009) to ~17% (2012), I decided I wanted Wikimedia Foundation to participate. I sought Zhurakhinskaya out at that year's Google Summer of Code Mentor Summit, my boss in tow. Zhurakhinskaya was already looking for me. We instantly agreed that WMF should participate. My boss, Rob Lanphier, trusted my judgement and gave me the budget to fund multiple interns. Zhurakhinskaya helped us decide to expand our contribution.
In the end, we got six interns for that round, thanks to WMF's contribution and to money Zhurakhinskaya and Karen Sandler got from Google's Open Source Programs Office. Wikimedia has kept on mentoring via OPW/Outreachy, several have stuck around as volunteers, and WMF has hired at least four alumnae as contractors or employees. Outreachy works to help recruit and retain technical contributors, who have more diverse perspectives, more than the event-based or publicity-only initiatives we'd tried before.
OPW helps oppressed people do things they didn't think they could do -- and thank you Outreachy for helping WMF do something we didn't know we could do. :)
Congratulations! And here's video of "The Outreach Program for Women: what works & what's next", a talk that Liz Henry and I gave last year at Open Source Bridge.
# 19 Dec 2014, 01:53PM: Join Me In Donating to Stumptown Syndicate and Open Source Bridge:
I'm donating up to $15,000 to the Stumptown Syndicate -- depending on how much you are willing to match by December
29th Updated: 31st at 1:30pm Pacific Time. Please join me by donating today and doubling your impact!
Updated 31 December: We made it!
I really love Open Source Bridge, which Stumptown Syndicate runs. I've spoken there every year since 2010, and it's the tech conference that has imprinted itself on my heart -- informative technical talks, inspiring ideas that help me improve how I do my work, and belly laughs and great food (see right). I love that I can tell friends "Come to OSB!" without having to add "but watch out for..." the way I do with so many other conferences. Hospitality lives in the DNA of Open Source Bridge, so it's a place where people from different projects and backgrounds can share their experiences as equals. Wikimedians, Linux developers, Mac users, designers, hardware hackers, managers, knitters, teachers, and everyone from Fiona Tay to Ward Cunningham swap tips and inspire each other. I especially appreciate that Stumptown Syndicate curates an inclusive all-genders tech conference where I'm never the only woman in the room; in fact, in 2014, half the speakers were women.
I don't live in Portland, so I don't get to benefit directly from most of Stumptown Syndicate's events. But they document their processes to make a playbook, and they built and improve open conferenceware and an open source shared calendar, all of which contribute to the infrastructure of inclusion for everyone to reuse.
With some more cash in the bank, the Syndicate can look at adding childcare to its events, improving access and scholarship options for low-income participants and guest speakers, and improving the audiovisual experience (with faster video processing or transcripts/captioning).
So: I'll match donations starting today and ending on December
29th 31st at 1:30pm Pacific Time, whether corporate or individual, one-time or recurring memberships. Please donate now to help raise $30,000 for Stumptown Syndicate and Open Source Bridge!
Updated 31 December: We made it!
# 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.
# 26 Sep 2014, 07:17PM: The Continuing Adventures (Transitioning From Intern To Volunteer):
By now dozens of women have stepped into open source via Outreach Program for Women, a paid internship program administered by the GNOME Foundation. I recently asked several of them whether they had been able to transition from intern to volunteer.*
Are you succeeding at continuing to volunteer in your
open source project? Or are you running into trouble? I'd love to know
how people are doing and whether y'all need help.
When you were an OPW intern, you had a mentor and you had committed to a specific project for three months. Volunteering is freer -- you can change your focus every week if you want -- but the training wheels are gone and you have to steer yourself.
(I bet Google Summer of Code alumni have similar experiences.)
I got several answers, and in them I saw some common problems to which I suggest solutions.
- Problem: seems as though there are no more specific tasks to do within your project. Solutions: ask your old mentor what they might like you to do next. If they don't respond within 3 days, repeat your question to the mailing list for your open source project. Or switch to another open source project, maybe one your friends are working on!
- Problem: finding the time. Solutions: set aside a weekly appointment, just as you might with a therapist or an exercise class. Pair up with someone else from the OPW alum list and set yourself a task to complete during a one-hour online sprint! Or if you know your time is being eaten up by your new job, set yourself a reminder for 3 months from now to check whether you have more free time in December.
- Problem: loneliness. Solutions: talk more in the #opw chat channel on GNOME's IRC (irc.gnome.org). Use http://www.pairprogramwith.me/ and http://lanyrd.com/ and https://lwn.net/Calendar/ to find get-togethers in your area, or launch one using http://hackdaymanifesto.com/ and http://meetup.com/.
Problem: motivation. Solutions: consider the effects you're having in the world. Or focus on the bits of work you enjoy for their own sake, whatever those are. Or teach others the things you know, and see the light spark in their eyes.
These are tips for the graduating interns themselves; it would be good for someone, maybe me, to also write a list of tips for the organizers and mentors to nurture continued participation.
* OPW also provides a list of paid opportunities for alumni.
# 15 Sep 2014, 08:57AM: The next Tor, role models, and criticism: the future I want:
I'm writing these words while I ride the New York City subway. I love
the subway because my fellow riders look like the world. I'm rarely the
only woman and I'm never the only nonwhite person in the car. We're
young and old, all genders, all nationalities, temporarily able and not
(although our stations fail at accessibility a lot), and speaking dozens
We'll know we've won when open source looks like this.
It doesn't yet. But we need it to. It is because I know how much
potential technology has to shape our world that I know it is essential
that the people who shape that technology represent that world,
represent the best that world has to offer. What will it look like when
open source reflects diversity of talent?
New tools we make -- the next git, the next WordPress, the next Tor --
will make inclusive assumptions from the start. They'll allow users to
change their names and identify outside the gender binary. They'll help
users block harassers from contacting them. Their FAQs will use
When a junior programmer looks around for a way to make her mark, she'll
see people who look like her doing lots of cool stuff in open source --
starting projects, leading them, arguing over architectural decisions,
joking about absurdly bad ideas, showing off their accomplishments at
conferences, teaching and learning, and generally having a good time.
She'll dip her toe into online discussions, and the hackers already in
the group will use her preferred pronoun, correctly, or ignore her
gender if it isn't relevant to the discussion. She will see so easily
how this community could include her that she will only notice in
retrospect the moment she fell in.
As a gag, people who have been doing open stuff for decades will send
their less senior friends links to the Timeline
of Incidents, anticipating their "they did WHAT?!" replies. A new
generation of activists will look back at the Ada Initiative and keenly
observe what we missed, what we got wrong, where we were too complicit
in the intersecting oppressions endemic to our society, too much of our
I want this future so much. I may not ever get to see it. But I can see
us getting closer. I'm on the board of directors of the Ada Initiative,
and I've been an advisor since 2011. In that time I've seen the Ada
Initiative's unique work changing the conversation, building the
infrastructure of inclusion, and moving us closer to -- well, to a world
that doesn't need us any more.
Please help: donate now.
# (10) 12 Sep 2014, 11:54AM: I'm Leaving My Job At The Wikimedia Foundation:
(Music for this entry: "You Can't Be Too Careful" by Moxy Früvous; "Level Up" by Vienna Teng; "Do It Anyway" by Ben Folds Five; "Teenagers, Kick Our Butts" by Dar Williams.)
I've regretfully decided to leave the Wikimedia Foundation, and my last day will be September 30th.
I've worked at WMF since February 2011, so I've seen the Foundation grow from 70 to 214 people. It's the best job I've ever had and I've grown a lot. And my team and my bosses are tremendously supportive. In April I summarized my work achievements from the past four years and I remain proud of them. Most recently, I'm proud of co-mentoring Frances Hocutt, who's about to turn her energies to Growstuff API development (with help from your donations).
But I want to redefine myself and grow in new directions, as a maker and activist. Wikimedia has 13 years of legacy code and thousands of vocal stakeholders, and WMF has one office, in San Francisco. I'm a junior-level developer (I'm a much better software engineer than I am a coder) but don't want to move to San Francisco, where we (understandably) prefer to have junior devs onsite. And I'd like to try out what it's like to get better at making software, to have more of a blank slate and perhaps less of a public spotlight, to work face-to-face with a team here in New York City, and to exclude destructive communication from my life (yes, there's some amount of burnout on toxic people and entitlement). One of the things I admire about Wikimedia's best institutions is our willingness to reflect and reinvent when things are not working. I need to emulate that.
I remain on the board of directors of the Ada Initiative, which aims to close the gender gap in Wikimedia and other open culture/source projects. (Please donate.) And I don't see any way I could stop being a Wikimedian and pursuing the mission. You'll see me as User:Sumanah out on the wikis.
After I wrap things up at Wikimedia Foundation, I'll be privileged to spend six weeks at Hacker School, concentrating on learning how to crank out websites and fiddling with web security, and then in late November I'll be meeting other South Asian geek feminist women at AdaCamp Bangalore. Aside from that I'm open to new opportunities, especially in empowering marginalized groups via open technology.
"Level Up" by Vienna Teng. ("If you are afraid, come out.") And heck, why not, a Kira Nerys fanvid I love, set to "Shake It Out" by Florence + The Machine. ("So tonight I'm gonna cut out and then restart.")
# (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.
# (4) 30 Jul 2014, 11:47AM: Here Are Some Grants You Could Apply For:
When I tell people about grants they could get to help them work on open source/open culture stuff, sometimes they are surprised because they didn't know such grants existed. Here are some of them!
Grants with deadlines:
Grants that you can apply for anytime:
- Urgent: August 1st is the deadline for the Knight Prototype grant which "helps media makers, technologists and tinkerers take ideas from concept to demo. With grants of $35,000, innovators are given six months to research, test core assumptions and iterate before building out an entire project."
- Also coming up fast: August 4th is your deadline to apply for the Open Society Fellowship, which gives you about USD$80,000-100,000 to work on a project for a year.
- September 30th is the deadline for Individual Engagement Grants applications. IEG projects "support Wikimedians to complete projects that benefit the Wikimedia movement. Our focus is on experimentation for online impact. We fund individuals or small teams to organize, build, create, research or facilitate something that enhances the work of Wikimedia's volunteers." The maximum grant request is USD$30,000.
- If you're a woman working on a tech project that will benefit girls and women in tech, check out The Anita Borg Systers Pass-It-On (PIO) Awards, which range from USD$500-$1000. The next round opens for applications on August 6th.
- It looks like November 2014 is the deadline to apply for the Drupal Community Cultivation Grants: "to support current and future organizers and leaders of DrupalCamps, Drupal Meetups, Drupal Sprints, Drupal coalitions, and other creative projects that are spreading information within the Drupal community and educating individuals outside the community about Drupal... Grant awards will range from several hundred to several thousand dollars per project".
- Wikimedia project and event grants, which "support organizations, groups, and individuals to undertake innovative, mission-aligned projects that benefit the Wikimedia movement." Grants usually vary from USD$500-50,000.
- Mozilla makes grants ranging from USD$1,000-300,000 "to people and organizations we know, who are either working with us or in a closely related field" (specifically: Learning & Webmaking; Open Source Technology; User Sovereignty; Free Culture & Community).
- "The Python Software Foundation welcomes grant proposals for projects related to the development of Python, Python-related technology, educational programs and resources." It looks like they've granted amounts from about USD$500-10,000 in the past. If you want to run a Python-related hackfest/sprint, there's money for that too, to help with food, venue, and so on, for up to USD$300.
- The Sunlight Foundation offers grants USD$5,000-10,000 to open source projects that "make government more open and accessible".
- The Open Technology Fund makes grants "to support innovative efforts and new ideas from individuals and organizations globally defending freedom of expression online" and basically considers new "concept notes" (lightweight proposals) every two months. They are interested in making grants around USD$75,000-500,000.
- Wikimedia's "Travel & Participation Support funds Wikimedians to actively represent Wikimedia at events around the world." I believe most grants are for a few hundred or a few thousand dollars, to cover "travel, accommodation and incidental expenses." Many Wikimedia-specific events have their own scholarship programs as well to subsidize participation -- I know that a lot of open stuff events (e.g., PyCon, WisCon) also offer financial assistance in case you need it to get to the event.
- Edited (on August 4th) to add: TPF (The Perl Foundation) also offers grants for a variety of work that would benefit Perl in some way. TPF evaluates applications every two months, i.e., January, March, May, July, September and November. "Each grant is budgeted individually, according to the duration of the award, the recipient's financial needs, and projected expenses (travel, equipment, etc.) A typical amount for a 12-month grant involving some domestic US travel would be US$80,000." Past grants have been as low as a few hundred dollars.
This partially overlaps with the list that OpenHatch maintains on its wiki (and which I or someone else ought to update), and I have not even scratched the surface really. So anyway, yes, if you need some financial help to do better or more work in open stuff, take a look!
# (3) 21 Jul 2014, 08:56AM: The Art Of Writing In The Dark:
Wordsworth tells us that his greatest inspirations had a way of coming to him in the night, and that he had to teach himself to write in the dark that he might not lose them. We, too, had better learn this art of writing in the dark. For it were indeed tragic to bear the pain, yet lose what it was sent to teach us.
-Arthur Gossip in "How Others Gained Their Courage", p. 7 of The Hero In Thy Soul (Scribners, 1936), quoted on p. 172 of The Art of Illustrating Sermons by Dawson C. Bryan (Cokesbury Press, 1938), which was in my father's library. He died in late July 2010.
He had a crowded office full of books, which I described in "Method of Loci", and he was enthusiastic about sharing his knowledge, as I mentioned in my eulogy for him. If you didn't know me four years ago and weren't reading my blog, go take a look; they're worth a read. (Most of Cogito, Ergo Sumana for the second half of 2010 is pretty raw and emotional, a lot of the writing-in-the-dark that Wordsworth described.) I'm a lot like my dad. The first copyediting I ever did was for the prayer ritual guides my father wrote, which, of course, had footnotes. I am so glad he was writing for Usenet and the web at the end of his life, getting to enjoy hypertext and linking. One of the last books he wrote was a set of essays about sparrows in literature and the word "sparrow." I think I grok the joy of that more now than I did in 2010.
And I'll repeat the anecdote I heard from a guy who came to offer his condolences after my dad's death, and who told me something about my dad's scholarship. Dad had been tapped to update a Sanskrit reference text, and the publisher told Dad he only had to check sources for the entries he was adding or updating, the diff from the previous edition. Dad didn't think this was good enough, and meticulously checked or found original sources for every entry in the book. This fairly thankless task will help numberless future scholars. Most won't know. We joke about "citation needed" but my dad stepped up and did something about it. You can tell how proud I am, right?
On my insecure days I am terrified that I am not making a difference. It calms, heartens, and sustains me to see other people move on different vectors because of my influence - billiard balls on new trajectories because I was on the baize too - or even completely new endeavors springing up from seeds I scattered. And the chain of attribution is what grounds me. I honor those whose work I reuse, and I am honored when others credit me. Accurate citations make a constellation connecting the filaments of light we lit to dispel the darkness. Accurate citations are an act of love.
I am a sentimental person and I wear my heart on my sleeve. I think it would clutter up the edit summaries on Wikipedia if I included a "<3" in each one, every time I added a citation. But you should imagine they're there anyway.
# 07 Jul 2014, 10:10AM: If You Log In To Wikipedia You Can Customize A Bunch Of Stuff:
I bet most people reading this often read Wikipedia articles but don't log in. That's fine. I love that you don't have to register to read or edit. But here are a few reasons you should try logging in:
- Read how you want. You can fiddle with a bunch of preferences you didn't even realize you wanted. Suppress display of the fundraiser banner. Disable the suggestions dropdown list for the search box. Choose a different skin (page style) that emphasizes information density. Remove images and background while printing.
- Beta features. If you log in, you can try out new improvements early. Right now, on English Wikipedia, the beta features include "hovercards" (when you hover over a page link, a little summary pops up) and better search.
- Language and font settings. If you're multilingual, note that you can change what language you want all the framing text to be in, on any Wikimedia site. For instance, I can go to Russian Wikipedia and change my preferences to English. All the articles are still in Russian, but stuff like the Random Page link is labelled in English, so I can navigate easier.
- Mobile stuff. If you read Wikipedia via your phone's or tablet's browser, you can look for Settings in the site menu and tap to turn on Beta. That'll give you a preview of upcoming improvements.
- The VisualEditor. For most Wikipedia editing, the new what-you-see-is-what-you-get interface is more intuitive than messing around with wikitext. So if you rarely hit Edit, it'll be way easier for you if you use VisualEditor. On English Wikipedia, if you log in, you can turn on VisualEditor by checking its checkbox in your Beta features.
- Better privacy. If you improve a Wikipedia page while you're logged in, the site associates that edit with your username. If you do it without logging in, the edit is associated with your IP address. And people can tell a lot more from an IP address than they can from a username.
- Better trust. If you end up editing, using your username means other people will have an easier time thanking you, suggesting ways to improve your work, cutting you slack when you make a mistake, and scheming with you to improve particular articles or topics. You can build a reputation when you log in.
So try logging in!
# 30 May 2014, 01:50AM: Citations and Links for My WCUSA Keynote:
In a few hours, I'm giving the opening keynote address at Wiki Conference USA. Here are some links and citations for sources I'll be referring to.
- Engineering learning styles and educational psychology research by Mel Chua.
- My PyCon 2014 poster session (see the poster "Be A Better Mentor: What Hacker School Taught Me About Community Mentoring").
- Valerie Aurora's "Diversity initiatives that worked in other open communities" session from the 2013 Wikimedia Diversity Conference. See also her slides and the Ada Initiative blog post summarizing the talk.
- Mary Gardiner's opening keynote at Wikimania two years ago. In "Fostering diversity – not a boring chore, a critical opportunity", she gave examples of how other movements increased diversity and gained from it, and told the audience what to do to improve diversity within
- The "Generation Wikipedia" project that Keilana and Ocaasi proposed ran into some difficulties and couldn't get started but seemed really promising on this front.
- "Bringing More Women to Free Software: What's Working for Us", Karen Sandler's presentation Friday afternoon at Wiki Conference USA.
- The Hacker School manual including the four social rules.
- "How It Works" (xkcd #385).
- How Learning Works: Seven Research-Based Principles for Smart Teaching, by Susan A. Ambrose, Michael W. Bridges, Michele DiPietro. Jossey-Bass, 2010.
- Women's Ways Of Knowing: The Development Of Self, Voice, And Mind by Mary Field Belenky, Blythe Mcvicker Clinchy, Nancy Rule Goldberger, and Jill Mattuck Tarule. Basic Books, 1997 (10th Anniversary edition).
- "It's not 'them' — it's us!" by Betsy Leondar-Wright.
- John Scalzi's formulation that some people's articulation of liberty is "I must be allowed to be a dick in every possible circumstance."
I'll link to video, transcript, and so on after they're up.
Edited 31 May to add: I borrowed my introductory acknowledgment of place from N.K. Jemisin and very slightly modified it.
Edited 5 June to add: The transcript and an audio recording are now up - thank you to Jeremy Baron for helping me get the audio. I paid Katherine Nehring for the transcription and I recommend her to you as well.
Retroactive talk title: "Hospitality, Jerks, and What I Learned".
Edited again on June 5th to add: Now the video is up!
# (3) 13 May 2014, 03:24PM: Dipping My Toes Into PHP:
This week, alumni like me get to spend time at Hacker School. Since I work on MediaWiki-related documentation and I've never programmed in PHP before, I decided to start understanding just enough PHP to be able to read it better. Jordan Orelli from Etsy, a fellow alumnus, was kind enough to give me several pointers, and to especially help me understand how a PHP programmer's experience differs from my experience as a Python programmer.
I have learned, for instance:
Much thanks, Jordan! This is all oversimplified for clarity, etc., etc. I think next up I am going to try to understand a bit of PHP syntax, and the role of PEAR.
# (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 Mar 2014, 12:25AM: Open Source Jobs (We're Hiring):
The Wikimedia Foundation, which employs me, is hiring, a lot. We need your help to:
- write code to try new ways to encourage people to edit Wikipedia (Growth engineer)
- keep our users' data safe (operations security engineer)
- make sure our designers and multimedia engineers build the right things (multimedia product manager)
- help other Wikimedians figure out how to design their outreach and mentoring initiatives better and evaluate them for effectiveness, so we learn what works (program evaluation community coordinator)
- automate more of the systems that help developers test new code to find bugs early (Test Infrastructure Engineer)
- like 14 other jobs, seriously, we're hiring a lot
And of course everything you make at the Wikimedia Foundation is freely licensed, so you can suggest your buddies use it to solve their problems, write public blog posts about it, talk about it at parties and conferences, and link to it on your résumé. Isn't open source rockin'?
(Many WMF workers, including me, telecommute. You might also like our Pluralism, internationalism, and diversity policy.)
Some other places that make open source software or free culture and are hiring:
Linaro, MongoDB, Participatory
Culture Foundation, CollectionSpace, Harvard Humanitarian Initiative, Mozilla, Kaltura, Boundless, Acquia, OpenStack-using companies, Varnish Software, Red Hat, InkTank, wikiHow, the libraries and similar institutions seeking Wikimedians/Wikipedians in Residence, Canonical, Collabora, the Linux Foundation, Eucalyptus, New York Public Library Labs, Pro Publica, Nebula, the Electronic Frontier Foundation, the Open Knowledge Foundation.
That's just a fraction of who's hiring. You can check the
FSF jobs board, OPW's list and the liberationtech-jobs mailing list for more.
If you're looking specifically for internships, the OpenHatch list, Google Summer of Code, and Outreach Program for Women should help you.
This is a followup to a similar post I made in late 2012.
# (2) 26 Feb 2014, 07:10PM: Some Help for New Open Source People:
Wikimedia is participating in this year's Google Summer of Code internships and Outreach Program for Women. This week we are seeing a bunch of new folks try to learn how to navigate the world of open source, and I have some advice for you. Some of this ought to go into the Google Summer of Code student manual and the Open Advice collection.
"Doubt": Lots of GSoC candidates are from South Asia. Indians often say "Can you help resolve my doubts?" where US speakers would say "Can you help answer my questions?" "Doubt" and "question" are synonyms here; the Indians aren't implying suspicion.
How we talk: We talk in different places when we want to have different kinds of conversations. Each open source community has "a mailing list, a wiki, and an IRC channel.... a platform for discussion, storage for documentation and real-time communication." (I borrowed this explanation from the hackerspaces wiki.) An IRC channel is a constant waterfall of conversation and you aren't expected to be there all the time or catch everything. A mailing list is more like a slow-moving river, and a wiki changes slower, like a marsh.
Some people prefer for their IRC conversations to be more like mailing lists -- a long, publicly archived conversation where people can see what happened before and take part. Some people prefer for IRC chat to be more like Snapchat -- ephemeral, temporary, so it's easier to be vulnerable. No one agrees on what all of IRC should be. So the community within each channel has a certain culture and each channel can be different. Some channels allow or encourage public logging (example) so anyone can see what happened in the channel. Others don't. This difference is normal.
The rhythm of help: When you are learning how to contribute in open source, you're going to find that people give you links to pages that answer your questions. Here's how that usually goes:
This helps us make a balance between person-to-person discussion and documentation that everyone can read, so we save time answering common questions but also get everyone the personal help they need.
- you ask a question
- someone directs you to a document
- you go read that document, try to use it to answer your question
- you find you are confused about a new thing
- you ask another question
- now that you have shown that you have the ability to read, think, and learn new things, someone has a longer talk with you to answer your new specific question
- you and the other person collaborate to improve the document that you read in step 3 :-)
What's this project like?: Figuring out whether something's a good project for you is a skill and new folks don't have that skill yet. My friend Mel wrote a guide to how she checks out an open source project -- how she takes five minutes to look on their website for certain things, to see what kind of project it is. It's fine for you to look for projects where you already have friends, or where they have already set up easy tasks for beginners. We hope that in a year you'll be one of the people coming up with new ideas, organizing those easy tasks, and helping the beginners.
# 14 Jan 2014, 01:20PM: Hidden Jewels of the RFC or PEP Process:
I've been looking into other open source projects' processes for making big architectural changes, to help improve MediaWiki's process. Some have Requests for Comment processes, separate from normal bug/enhancement tickets. Some don't. Some have voting, some have a Benevolent Dictator For Life making the decision. And so on and so on. (This is where I get to use my bachelor's in political science!)
I have come across a few fun documents in this quest:
# 30 Nov 2013, 06:37PM: Round Seven of OPW:
Congratulations to all six of the Wikimedia's chosen participants in the current round of FOSS Outreach Program for Women internships. I'm especially glad I was able to help Maria Pacana and Be Birchall, my colleagues via Hacker School, learn more about the program and apply.
Many months ago, Wikimedian Liam Wyatt tweeted:
@hexmode @brainwane prob a dumb question, but do we have anything planned like @codeacademy to help folks learn mediawiki/php/wikimarkup?
The answer: now we do. One OPW intern will make a Codecademy course on the MediaWiki API. (Also, we now have The Wikipedia Adventure and the Visual Editor to help people start editing.)
# 15 Nov 2013, 03:44PM: Code4Lib, Open Data, Open Access, and Fighting Systemic Bias:
"Missing from Wikipedia" (code) makes me happy. I presented about it yesterday at Hacker School, asked a fellow HSer to discuss his critique of my code, and - live! on stage! - merged his pull request. Yay for code review and collaboration! (I also showed off a much sillier toy I made, which grabs some sentence from an English Wikipedia page if you give it a topic. Sample for "Chairs": "Some are decorative.")
I am grateful and proud that I can, with "Missing from Wikipedia," make a small contribution to the ecology of openly licensed code and content that I draw from. I could make "Missing from Wikipedia" because:
And so on. I fork from the repos of giants.
- the data for all Wikimedia projects is available under an open content license
- and queryable via an open-to-all API
- that lets you get information about 50 pages at a time (and with not-too-terrible rate limiting)
- that I could access using a good open source library with great docs
- available for an excellent and well-documented open source programming language
- that already Just Works with my source control system, text editor, operating system, and laptop
But we can only use a tool like "Missing from Wikipedia" if we have data to feed into it: a list of names. This is another way open data and open access to research is important. If we can get digital copies of things like the tables of contents of other encyclopedias and dictionaries, that makes it easier for us to systematically check for missing coverage on Wikipedia. But if those lists and tables are behind paywalls, then we can't see them.
And we need access to research papers, to help us figure out what tools to write. Let's say you'd like to fight systemic bias on Wikipedia and you want to write the most effective tool you can. What proportion of these citations on the effect of sexist language can you read & assess yourself? What proportion of the research that would help you do your job better is behind a paywall, and therefore not just hard to find, but essentially undiscoverable? Papers you can't link to are like missing Wikipedia articles -- out of sight, out of mind, out of the group discourse.
At this point I wave my hands excitedly and go off in some direction expounding on the intersection of open stuff (especially Wikimedia), social justice, comedy, and transformation. I presume I will cover similar topics in March 2014 when I keynote the Code4Lib conference, speaking to people who make things for/with cultural institutions. (Such an honor to be asked to keynote Code4Lib! And with Val Aurora of The Ada Initiative giving the other keynote!)
I've benefited so much from the ecology of open stuff. I aim to reciprocate, and to help make it even better.
# 13 Nov 2013, 08:38AM: Missing From Wikipedia: Tool to Help Fight Systemic Bias:
This week I wrote a tool I currently call "missing from Wikipedia" although the name may change. You feed it a list of people's names and the language Wikipedia you want to check, and it tells you who from that list does not currently have Wikipedia pages about them.
For instance, I gave it the ~2100 names from the table of contents from the Oxford Dictionary of African Biography (edited by Emmanuel K. Akyeampong and Henry Louis Gates), and asked about English Wikipedia. The list of people who (I think) do not have enwiki articles about them has 948 names. That means we do cover about half those Africans already, e.g., Nadine Gordimer. (This is an approximation, because I know some names need more finagling; for instance, currently the script messes up Barack Obama Sr.'s name so it wrongly thinks he doesn't have an enwiki page about him.)
I wrote this for Keilana (yay) as a tool to help fight systemic bias on Wikimedia projects. I hope other people find it useful. I've just added some code so that it prints out the percentage of missing people when it's done running, so you have a better measure of (for instance) French Wikipedia's coverage of important Senegalese leaders. I met Keilana in Berlin this past weekend at the Wikimedia Diversity Conference, and got to show her the power of APIs.
When I came to Hacker School, I had a general goal: "When I see a problem that could be solved by writing some Python and reading from/writing to an existing API, I want to recognize that and be able to solve the problem that way." Now I'm a little over halfway through and I have done it!
The code's GPL'd. Enjoy.
# 06 Oct 2013, 12:00PM: What They Don't Know:
Or: you are an expert if you can save people time.
Late in 2011, I found out that one of my colleagues, a whip-smart and infinitely organized administrator, wanted to know more about how the engineering side of Wikimedia works. So I started teaching her. Every month, we talked for about an hour. She asked me about some activity from the monthly report and I explained what we're doing and why, often using analogies. She loved it and felt far more connected to what her other colleagues were doing.
She's not at Wikimedia anymore, so I have tried doing it as a Wikimania presentation and continuing the tradition with other WMFers who were interested. So far I've done a lot of one-off "What the fudge does Wikimedia engineering do" sessions for incoming folks, mostly non-engineers coming into the Foundation's other departments.
Two lessons from that experience:
- Sure, continuing mentorship relationships are awesome. But don't discount the value of a few limited teaching sessions.
- I have about three approaches to teaching this stuff: Historical (What has happened since we started in 2001?), Experiential (What happens under the hood when you go to en.wikipedia.org in your browser, and who's in charge of what parts?), and Organizational (Who are the eight directorates in WMF engineering, and who are other important Wikimedia tech institutions, and who does what?). I want to get better at the historical mode, which means learning what happened in what order between 2001 and 2011; right now I do the org-chart mode quite well, and the experiential mode well except for talking about load-balancing and caching.
I wish I'd kept good notes of all the questions people have asked during these sessions. Some of them:
- What is a parser?
- What is LAMP?
- What is MySQL? What is a database?
- What is Apache?
- What does "open source" really mean?
- How can it be that so many talented programmers are only in their twenties?
- What is the role of the Engineering Community Team?
- What do the people in the MediaWiki core team do?
- What is Subversion, what is Git, and why did we switch?
- Do all the Wikimedia sites run on MediaWiki?
- How can we do what we do with so little staff?
- What's with this Lua thing?
- Why has it taken so long to write the Visual Editor? (This question led me to sketch out a blog post we published.)
- What is a "virtualized hosted development environment" (Labs)?
- Why did we have to switch to IPv6 and why was that hard?
- What is an API?
- What is HipHop and why would we use it?
- Why did we work on a specialized Wiki Loves Monuments app?
- What are the Universal Language Selector and Milkshake?
- What is Swift?
- What is the difference between the E2 (Editor Engagement) and E3 (Editor Engagement Experiments) teams, and what do they do? (We partially fixed this by rearranging and renaming the teams to Core and Growth.)
- What is HTTPS? How does SSL work?
- What kind of security problems could a web-based application have? Do we have worse problems because we're open source?
- What does a product manager do?
- Why don't we provide automatic translation from and to different language Wikipedias?
- What is Wikidata?
- Is Wikipedia Zero just for Wikipedia, or also the sibling sites?
- How do we consult with hundreds of different wiki communities when building and rolling out our software, especially when we don't speak their language?
I have just started at Hacker School, a place designed to help everyone learn. That means making people feel comfortable with saying "I don't know". I've benefited countless times from this, because if no one's going to belittle me for not knowing something, I feel safer asking and learning. I didn't realize how much I would also get to teach! When everyone feels safe saying "What does that mean?" then I get to help more people learn more things. I've explained, among other things:
It's super amazing when you teach someone a skill or a perspective that changes them. I feel so lucky that I am an expert, i.e., someone who can save other people time. It is a form of hospitality.
- what Markdown is, and why you would use it
- what screen-scraping is, and why APIs would be better
- how I use git
- what unit tests are, and why you would add automated testing to your project
- dozens of opportunities to reuse, integrate with, or improve Wikimedia data and software
- a bunch of Unix command-line tips, such as control-R for interactive search of bash history
- the sordid history of ReiserFS
- why Nvidia drivers are the classic example of "proprietary stuff that's not in the Linux kernel but that you might want to use so some distributions carry it"
# (5) 28 Aug 2013, 01:05PM: Accepted To Hacker School:
If you've read my past posts on Geek Feminism, you've seen me thinking about how I learn. I have worked 15 years in the software industry as a tech writer/salesperson/tester/manager. And I have about 25 years of occasional BASIC/Scheme/SQL/Visual Basic/Python/CSS/bash under my belt. I've enjoyed dabbling; I love solving problems with code and the "it works!" feeling of making something that does my bidding. And, thanks especially to AdaCamp, the Boston Python Workshop, and related communities, I've now learned that I learn best when I'm around other curious, passionate, and respectful people whom I can teach and learn from and brag to, and in a physical space we dedicate to that activity for big stretches of time. Since then I haven't had the time to focus on improving those skills.
That sounds exactly like Hacker School. So I applied for the autumn batch, and I've been accepted. I will therefore be taking an unpaid personal leave of absence from the Wikimedia Foundation via our sabbatical program. My last workday before my leave will be Friday, September 27. I plan to be on leave all of October, November, and December, returning to WMF in January. During my absence, Quim Gil will be the temporary head of the
Engineering Community Team. I'll spend much of September turning over responsibilities to him. Over the next month I'll be saying no to a lot of requests so I can ensure I take care of all my commitments by September 27th, when I'll be turning off my wikimedia.org email.
When I'm in the zone, growing my programming skills, time is a blur, I feel powerful, and I am in awe of what we can make. And the more I think about doing Hacker School, having that feeling for weeks at a stretch, the more excited I get. So I'm thrilled that I can take three months off my job to come to Hacker School, so I can make tools to make my life easier, and so I can be a better community manager for MediaWiki (calling out easy bugs for newbies, running stats, packaging and customizing tools, etc.). I want to nurture the programmer side of myself, because programming is heady fun, and because the skillset will supercharge everything else I do. I'll be a more effective citizen, coach, and leader if I increase my fluency in code.
After all, it's going to take a lot of energy and innovation to improve the quality of open source software. We need open source software that ordinary people can use, with documentation in the languages users speak, and whose design addresses the needs of women and men worldwide. Whatever approach I take to that problem -- mentorship, platform-building, recruiting specific demographics, media-making -- I anticipate wanting to hack a lot of dashboards, APIs, courseware, wiki templates, poorly formatted datasets, CRMs, and helpful little scripts along the way.
Thank you, WMF, for the sabbatical program, and thanks to my team (especially Engineering Community Team's Quim Gil, Andre Klapper, Guillaume Paumier, and my boss Rob Lanphier) for supporting me on this; I couldn't do this without you. And thanks to the women-in-open-source community, especially the Ada Initiative, for helping me gain the confidence to take this step. (The Ada Initiative's trying to finish its fundraiser, in case you can help.)
If there's anything else I can do to minimize inconvenience, please let me know. And wish me courage!
# 21 Aug 2013, 10:45AM: My Family And The Ada Initiative:
Please join Leonard and me in donating to the Ada Initiative. Why? Let me tell you a story, and then a surprise.
My parents came to the US from Karnataka, in south India, in the 1970s, and they were lonely. They spoke Kannada and English and Farsi and Hindi and Sanskrit, but Kannada was their mother tongue, and they arrived in Oklahoma and found no Kannadiga community to speak of. (Go ahead and groan. My dad passed on his love of terrible puns to me.)
I'm not saying they were the first Kannada speakers in the US. There were definitely already Kannadigas in the US in the 1970s. Indians had been immigrating here for decades.* There were letters and long-distance phone calls and occasional visits, a few families getting together, the adults laughing and swapping tips in Kannada while kids ran around. But the Kannada-speaking diaspora was scattered and had no central place to talk with each other. A bunch of people who shared a characteristic, but not really a community.
So my parents did some community organizing, in their spare time, in between working and raising my sister and me. How did they get Kannada speakers together? They started "Kannada Koota" local organizations (like user groups). "Koota" means "meeting" in Kannada. They basically started a grassroots network of Kannadiga meetups. How did they get these folks talking to each other, all across the country? They started a bimonthly magazine, Amerikannada, and ran it for 7 and a half years, until their money and energy ran out. It had great fiction, and articles from the literary magazines back home. And it included ads for those Kannada Koota meetups, "how I started a Kannada Koota" articles, and tutorial exercises for "how to learn Kannada", for parents to teach their kids. My parents were sharing best practices, talking meta, inspiring people all over.
I didn't really know that, as a kid. As my parents processed subscriptions, recruited articles and ads, wrote, and edited, my sister and I stapled, stamped, glued, and sealed bits of paper in languages we couldn't quite yet read. We had a rubber stamp with the logo: a griffin-like creature, half-lion, half-bald eagle. I gleefully deployed those magical bulk-mail stickers, red and orange and green with single-letter codes, and piled envelopes into burlap sacks and plastic bins for the frequent trips to the post office.
It was always my Dad who took the Amerikannada mail to the post office. He was strong in those days, heaving the great bags of mail like an Indian Santa Claus (mustache yes, beard no) alongside the blue-uniformed workers on the loading dock, the part of the post office most people never use or even see. My sister and I came along, not to help -- how could we? -- but to keep my Dad company.
At home, while toying with BASIC on a PC Jr, I overheard the shouted long-distance phone calls in mixed Kannada and English. Stuff like "Go ahead and give me the directions to the venue, and I'll tell it to Veena." or "Well you know who you should talk to? Raj is going to be over there around then...." Weekend after weekend I spent reading science fiction in some corner at a Kannada Koota.**
The funny thing is that I thought I was rebelling against my parents by taking the path I did. I majored in political science at Berkeley instead of engineering, and fell in with open source hippies. I used AbiWord on Caldera Linux to write papers about nineteenth-century American political theory and naturalization rates among Indians in Silicon Valley. I fell away from coding and saw that other things needed doing more urgently: tech writing, testing, teaching, marketing, management.
And here I am now, a community organizer like them, finally appreciating what they did, what they made, what they gave up. My dad had to work to support us; he couldn't edit Amerikannada full-time, even if that would have been a better use of his talents, and a greater service to the world. My parents couldn't find enough ads and subscribers to pay for the cost of keeping the magazine going. I appreciate WordPress and PayPal all the more because I see that Amerikannada folded (partly) for the lack of them.
What if one of my parents had been able to bring in income from the community we were building? What if it had been sustainable?
Today, the community that I most identify with is that of women in open source and open culture. We've talked to each other in pockets and locally for decades - hats off to LinuxChix and VividCon, for instance - but in the last few years, The Ada Initiative has brought us more resources, a stronger community, and faster progress than ever. And this is possible because the Ada Initiative's staff is full-time.
So, here's the surprise: Leonard and I will match every donation to the Ada Initiative up to a total of USD$10,000 until midnight August 27th PDT, one week from today. Yes, again. And this time, if the community matches the full amount, we'll chip in an extra thousand dollars.
The Ada Initiative's work is useful in our own lives. When I needed an anti-harassment policy for my workplace's technical events, and when Leonard wanted resources to advise his technical communities on diversity, we consulted the Ada Initiative's resources. AdaCamp brings together, teaches, and inspires women from all over, including me. And the network I found via the Ada Initiative helped me write a keynote speech and respond to unwanted touch at a hackathon.
But more than that, we know that we're improving our world and helping science fiction, open source, and Wikipedia live up to our values. We believe in inclusiveness, compassion, empowerment, and equal and fair treatment for all, and the Ada Initiative opens the doors for more women to get to enjoy those values in the places we love.
And my parents taught me that I should give back. It feels so much better to give back than to give up.
* One couple who moved from Gujarat to California in 1958 had a son who's now a Congressman.
** Nowadays I get to be the only Kannadiga at science fiction conventions.
# (1) 12 May 2013, 09:49AM: Tips for New Summer Interns:
Three tips to help new Google Summer of Code applicants and interns, some of which all remote workers could stand to remember:
- Never let yourself get stuck on a technical question or problem for more than half an hour. Take a break, ask questions in IRC or a mailing list, find a technical book to read like
The Architecture of Open Source Applications, look at some other codebase to
see how they do it, eat a meal, or do something else, then come back to
- Never let yourself get stuck waiting for someone's reply for more
than 2 business days (Monday through Friday). Escalate -- ask your
mentor. If your mentor isn't helping, ask your org admin. If the org
admin isn't helping, ask on the GSoC discussion forum, or email Carol Smith.
- Ask yourself at the start of every day: what did I accomplish
yesterday? What will I try to do today? What are the obstacles I think I will run into? If you ask yourself those three questions and answer honestly -- especially if you let your mentor and team know the answers -- then you will prevent long delays and help keep your morale up.
# (3) 31 Mar 2013, 09:17AM: Open Tech New York City:
Yesterday I delivered a reasonably well-received talk at Open Tech NYC in which I introduced the crowd to their New York open tech neighbors. That is, I explained the four freedoms that define what make software truly free and open, and I gave examples of NYC people and institutions who make or use open culture and open knowledge, open data, open source software, open formats and open hardware.
Here are a bunch of links!
- Culture and knowledge: Wikipedia and other Wikimedia sites -- check out Wikimedia NYC, which collaborates with libraries and other cultural institutions such as the New York Public Library. QuestionCopyright is a nonprofit org that educates artists about alternative licensing and advocates against copyright maximalism. And the Organization for Transformative Works "is a nonprofit organization run by and for fans to provide access to and preserve the history of fanworks and fan cultures."
- Data: the municipal government open data sets are available, and are consumed by organizations like local nonprofit OpenPlans. In February, look for Open Data Day, which had a Code for NYC event this year. (And look at New York City in Wikidata!)
- Open formats: Aaron Swartz, honorary New Yorker, was one of the inventors of RSS.
- Software: I mentioned a few organizations that produce open source software. Socialbomb in Brooklyn helps work on the Tornado web server. Brooklyn-based OpenGeo makes the OpenGeo suite of geographic information systems software. 10Gen in Manhattan makes MongoDB. The Museum of the Moving Image in Queens is working on CollectionSpace, software to help run museums. ProPublica makes tools for data journalism (blog). OpenITP (the Open Internet Tools Project) in Manhattan "supports and incubates a collection of free and open source projects that enable anonymous, secure, reliable, and unrestricted communication on the Internet. Its goal is to enable people to talk directly to each other without being censored, surveilled or restricted." OpenITP is part of the Open Technology Institute, which helps make Tidepools (social wifi).
I mentioned consumers and users of open source among our neighbors. Drupal and WordPress are pretty useful to consulting shops like Behavior. Google makes some open source software but also uses a bunch; for instance, their servers run on a slight variant of Ubuntu Linux. And an art installation in the New York Times lobby uses the Beautiful Soup screen-scraping library that my spouse wrote.
- Hardware: We have Makerbot in Brooklyn, including Thingiverse, and we have Shapeways in Long Island City. And NYC Resistor is a hacker collective in Brooklyn that has get-togethers all the time.
- Events and meetups: Gosh we have a lot. Python and Ruby and open source data analysis groups, for instance. The Drupal community's hosting a Drupal Ladder sprint on April 7th at Elephant Ventures in west midtown, helping new contributors get started. You can come to Techno-activism Third Mondays at OpenITP. Wikimedia NYC hosts events every few months. And for open hardware, check out Maker Faire in September, and the Shapeways meetup. I should have also mentioned Free Culture Conference 2013, April 20th and 21st at New York Law School, and the New York Linux Users Group.
I hope the people listening understood that I was just offering a sample of the organizations in the five boroughs that work on or use open stuff! I opened and ended my speech with some thoughts about love and sharing (and how being a free software person is like or unlike being a vegan), which I reused from "A Slightly Disjointed (Due To A Five-Day Cold) Musing On Open Source, Fear, Motivation, And Witnessing", where I discuss my experience with the open source GNOME desktop environment.
During the coffee breaks and lunch, I also spread the word about Outreach Program for Women and Google Summer of Code internships available this summer; application deadlines are around May 1st.
Thanks to the sponsors and organizers of Open Tech NYC 2013. I enjoyed it despite getting over a cold, and appreciated the chance to learn from and chat with a variety of people interested in open stuff.
Update: Video is up.
# 06 Feb 2013, 07:47PM: What Systems Administrators Do:
I hope you'll read two blog entries I just wrote, whether you consider yourself a "techie" or not. They're meant to explain why the recent Wikimedia data center migration was difficult and took a long time, and how our systems administration department has started being able to respond to problems faster, and prevent them. And I wrote them in the hope that non-programmers will be able to appreciate my colleagues' work.
From duct tape to puppets: How a new data center became an opportunity to do things right (using Puppet for configuration management).
How the Technical Operations team stops problems in their tracks (fixing crises and preventing them with Nagios, Graphite, & Ganglia for monitoring & profiling).
Sometimes non-sysadmins don't appreciate the work that sysadmins do, building and maintaining infrastructure so the rest of us can use websites without thinking about it. But it's important work and I hope these posts help Wikipedia and Wikimedia users recognize it.
# (2) 01 Dec 2012, 10:35AM PST: We Are Hiring - You Too?:
Wikimedia Foundation is hiring, a lot. We need your help to:
And of course everything you make at the Wikimedia Foundation is freely licensed, so you can suggest your buddies use it to solve their problems, write public blog posts about it, talk about it at parties and conferences, and link to it on your résumé. Isn't open source rockin'?
Some other places that make open source software and are hiring:
Linaro, 10gen (makers of
Culture Foundation, Balboa Park Online Collective, CollectionSpace, Mozilla, OpenStack, Red Hat, Canonical, Collabora. And you can check the
FSF jobs board.
If you're hiring people to improve open source -- designers, tech writers, product managers, sysadmins, coders, etc. -- feel free to leave a comment. I know a few FLOSS-ish folks who are about to start looking and maybe I can direct them your way as well.
# (1) 30 Nov 2012, 05:54PM: I Am A Software Developer:
I arrived in San Francisco yesterday in just enough time to speed to Wikimedia Foundation headquarters and present:
Watch, live, via screensharing as a developer fixes a bug, including investigation, git commit, getting it reviewed and merged, and closing the Bugzilla ticket. Probably featuring Sumana Harihareswara. Great for newbies!
About 25 people watched the YouTube stream, which you can now view (it's about the first 20 minutes; the IRC log starts at 20:30:36). A copy of the video should get to Wikimedia Commons sometime in the next week.
A small part of me thought I was defrauding the viewers by masquerading as a developer. Because, sure, I fix user-visible strings and all, and I can read code okay, but (insert moving-the-goalposts here).
This morning, of course, I woke up too early from jet lag, and was listening to calming music, trying to get back to sleep. And then I realized that I hadn't fixed the second half of the demo bug. So I dragged myself upright and opened my laptop and made the fix.
Okay, now I'm a developer. An occasional, entry-level software developer, but one nonetheless. I viscerally believe that the ritual that brought me into that guild was not yesterday's commit, but today's.
# 04 Nov 2012, 10:38AM: Use Case:
Why is open data important? Here's an example from the Wikimedia chapter in Hungary. For context: every year people all over the world participate in the "Wiki Loves Monuments" contest, taking photos of monuments and historic places and uploading them to Wikimedia Commons. So local organizers have to get lists of those places (example).
We had high hopes to repeat in 2012 the highly successful 2011 Wiki Loves Monuments photo contest, which required agreement from the National Office of Cultural Heritage to use the database of national monuments. However, the head of the Office has resigned in June due to a disagreement with the government before he could sign the cooperation agreement for 2012, leaving the decision to his successor. The new head, partly due to the tasks of taking over the Office and partly due to summer holidays could only devote time to the draft agreement in the middle of August. Finally, at the end of August, a few days before the government disbanded the Office, we had received notice that an agreement this year is not possible and we had to cancel our participation in the international photo contest.
Aaaarrrrghh! I offered my sympathies and got a reply:
Thank you Sumana! Wikipedians are quite resilient, so I have good hopes for 2013, even if we have to create a list of the 10 thousand monuments from scratch by hand (which I believe some people have already started doing)... –Bence
I wish you good luck, Wikimedia Hungary, and I wish you open data.
# (6) 29 Oct 2012, 02:53PM: Leonard And I Will Match Ten Thousand Dollars Of Your Ada Initiative Donations:
Leonard and I met because of the open source movement. We owe our livelihoods to open source, and its values -- inclusiveness, compassion, empowerment, equal and fair treatment for all -- help make us who we are.
This is why he and I are pledging to match up to USD$10,000 of donations to the Ada Initiative made before November 1, 2012.
The Ada Initiative works to increase the participation of women in open technology and culture. They gave me the wording and support I needed to create Wikimedia Foundation's Friendly Space Policy for technical events, which helps everyone at a Wikimedia hackathon feel safer so they can concentrate on rockin' out. If you liked "Be Bold: An Origin Story", the keynote I delivered at Open Source Bridge this year, thank the Ada Initiative, whose advisors helped me shape it. Everyone who wants to grow the open source community benefits from the Ada Initiative's work, and so donating to TAI is like investing in a good piece of machinery; TAI's going to make my work easier for a long time to come.
Please join us in donating to the Ada Initiative, especially if you've also gotten a good career out of open source.
# 28 Sep 2012, 10:01AM: Sometimes An Unconference Is The Wrong Choice:
Now that I'm something of an expert on it, I have Opinions on how to structure a workshop or collaboration event for newbies. Summary of my answer:
- define your goals very clearly and specifically
- skip unnecessary tactics
- choose how to use some mix of speeches, tutorials, sprints, and breathing room
We all want to avoid stultifying slide presentations, and if we preplan the schedule, we might choose irrelevant topics or activities. One alternative is Open Space Technology, which substitutes an alternative, more participatory event structure and nearly guarantees that no one will fire up PowerPoint. Some planners (and participants) think that all planned activities are per se useless, and that thus we should only do unconferences that follow an Open Space model, regardless of the event's audience. More often I run into new event planners who default to "we'll do an unconference" without thinking about whether that's the best tool for the job.
When people suggest removing traditional structure from collaboration events, I think of Mako Hill's research on why Wikipedia succeeded and other contemporaneous projects didn't (summary, audio and video). One reason is: even though the peer production model was unfamiliar and chaotic and new, the goal (an encyclopedia) was well-defined. In contrast, these other projects were trying to redefine both process and THE NATURE OF KNOWLEDGE CYBER COLLAB DISTRIBUTED ETC ETC: both process and outcome.
I think that workshops are kind of like that. You can either be innovative, groundbreaking, and inclusive in what you are doing or how you are doing it, but both, simultaneously, is very hard. (This is also an issue with Agile.)
If you are planning an event for people who already know and trust each other, and are good at public speaking and collaboration, and are experts in the field, then an unconference might work! But for newbies who are learning not just a new skill, but a new way of thinking? Give them a more familiar structure. (WisCon is an interesting example here. It's a massively multiplayer conference: anyone can suggest sessions or suggest themselves as copanelists or moderators. But a programming committee processes that input ahead of time into a great at-con schedule.)
This is tough for free culture ideologues, because one wants to "be the change you wish to see in the world", and do everything collaboratively, empoweredly, etc. But sometimes the ivy needs a trellis to grow on.
I think event organizers should consciously design space in the structure for breathing room. People get a lot out of the breaks, the hallway track, and unconference sessions. But I think it's rare to have a good hallway track without some interesting and structured stuff happening in the rooms just off the hallway.
# 09 Jul 2012, 10:46PM: Open Content, Source, And System:
Video interview with me about Wikimedia's openness on multiple levels.
# 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.
# 12 Feb 2012, 07:51PM: What Does A Volunteer Development Coordinator Do?:
A giant wall of text follows, giving a snapshot of work I do. I nurture the software community that supports the Wikimedia movement. So here's a big swath of stuff I did between February 1st and today.
Wrote and posted a blog entry about the San Francisco hackathon. Still need to do more followup with participants.
Handed over the MediaWiki 1.19 deployment communications plan to Guillaume Paumier, WMF Technical Communications Manager. He blogged a summary of the deployment and of our efforts and that's just the tip of the iceberg; he also set up a global message delivery and improved the CentralNotice maintenance message and did even more to make sure that we thoroughly communicate about the upcoming deployment to all the Wikimedia communities. I also shared information with various folks regarding testing of site-specific gadgets on 1.19.
I sent at least 285 work-related emails. That's 41 per workday but I definitely sent some work-related email on weekends.
Some patch queue work, responding to contributors and getting experienced developers to review the patches. I'm just trying to keep our queue from growing while code reviewers are mostly focused on getting MediaWiki 1.19 reviewed, polished, and deployed. But I do want to take care of all parts of the volunteer pipeline -- initial outreach and recruiting, training, code improvement, commit access, continued interest and participation, and debriefing when they leave -- so the patch review queue is a continuing worry.
Some work preparing for the Pune hackathon and for GLAMCamp DC, neither of which I am attending. I wrote or edited some tutorials and made a tutorial category which pleases me. We have more good material for workshops and stuff now, yay! And I helped the GLAMCamp people a bit in talking through what technical goals they wanted to achieve during the weekend.
Got dates from Wikimedia Germany for the Berlin hackathon, 1-3 June, and started trumpeting it. Also worked on planning for it and did outreach. For example, I reached out to about 13 chapters that are pursuing or interested in some kind of technology work like, say, funding or working on the offline Wikipedia reader (Wikimedia Switzerland), or usability and accessibility for Wikisource (Wikimedia Italy), or the Toolserver, a shared hosting service for tools and stuff that hackers use to improve or make use of the Wikimedia sites (for example, Wikimedia Germany & Wikimedia Hungary). We hope they can convene, share insights and collaborate at the WMDE hackfest.
Told at least 30 contributors to apply for Wikimania scholarships because the deadline is 16 February.
Talked to some Wikimedia India folks about planning technical events, and contributed to a page of resources for upcoming events.
Worked on some event planning & decisions for a potential event.
Passed the word to some friends, acquaintances, and email lists about some job openings at the Foundation.
Google Summer of Code has been announced, and I am managing MediaWiki's participation. I have started -- flyers, emails, recruiting potential students, improving the wiki page, asking experts whether they might mentor, and so on. I'm trying to start a thing where every major women's college in North America gets a GSoC presentation by March 15th, to improve the number of GSoC applications that come from women; let's see how that goes. MediaWiki still needs to apply to participate as a mentoring organization and acceptances only go out after that, but I'm comfortable spending time preparing anyway. And the women's college outreach will lead to an increase in the number of applications for all the participating open source projects, instead of just aiming a firehose at MediaWiki; that's fine. Like Tim O'Reilly says, aim to create more value than you capture.
Related to that -- I set up a talk for one of our engineers to give at Mills, a women's college that has an interesting interdisciplinary computer science program (both grad and undergrad, the grad program being mixed-sex) and I think it may end up being a really amazing talk. Ian Baker is going to talk about how CS helps us work in Wikimedia engineering, how we collaborate with the community during the design, development, and testing phases, and what skills and experiences come in handy in his job. I'll publicize more once there's an official webpage to point to.
Had a videoconference with a developer and my boss about our conversion to Git. I prepped for it by collecting some questions and getting preliminary answers, and then after the call we ended up with all this raw material and I sent a fairly long summary to the developers' mailing list. There's a lot left to do, and the team needs to work on some open issues, but we have a lot more detail on those TODOs now, so that's good.
Saw a nice email from Erik Möller publicizing the San Francisco hackathon videos and tutorials/documentation, yay!
Talked with a few people about submitting talks to upcoming conferences. I ought to write some preliminary Grace Hopper, Open Source Bridge, and Wikimania proposals this week.
Various volunteer encouragement stuff (pointing to resources, helping with installation or development problems, troubleshooting, teaching, putting confused people in touch with relevant experts, etc.), especially talking in IRC to eager students who want to do GSoC. Many of them are from India. I wonder how many of them see my name and think I'm in India too.
Commit access queue as usual.
Helped with the monthly report. I have a colleague who wants to learn more about All This Engineering Stuff, so every month we have a call where I explain and teach the context of the report, and for this month's call I suggested we add another colleague who also wants to learn how the tech side works. Who knows, maybe this will turn into a tradition!
Followed up on the GSoC 2011 students who never quite got their projects set up and deployed on Wikimedia servers, and looks like two of them have some time and want to finish it now, yay! Updated the Past Projects page.
Checked in on the UCOSP students who are working on a mobile app for Wiktionary and told them about Wikimania, new mobile research, etc. Also got some feedback from their mentor, Amgine, on how they're doing.
Started an onwiki thread to discuss the MobileFrontend rewrite question(s).
Talked to Oren Bochman, the volunteer who's working on our Lucene search stuff, and followed up on a bunch of his questions/interests.
Ran & attended meetings.
Suggested to the new Wikimedia Kenya chapter that maybe we could collaborate, since they're interested in helping schools get Wikipedia access via offline reading.
Looked into the code review situation by getting a list of committers with their associated numbers of commits, reviews, and statuschanges. It's just a first pass, but it's a start for discovering who's been committing way more than they review, so we can start efforts to mentor them into more code reviewing confidence. I also saw who's been reviewing way more than they commit, and saw a name I wasn't familiar with -- looks like I've now successfully recruited him to come to the Berlin hackathon. :-)
Put two groups of people in touch with each other: did a group-intro mail to people at various institutions working on Wikimedia accessibility, and another to people who want to work on a redesign of mediawiki.org's front page.
And there was other miscellaneous stuff, but this is already sooooo TL;DR (too long; didn't read). (Which is funny because that's the name of my team.) Monday awaits!
# 18 Jan 2012, 04:14PM: Ducts:
I've had two astonishing experiences in the last few days.
The first was watching the film Brazil for the first time. If I had watched that at 16 it would have changed the course of my life.
The second is still ongoing. I am at Wikimedia Foundation headquarters today, and I was here when the word came back that the community had decided to globally black out English Wikipedia in protest of SOPA and PIPA, and I was here when we flipped the switch to do that and some music player started blasting "We're Not Gonna Take It."
This morning a stranger thanked me for working at the Foundation, as though thanking a soldier for her service in a war.
In Brazil we see everywhere ubiquitous ducts, maintained badly -- sometimes sabotaged -- by Central Services, as heroic volunteers make up the difference by secretly installing workarounds. I write this at my temporary desk, seeing the exposed HVAC ductwork on the third floor of a nondescript San Francisco office building. The more vital duct is the Ethernet cord connecting me to the Internet, to that communally maintained "series of tubes" that gives me work, community, free speech, and the collective wisdom of civilization.
Right now someone needs to save our ducts from sabotage, and the volunteers of the Wikimedia community have courageously decided to sacrifice a day of Wikipedia in the hopes of decisively ending a great threat. We Foundation workers have the privilege of helping.
I oppose SOPA and PIPA. Will you join me?
# 12 Nov 2011, 10:09PM: Work And Being Realistic:
This month I'll briefly be in Mumbai for a Wikimedia developers' meetup. Developers and translators will be working on mobile and offline access, localization, and general knowledge sharing about Wikimedia technologies. If you're interested in coming by, let me know.
Selected recent Wikimedia (work) stuff: Guillaume Paumier did important foundational work in collecting and integrating information for a MediaWiki architectural overview and history. I've already pointed newbies to it at least five times to explain something. And the first MediaWiki 1.18 beta release is out so people can download and test that. We're hiring for like a dozen technical positions. There's so much going on that if I go on I'll end up repeating our monthly reports.
Perhaps more interestingly, my current crusade is patch review. When new technical volunteers show up, perhaps trying to scratch their own itch or get started with an annoying little easy bug, they contribute patches in our Bugzilla. We're not reviewing and responding to them consistently and quickly enough; there are more than 260 patches awaiting a response, some dating back years and thus suffering bitrot. So, the workflow isn't working. I'm working on figuring out what's broken and how to fix it.
All my Wikimedia work and travel has kept me from my previous big open source commitment, GNOME. I've been saying to friends and GNOME teammates for some time now that I can't keep up, and am now unsubscribing from the GNOME Marketing and GNOME Journal team email lists in recognition of that fact. It hurts, but it's better not to pretend to commitments one can't keep. Fortunately, Emily (Rose? not sure of her last name) & Sriram Ramkrishna have done a great service in moving GNOME Journal to a modern publishing system at https://thegnomejournal.wordpress.com/. It looks like they'll take over running and editing it, which is lovely. Paul Cutler and I simply have not had the time to give this information channel the attention it deserves, so he and I asked for others to step in and take over, and I am glad to see Sri's, Emily's, Allan Day's, and others' energy pushing forward to keep the GNOME and FLOSS communities informed about GNOME happenings.
We are in this together. It's like the geek feminist saying goes:
Let's say that fighting sexism is like a chorus of people singing a continuous tone. If enough people sing, the tone will be continuous even though each of the singers will be stopping singing to take a breath every now and then. The way to change things is for more people to sing rather than for the same small group of people to try to sing louder and never breathe.
The demands of scaling up imply, somewhat recursively, that in my role coordinating and recruiting volunteers, I need to also recruit people who will coordinate and recruit volunteers. I'm working on it.
# (6) 01 Sep 2011, 06:22PM: Everybody's Doing It: Some Hackathon Tips:
I'm helping arrange some developers' events at work. They're meant for open source software developers, testers, documenters, and other contributors to get together, talk, and collaborate. We often call them hackathons. I'm directly planning, with a colleague, the October 14-16 hackathon in New Orleans. But I'm also advising volunteers and people at partner organizations who want to put on technical events -- for example, a British contributor is planning a hackathon in Brighton, 19-20 November. The Wikimedia Foundation itself can only put on a few events a year, but there's plenty of room and demand for smaller regional meetups, so I'm enthusiastically encouraging volunteers who want to throw a hacking party.
People keep acting as though I'll have useful advice for them in hackathon planning, so here goes! I do not want to reinvent the wheel here, so I'm liberally linking to others' existing guides and HOWTOs.
My colleague Siebrand Mazeland wrote some goals for an upcoming hackathon and I like them as an example. Note that this is for an event where we're expecting that most participants will be new to MediaWiki and to open source development in general:
- Inform participants about how the MediaWiki community works
- Inform participants of the major development languages and tools for MediaWiki
- Provide a brief, comprehensive, accessible overview of the exciting projects MediaWiki developers are working on -- convey that anyone with PHP knowledge, and who wants to build an excellent open source CV, can participate in the community
- Get current developers talking to prospective developers
- Get a few people (1-3) that were not MediaWiki developers beforehand to be MediaWiki developers within 2 months after the hackathon
First I'll talk about the social/content side of hackathons, and then some outreach/process stuff, and then the technical/logistics side.
People & Activities
Here's what I wrote while helping plan an upcoming hackathon, one of the first in its region:
Since I predict that at least half of the participants will be new to
MediaWiki-related development, we'll want to seed the crowd with some
more experienced developers (if possible, from the region). And we'll
want to provide some direction and some pre-planned activities,
especially for the first day (if we're assuming a two-day hackathon).
One of these activities should be the "how to start modding MediaWiki"
lecture/workshop that we first led at Wikimania. A colleague and I will
be cleaning up those notes in
September to create a curriculum that a local developer could use to teach.
Other preplanned activities would include just enough structure to
help inform and guide the energy of new, uncertain participants. For
example, organizers should ask several local developers, ahead of time,
to prepare sets of tasks that small groups could work on, such as "fix
these ten bugs in Kiwix" or "add language support for (this language) to
(tool)." It would be best if these developers could also give extremely
short talks about their areas of interest (3-5 minutes each, no slides
necessary). In the afternoon of the first day, and at the beginning of
the second day, there would be a twenty-minute period of these
"lightning talks" and then participants could decide what group to join.
I am generally in favor of allowing some room for spontaneity, by asking
participants on the first day what they're interested in working on,
encouraging them to give ad hoc lightning talks during the short talks
sessions, and by encouraging participants to lead sprints on topics of
their interest. Technologists feel more inspired and creative if
there's lots of support (people who are willing to teach and mentor) but
also freedom to discover and concentrate on new interests.
It's tempting for organizers to say "let's concentrate on this! and
this! and this!" at a hackathon. But you can't concentrate on
localisation, and mobile, and accessibility, and HTTPS, and mass
uploaders, and usability, and the article feedback tool, and and and.
:-) If you really want some topic focus at the hackathon, choose maybe
2 concentrations a day, and target your outreach and publicity, saying
that you especially welcome participation in those areas.
Some Things You'll Need
for a successful developer outreach event:
- a public wiki page stating the date, time, and venue, and specifying that everyone is welcome. Also tell people what to bring (laptop and power cord), ask them for topic ideas, and ask them to put their names down -- no obligation. A sample.
- outreach/publicity drive, starting at least six weeks in advance, to relevant
communities. Ideally you'd get the word out to technical interest
groups, local user groups, consultants and other businesses in the
industry, individuals whom you want to attend, professors and colleges
and universities and technical schools and trainers, email lists, and
(if relevant to your audience) newspapers.
- some experienced developers. I don't know the exact ratio, but
perhaps a fifth of your participants should be people who have had some
experience in developing Wikimedia/MediaWiki stuff, loosely defined.
You need some seeds.
- documentation tools & some people who will take notes with them (more below).
- lightweight tracking. At some point, somehow, at the event, get every participant's name and email address. That way you can follow up and
continue encouraging them after the event.
Technical stuff & logistics
I find that the Stumptown Syndicate's Event Planning Handbook section on logistics ably summarizes the logistical side of what's needed at a technical event.
Basically, once you have a venue, the next priority is provision for
robust wireless (and, if possible, wired) internet, and provision for
heavy electrical power usage.
You'll want to have some kind of documentation of your hackathon, to
make it easier for people to collaborate (face-to-face and remotely),
and to have a record for future reference. As we decided for the Berlin WMDE hackathon this year (thanks to Daniel Kinzler for distilling this hierarchy):
- textual documentation: essential
- live textual documentation (IRC, Etherpad): important
- photo documentation: important
- audio recording: important
- video recording: would be good
- audio streaming: would be good
- video streaming: nice to have
It's great to have two dedicated notetakers/facilitators typing into
Etherpad for collborative notetaking, finding and answering questions on IRC and blogging, and walking around talking to people and asking them what they're working on and helping them collaborate more effectively.
And below I'll reproduce a note that Jon Davis, formerly of Wikimedia
internal IT, wrote about audio recording and streaming (when planning
for the Berlin WMDE developers' days):
The biggest problem is getting reasonably quality audio to a computer. The single biggest complaint I've had... was that it was hard to hear people. [You'll] need some reasonably quality microphones to capture with. If it is presentations, I recommend some sort of shotgun style mic. If it is a group talk, something omnidirectional. The trouble is twofold.
There is probably far better advice out there regarding recording/streaming video and audio. I welcome links and experiences.
#1 - I couldn't find any USB compatible shotgun mics off hand. You can, in effect make one with the right parts , , but it's definitely not cheap.
#2 - The USB omni-directional that I found  isn't cheap, and I've no idea what the quality is.
So [you'd] need at least one mic setup (and probably computer) per area [you] are trying to record. It's not... "great", but it sure beats running a ton of cable, doing mixing and all sorts of much more pro level work. I have no idea what the budget is for that sort of thing, so it might not be a big deal...
You'll also want to consider bathrooms, garbage needs, whiteboards and
markers, and maybe childcare, and so on -- the sorts of things
conference organizers need to consider, in general. A few guides with
tips on what to consider:
And of course there is a lot of "how to run a conference" reference material available for your perusal, including ConRunner, which focuses on science fiction convention organizers but which has more generally applicable advice. And hey, they're running MediaWiki!
Questions, links, comments welcome in the comments.
# (1) 11 Jul 2011, 11:11AM: Kyriarchy & Mr. Rogers:
In late June, Kjerstin Johnson interviewed me for Bitch Media (makers of Bitch Magazine) about Wikimedia, feminism in open source, and related topics. You can listen to the half-hour interview via download from the Internet Archive, or read the transcript (4800 words, 67KB .doc file).
So open source means that anybody can modify the code; closed source means that no one else other than the people who basically sold it to you can modify it, and therefore you are disempowered, and you are under someone else's control. And as Mr. Rogers once said, "I am against the idea of anybody being programmed by anybody else."
The actual quote is: "Very frankly, I am opposed to people being programmed by others." I'm pretty sure I first ran into it in Seth Schoen's email signature.
# (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.)
# 20 May 2011, 07:43AM: Three Wikimedia Facts:
If you have a WordPress blog, the PhotoCommons plugin is an easy way to grab photos from Wikimedia Commons as graphics for your posts.
We have a lot of job openings, including nonprofit-y, communication and legal stuff.
Basically, our number one priority right now is new editor retention -- people don't realize they can edit Wikipedia, or they try and then something turns them off. We're implementing a bunch of technical and social initiatives to turn this around.
# (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.
# 26 Apr 2011, 05:14PM: GSoC, GSoC, Who's There?:
As the organizational administrator for MediaWiki (thanks to my job for the Wikimedia Foundation), I am pleased to announce our Google Summer of Code students for 2011.
Also delight-inducing: the number of rejected applicants who hope to contribute to MediaWiki as volunteers. I'm trying to get them involved in their local Wikimedia chapters as well.
# 31 Mar 2011, 03:40PM: MediaWiki Accepting Google Summer of Code Applications:
Just posted on the Wikimedia tech blog: MediaWiki got accepted as a Google Summer of Code project, so we're looking for project ideas, mentors, and students. More details at the techblog post.
# (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) 09 Feb 2011, 12:34PM: Recruiting:
As you might have seen from my microblogging, I seem to know a lot of firms that are hiring. In short: I know people who are looking for project managers, UX designers, backend developers, undergrads who code, playtesters, kernel & mobile hackers, so if you know me at all, feel free to contact me to ask for an introduction.
Wikimedia, the foundation that supports Wikipedia ("No, Mom, not Wikileaks, that's different"), is looking for lots of engineers (deadline in 2 days) and fundraisers/researchers/analysts/more. The Volunteer Development Coordinator role also has a 11 February application deadline: attention, open source community managers!
Get paid to hack Linux mobile and save vendors & developers from constantly reinventing the wheel at Linaro. They especially need kernel and Android hackers and technical project and product managers.
OpenPlans, the New York City nonprofit that uses technology to make cities better, has decadent offices and benefits. Oh, and they're looking for a web designer, two engineers, and a fundraising manager.
Socialbomb, the Brooklyn startup that creates stylish experiences connecting Blu-Ray and mobile devices to Facebook & Twitter, is looking to fill several roles, including development.
I'll be administering some Google Summer of Code work this year, so I'd like to recruit bright university students to consider applying. It's never too early to start thinking about summer internships! And don't worry too hard about qualifications: "Do you have some programming experience at the university level? Then, yes, you are good enough! No, you don't need to be a Computer Science or IT major."
And I know at least one more project that's looking for a part-time playtester and a part-time project manager, so let me know if you're interested.
You can hire me through Changeset Consulting.
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.