# (0) 21 Dec 2014, 11:10PM: Why You Have To Fix Governance To Improve Hospitality:
Fundamentally, if you want to make a community hospitable,* you need to work not just on individual rules of conduct, but on governance. This is because
- the particular people implementing rules of conduct will use their judgment in when, whether, and how to apply those rules, and
- you may need to go a few levels up and change not just who's implementing rules, but who's allowed to make rules in the first place
Wait, how does that work?
In my Wiki Conference 2014 keynote address (available in text, audio, and video), and in my PyCon 2014 poster about Hacker School, I discuss how to make your community hospitable. In those pieces I also mention how the gatekeeping (there is an initiation/selection process) and the paid labor of community managers (the facilitators) at Hacker School help prevent or mitigate bad behavior. And, of course, the Hacker School user manual is the canonical document about what is desired and prohibited at Hacker School; "Subtle -isms at Hacker School" and "Negative comments" have more ruminations on how certain kinds of negativity create a bad learning environment.
Sometimes it's the little stuff, more subtle than the booth babe/groping/assault/slur kind of stuff, that makes a community feel inhospitable to me. When I say "little stuff" I am trying to describe the small ways people marginalize each other but that I did not experience at Hacker School and thus that I noticed more after my sabbatical at Hacker School: dominance displays, cruelty in the guise of honesty, the use of power in inhospitable ways, feeling unvalued, "jokes", clubbiness, watching my every public action for ungenerous interpretation, nitpicking, and bad faith.
You can try to make rules about how things ought to be, about what is allowed and not, but members of the incumbent/dominant group are less accustomed to monitoring their own behavior, as the Onlinesmanship wiki (for community moderators) reminds us:
Another pattern of the privileged: not keeping track of the line between acceptable and unacceptable behavior. They only know they've crossed the line when someone in authority tells them so. If this doesn't happen, their behavior stays bad or gets worse....
Do not argue about their intentions. They'll swear they meant no harm, then sulk like fury because you even suggested it. In most cases they'll be telling the truth: the possibility that they were giving offense never crossed their minds. Neither did any other scenario, because unlike real adults, they take no responsibility for getting along with others. The idea that in a cooperative work situation, getting along with one's fellow employees is part of the job, is not in their worldview.
This too is a function of privilege. They assume they won't get hit with full penalties for their first offense (or half-dozen offenses), and that other people will always take on the work of tracking their behavior, warning them when they go over the line, and explaining over and over again what they should have done and why. It's the flip side of the way people of the marked state get hit with premature negative judgements (stupid, dishonest, sneaky, hysterically oversensitive) on the basis of little or no evidence.
And, in any community, rules often get much more leniently interpreted for members of the dominant group. And this is even harder to fight against when influential people believe that no marginalization is taking place; as Abi Sutherland articulates: "The problem with being lower on an unstated social hierarchy is that marginal judgment calls will
reliably go against you. It's an excusable form of reinforcement."**
Changing individual rules isn't enough. After all, individual rules get made by particular humans, who -- here, instead of babbling about social rule system theory at you, I'll give you a sort of sidebar about three successive levels of governance, courtesy of my bachelor's degree in political science:***
- Actors: The actual set of people who run an organization or who shape agendas, on any given day, have particular ideas and policies and try to get certain things done. They implement and set and change regulations. Actors turn over pretty fast.
- For example, in its five-year history, Hacker School has had employees come and go, and new participants have become influential alumni.
- Dominant worldviews: More deeply and less ephemerally, the general worldview of the group of people who have power and influence (e.g., Democrats in the executive branch of the US government, sexists in mass media, surgeons in operating rooms, deletionists on English Wikipedia) determines what's desirable and what's possible in the long term. Churn is slower on this level.
- For example, dominant worldviews among Hacker Schoolers**** include: diversity of Hacker Schoolers, on several axes, helps everyone learn more. Hiding your work, impostor syndrome, too much task-switching, and the extrinsic motivation of job-hunting are common problems that reduce the chances of Hacker Schoolers' success. Careers in the tech industry are, on balance, desirable.
- Rules of the game: What is sacred? What is so core to our identity, our values, that breaking one of these means you're not one of us? The rules of the game (e.g., how we choose leaders, what the rulers' jurisdiction is) confer legitimacy on the whole process. Breaking these rules is heresy and amending them is very hard and controversial.***** Publicly disagreeing with the rules of the game costs lots of political capital.
- For example, the rules of the game among Hacker Schoolers, as I see them, include: the founders of Hacker School and their employees have legitimate authority over admissions, hiring, and rule enforcement. Hacker School is (moneywise) free to attend. Admission is selective. A well-designed environment that helps people do the right thing automatically is better than one-on-one persuasion, which is still better than coercion.
(Where do the four Hacker School social rules fall in this framework? I don't know. Hacker School's founders encourage an experimental spirit, and I think they would rather stay fluid than accrete more and more sacred texts. But, as more and more participants have experienced a Hacker School with the four social rules as currently constituted, I bet a ton of my peers perceive the social rules as DNA at this point, inherent and permanent. I'm not far from that myself.)
(I regret that I don't have the citation to hand, and would welcome the name of the theorists who created this model.)
So, if you want a hospitable community, it's not enough to set up a code of conduct; a CoC can't substitute for culture. Assuming you're working with a pre-existing condition, you have to assess the existing power structures and see where you have leverage, so you can articulate and advocate new worldviews, and maybe even move to amend the rules of the game.
How do you start? This post has already gotten huge, so, I'll talk about that next time.
* I assume that we can't optimize every community or activity for hospitality and learning. Every collaborative effort has to balance execution and alignment; once in a while, people who have already attained mastery of skill x just need to mind-meld to get something done. But if we want to attract, retain, and grow people, we need to always consider the pathway to inclusion. And that means, when we accept behavior or norms that make it harder for people to learn, we should know that we're doing it, and ask whether that's what we want. We should check.
**See the second half of "One Way Confidence Will Look" for more on the unwillingness to see bias.
*** I am quite grateful for my political science background -- not least because I learned that socially constructed things are real too, which many computer science-focused people in my field seem to have missed, which means they can't mod or make new social constructs as easily. Requisite variety.
**** A non-comprehensive list, of course. And I don't feel equal to the more nuanced question: what beliefs do the most influential Hacker Schoolers hold, especially on topics where their worldview is substantially different from their peers'?
***** The US has a very demanding procedure for amending the Constitution. India doesn't. The US has had 27 amendments in 227 years; India, 98 in 67 years. I don't know how to interpret that.
# (0) 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. Please join me by donating today and doubling your impact!
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, whether corporate or individual, one-time or recurring memberships. Please donate now to help raise $30,000 for Stumptown Syndicate and Open Source Bridge!
# 17 Dec 2014, 12:08PM: Some Fanvids I've Enjoyed Recently:
Many of these came to my attention thanks to singlecrow's link to a rec post; thanks!
"Level Up", a Buffy vid by such_heights. A great match of song and topic, with an inspiring focus on the courage and growth of the whole gang.
The "Every Frame a Painting" series by Tony Zhou, analyzing various uses of film form. In particular the "What is Bayhem?" analysis helped me enjoy Hot Fuzz on a new level when Leonard and I re-watched it the other day.
"It's Still Science Fiction to Me", a multifandom vid by azurish. A funny, joyous, clever, and celebratory tour of the last several decades in film and TV speculative fiction. Partially inspired by bironic's mindblowing "Starships" vid, have you seen it? and also by:
"Hey Ho", a Marvel Cinematic Universe vid by thuvia ptarth. As chaila puts it, a "completely scathing critique of the way Marvel sells the military-industrial complex." I also agree with tardis_stowaway -- it "manages the tricky balancing act of being enjoyable to watch while delivering a powerful, disturbing critique."
# 17 Dec 2014, 01:04AM: My Next Few Months:
Last week I got back from AdaCamp Bangalore, some family visits, the community-builders' meeting within Mozilla's workweek, and some volunteering with Stumptown Syndicate to support Open Source Bridge 2015. I set off on those travels basically right after I spent six weeks improving my webdev skills at Hacker School, which I started a few days after I finished up my four-year stint at the Wikimedia Foundation. So it's been intense!
I'm concentrating on a bunch of errands and backlogged volunteer work in the next few weeks, and then in the new year, for several months, I want to do activist and maker work. (I can go without getting paid right now, and I'm fine with doing this as a volunteer. It's not emotionally sustainable for activists and open source contributors to put in huge gobs of volunteer work over and above full-time jobs. And it's not financially sustainable for most people to work as activists for money (not to mention argh the nonprofit-industrial complex). But Leonard and I are very fortunate in that we can switch; sometimes he supports the household and sometimes I do.)
Spend about 20 hours/week writing open source code that ships and that others directly depend on. I have worked on open source projects that hundreds of millions of people depend on, e.g., MediaWiki, but I wasn't a code contributor. I've written open source code that shipped, e.g., my MC Masala site, but my projects were toys or I was the main customer (one exception being "Missing From Wikipedia"). In 2015 I aim to meld these skills.
Right now I'm planning on contributing to GNU Mailman as a volunteer. I know Terri Oda, one of the maintainers, and talked with her in Portland. The Mailman 3 refactor looks like a promising field, fresh code with work tasks of about the right size and shape for me. My Python's good enough. The codebase has comments, docs, and tests. I hear the community is friendly, and I know Terri, and I live close enough to another key contributor that I can probably arrange some in-person hackdays. I'll get to munge stuff dealing with underlying protocols like SMTP, and it's a project lots of other open source projects depend on, so I'll have an impact.
Ideally, by the end of the PyCon sprints, I'll be contributing to code review and comaintaining something. I'll be better at making the systems I want to make. And I'll be confident and seasoned enough that I could plausibly go find a full-time Python web development job, should I wish. That's really more of a self-assessment heuristic than a goal. More importantly, I'll have the experience necessary to give good and credible advice for marginalized people in tech who want to follow that path, and I'll have better wisdom that I can share with allies and imbue into systems to help those people.
Spend about 20 hours/week working to make open stuff friendlier and more diverse. This is time to volunteer on Stumptown, to continue my volunteer duties on the Ada Initiative Board of Directors, to teach Ally Skills workshops, and do miscellaneous other outreach and writing. I'm also open to a little bit of consulting, but will be redirecting some requests to Ashe Dryden or Julia Rios or other experts.
My goal with these activities isn't so much to grow as an activist; rather, I want to give back to these communities that have given me so much, and to help them in ways I'm uniquely positioned to do well. But I'm building on my strengths as a project manager, communicator, and leader, and I'm learning how to be an effective board member and influencer.
Ideally, by late April (after PyCon): Open Source Bridge and Stumptown Syndicate will have better documentation and more vigorous processes that help attract, retain, and grow volunteers; dozens or even hundreds of motivated open stuff participants, especially Wikimedians, will be better feminist allies; and the Ada Initiative will remain swimming along happily and effectively. The infrastructure of our movement will be in even better shape, and I'll have no qualms about changing my commitments to suit my abilities, my interests, and the movement's needs.
As I said when I announced that I'd be leaving WMF, I'm open to new opportunities, especially New York City-based work in empowering marginalized groups via open technology. But if nothing new comes up, internally or externally, I have a reasonable plan for the next four months. Which is nice.
# (0) 16 Dec 2014, 06:06PM: Blog Posts Are A Way For Tabs To Make More Tabs:
# (1) 15 Dec 2014, 12:06PM: A Code Review Group:
I'm interested in piloting a peer code review group, structured like a writer's group. So next month I'm starting one out in New York City, starting with Hacker School alumni and participants, and I figured I'd put some logistics and reasoning here for my own future reference and to help anyone who'd like to do something similar.
Basics: Part of the point of a writers' group is to get participants to produce work consistently, and part of the point is to help everyone learn craft -- the authors and the critiquers. So I'm trying out a similar structure for this pilot. We will meet in person; I think that criticism is often a lot easier to take in person, and I know it's easier for me to take in person. We'll meet about every 3 weeks, midday Saturday or Sunday, to critique two works of code. We'll have a rotating schedule of who's responsible for writing code and who's responsible for reviewing it; I am maintaining that schedule. (I'm copying the frequency and format from writers' groups like Leonard's.) I figure we'll run this with about 5-6 people for four months, hopefully giving each person a chance to have their code reviewed twice, and then reevaluate and see what to keep, change, or give up.
Who?: It felt natural to me to start this in the Hacker School community. Anyone who's going or gone to Hacker School is someone who accepts the social rules we've set up to make learning easier, and is generally collaborative and friendly. Also, alumni can use Hacker School for stuff like this outside of normal work hours, which means we can use a HS conference room (and projector!) for the group meetings.
What language?: Since Python is the only language I am fluent in and it is the language I'd prefer to work in and grow in, most code we review will be in Python. I consider myself an intermediate Python programmer (very comfortable writing list comprehensions, but still need to stop and look up exception-handling syntax when I need it; see "mcmasala" for a recent code sample). Fortunately, Python's enough of a lingua franca, and there's a wide enough variety of skill levels in the Hacker School community in New York, that several programmers were willing to sign up to an intermediate-and-higher Python-specific group. After the pilot period, I think the group will evaluate the idea of expanding to other languages, and see how we feel about skill heterogeneity.
New code only?: I'm not sure whether people will end up submitting already-written or fresh code for the group to critique. I personally think that it would be fine to circulate bespoke and/or already-working-on-it code. Sometimes I might be working on something that's so huge that it doesn't make sense to extract a small-enough chunk of it for peers to review, so I'd write something from scratch instead. Sometimes I'd really want my peers to look at something that I have already been noodling with. I'm curious what other code review groups have found when experimenting on this axis.
Submission length?: My current wild-ass guess is that each submission for review should be somewhere between 32 and 2048 lines of code, but, given that this.py (as in
import this) is ~6 lines other than a giant string, I am happy to deal with codebases of lengths 4-31 as well, for the length of the pilot. :)
Time commitment?: As far as I can tell, here's the format and time commitment for this pilot:
- Everyone: in-person meeting every three weeks for about four months, January-April -- probably about 60-90 minutes long each time, with about 30-45 minutes for each work (the critiquers offering praise and criticism of the work, and the author responding at the end).
- Per person: Twice during the pilot: writing code and emailing it (or a link to it) to the rest of the group, a week ahead of the meeting.
- Per person: Before every meeting, so, about 5 times: reviewing the author's or authors' code ahead of time and writing out notes, so it's easier to give specific praise and criticism at the meeting, and to email to the author(s) afterwards. (I say "author's or authors'" because even if you're one of the two authors who submits code for a particular meeting, you'll still have to review the other author's code for that meeting.) Writing a critique will probably take the participant at least 30 minutes per critique.
- Organizer: a few hours total of scheduling, sending nag emails, and writing writeups like this one. :)
I'm opening comments on this post specifically to hear from other people who have participated in code review groups, about what has worked and not worked for you. And of course other people should feel free to reuse bits of these ideas to start groups that meet online, or go multilingual, or meet more or less frequently, or what have you!
: Hacker School
# 28 Nov 2014, 07:25PM GMT+5:30: Attachment:
From The Young Buddhists' Path To Success, by Venerable Master Hsing Yun, 1987, p. 25:
What the Buddhist youth lack today is a sense of ambition.
I'm turning this over in my head, half thoughtful and half amused.