monday, march 16, 2015
In high school, my principal accidentally taught me something: that publishing can give you a lot more access to power than you realized you had. This was pretty memorable, and I hope students are still learning this type of thing.
In 11th grade I was frustrated with some aspects of my public school, and it had no student publications or student government. This was 2004, so there was no Facebook for high school students or other obvious ways to have an organized, popular student backchannel online. After a fellow student tried to make an official newspaper and ran into obstacles, I decided it would be fun to run an underground newspaper: my classmates and I would report on weird and interesting things happening around campus, and we would decide exactly what we wanted to publish and when. Great! Here are the cover pages of the three issues I edited and distributed (with a name change for the third issue since I was told to stop using the school’s abbreviation):
Highlights included: a story about how a new guidance counselor turned out to be better than expected, a story about a “toxic cloud” terrorism drill we had to do, an opinion about the school district’s food policies, a report on an illicit juice box selling operation during a boring outdoor assembly, a gay student’s perspective on the “Don’t Ask, Don’t Tell” policy (he even went and talked to a military recruiter), a photo essay about the different kinds of games students played at break, a few poems, and lots of music reviews. Every back page quoted what the the California education code and Los Angeles Unified School District parent-student handbook had to say about student free speech rights. The newspaper was very ordinary, with not even very controversial content. The interesting part was that doing it without permission made our principal very, very angry.
While looking for these old newspaper files, I also found notes from when I called up the school district’s legal office and asked for verification of my right to produce and distribute the newspaper without permission, and asked about whether various school policies fit the district rules (turned out not entirely). I actually found a district administrator who was willing to give at least minimal answers to my questions, as just a random student at one of their zillions of high schools, which surprised me a lot. I didn’t find the nerve to write down all of what they said in the newspaper though. The principal was already upset with me for distributing the newspaper on campus without her permission, and I don’t know what she would have done if she’d found out that I’d called up the district and asked about the legality of her uniform policy.
She was controlling in general, so much that even a lot of teachers weren’t fans of her. One morning after I’d distributed a freshly xeroxed set of newspapers, she decided to go on the intercom and tell the whole school (K-12) that she wasn’t going to let a 17-year-old run her school, in a several-minutes-long speech that didn’t name me but was very clear about how unhappy she was with me and how disrespectful I was. In the few days after that speech, a few teachers quietly found me and told me that they supported the newspaper and thought we were doing good work. I found out that some writing, some friends, and some xeroxing could produce something that made a person with a lot of power over me scared of me.
She’s no longer the principal there, and the high school I graduated from no longer exists. It got transformed into a new school with many of the same teachers but a different focus — and it now has a journalism class with an official school blog written by students! They seem to have fun with it, and I hope they find some way to get dangerous when necessary and learn exciting new things, even if their blog doesn’t get proper free speech protection as a school-sponsored publication. And even if publishing on the web with your name constrains your options in a way that an all-paper newspaper didn’t for me. And even if people can now just make complex Tumblr networks instead of needing to do school-wide communication on visible folded sheets of paper…I’ll hope they’re finding out different and equally powerful lessons that way.
saturday, october 04, 2014
I wrote this on Facebook on October 4 and later realized it also works fine as a public post, so I’m posting an edited version here too, backdated to that day.
When I lived in Isla Vista, I daydreamed a lot about establishing an Isla Vista History Museum, which would be me occasionally setting up somewhere outside with a folding table and the tons of cool old images I’d found and stories I’d learned, talking to people who stopped by. I wanted to share some sense of connection to previous generations of students, some kind of pride in our weird little neighborhood. But I didn’t know what would happen if I tried it, and I never got around to just going for it.
Today I got a chance to set up an amateur history exhibit about San Francisco’s Market Street for a street fair that was part of an event themed around prototyping public art and other interventions for public spaces. I made some cards with entertaining/interesting information, and since I had to make this interactive (a theme of the event), I decided to provide paper for people to make their own pretend “plaques” for some memory or meaningful place along Market Street. This was a little bit of a cheesy idea, but it turned out better than expected — most of the people who stopped by told me something they knew about the street that wasn’t on the cards, and I asked them to write down their information to share with the next visitors. Everyone knows something interesting about where they live and spend time. I talked to my mom on the phone this evening, and she told me a cool thing about Market Street that she learned while living in San Francisco many years ago: the story of the company that built its street lights.
Display cards I made:
- There are ships buried under Market Street / Views under Market Street for promoting transit
- Why is Market Street set at an angle? / Landowners didn’t like the new Market Street
- Photos of a happy 1890s and then 1906 / Photos of growth in 1920s and struggle in 1969-1972
- Use an old nickname: call SoMa “South of the Slot”
- “A Trip Down Market Street” — A video taken a few days before the 1906 earthquake
- In 1935, merchants wanted to rename an unsuccessful Valencia Street to “South Market”
- 717 Market Street is an ordinary building — But even ordinary buildings on Market Street have cool stories
- Check out the Market Street Railway Mural — On 15th Street near Church Street (near Market)
- Examples of plaques on Market Street — For history, for memory, sometimes illustrated, placed by people for other people.
- Make your own pseudo-historical plaque
A couple of the nice contributed “plaques”:
So I tested my idea for informal history exhibits and it worked, at least in this context. Some people read the cards, some watched the old video of Market Street, some enjoyed talking. There weren’t that many people who came to the street fair, but eight people were interested enough in this table to sit down and write something down. I even met somebody who works in the Market Street building that I did a longer project on (717 Market Street), and he was interested in this so I gave him the printout of it.
A fellow Double Union member volunteered to hang out with me at the table and help talk to people, which was fun and also meant that we could take turns finding water and food occasionally. Thank you to her!
saturday, july 12, 2014
I’ve had a lot of fun helping developers in my community (who build extensions for jailbroken iOS) improve our developer documentation wiki over the past year, so in May I gave a talk about it at Write The Docs in Portland. This conference was exciting; I don’t often meet other people who actually care about technical writing, and there were a couple hundred of us and many good conversations. There are 29 talk videos online!
The following is my talk, in video and text. I hope it’s helpful for other people who work with volunteers and documentation. You can jump to about 6:26 if you prefer to skip introductions and context.
Hi everybody, sorry about that [setting up the slides went weird], I’m Britta, and this is what I’ve learned from reviving my community’s volunteer developer documentation wiki. I’ll explain how I ended up as a contributor, despite not being a developer at all, and then I’ll share my strategies for encouraging volunteers to help with it — with a little bit of social engineering and a lot of friendliness. Pretty much all documentation projects could use some more enthusiasm, and I wanted to share what I’ve learned so far, because hopefully this will help you with your projects too. And there’s an under construction gif [on the intro slide], because under construction gifs are pretty cool.
So for a few years, our wiki looked like this:
It looks like a MediaWiki install — OK, whatever. But it was somewhat cryptic.
It started with an outdated tagline, and then it had a list of “ideas on what to add to this wiki”, as if the wiki didn’t have anything yet. It did have a lot of good pages, they were just buried. But at least it was honest — it also said “it is a real challenge for a beginner — where to start?”
This is what it looks like now:
Still looks like a MediaWiki install, pretty standard. But it’s so much more exciting now!
There’s a up to date statement of goals, there are lists of the best articles and the newest articles, there’s a picture with an in-joke just for fun, there’s a big “Getting Started” section, it’s alive!
So what happened here? There are a lot of volunteer editors who have helped make this happen. They are pretty awesome, so I listed some of them here.
But before I explain, it’s probably helpful if you know what this community is — where do these people come from, and why do they care about it?
I work for the tiny three-person company that makes Cydia, which is the alternative to the App Store for jailbroken iPhones and other iOS devices. This is documentation for writing software for jailbroken iOS. Apple is not going to document how to use their private APIs, so we have to do it!
What is jailbreaking though? Let’s say you have an iPhone and you want to write some software that shows up on the lockscreen instead of being a normal self-contained app. That’s crazy. You can’t do that. Apple just doesn’t give you a way to do that. But wait a minute…
This is a lockscreen running custom software. [Credit: Typo5 Lockscreen by Patrick Muff, using Cydget by saurik.] You can use a specialized security exploit available for free — you can download it from the internet and put it on your phone — which removes Apple’s restrictions on the operating system. Then you can write crazy new software that adds new features and customizations to any part of iOS, and people distribute and sell this software in our alternative to the App Store. These developers mostly write this stuff for fun, and they might make some money on their products, but they don’t work for us; they’re not our employees. They’re volunteers when they’re writing on the wiki.
How do you get started writing these kinds of customizations? You’d probably want to learn about the tools and libraries that people have written for doing this, such as by reading some documentation. That’s usually a good start.
But for a long time we didn’t have much documentation. You had to figure out a lot of it on your own, and maybe ask some questions on IRC. When I started working for this company as a community manager, I was just working on user support forums and that kind of thing, because I’m not a developer. What do I know about developer documentation?
Occasionally I would poke developers and say “Oh, the wiki is looking a little neglected, maybe you should do something about that” — and they said “OK, I guess so. Sure.”
That didn’t work.
A new perspective
Here’s a story. Last year, just for fun, I started contributing to an open source project called OpenHatch, which teaches people how to contribute to open source projects. I’m a support person at heart, so I helped out by answering questions from developers about contributing. I answered questions about how to read a bug tracker, how to submit a patch, how to find the right documentation for the project they wanted to work on…that kind of thing.
But wait a minute, I’m helping developers with development questions. It turns out I know something about helping developers? OK, maybe I should actually join the developer IRC channels in my work community and see what I can do there too.
And that developer wiki — I actually know a lot about building wikis. I’ve been a Wikipedia contributor for twelve or thirteen years. I don’t know why I wasn’t feeling qualified to edit a wiki. OK, it was time to log in, click “edit”, and start fixing up that homepage.
This is what started my fight against inertia on my wiki. Contributing to open source projects can give you a new perspective on your work and new skills, and you can practice them in a low-pressure environment where people will often help you, because they want you to volunteer on their project. It’s also really fun. So, as an OpenHatch volunteer, if you have questions about being a new open source contributor, you can ask me! That’s my plug.
Now I’m going to go through a big list of strategies that I’ve learned while working on this wiki. Some of these will resonate for you and some won’t, so I’m going to throw a bunch out there.
0) Have somebody who cares hang out where the developers are.
My first step was to show up and hang out with the developers. For me, this meant joining the IRC channels (developer chat rooms). If your community has an IRC channel, that’s probably where the developers are. But this could be a mailing list, Twitter, forums, meetups, the engineer lunch table, whatever it is in your community or at your company.
1) Talk to newcomers and beginners.
You might start by asking the experienced developers to write things, since they know a lot, and if that works, that’s great. But usually they’re busy, or they don’t know what to write, or sometimes they ignore you, because well, who are you anyway?
But enthusiastic beginners are solid gold. They want documentation, they’re looking for it, they’ll read it if it exists (if they can find it), and they ask questions that reveal what’s missing. They ask redundant questions that show that something is hard to find, which is also useful to know. You can ask “What was the search path that you used?” to help you fix why they weren’t finding it.
You can ask these beginners to write things down as they learn, because they look up to you as a more established person in the community, even if you’re really new too. They don’t know better! As they get more experienced, if you’re lucky, they’ll keep on contributing. You can have a nice pipeline going on.
1a) Help identify useful info to write down.
I started by noticing useful conversations in these developer chatrooms and very, very gently asking “Would this be useful to put on the wiki?”
It turned out that people had forgotten about the wiki. It was kind of outdated and stale, and it didn’t seem useful to them, so they weren’t using it. That meant they didn’t know what was documented and what wasn’t. It didn’t occur to them that they could actually fix it.
So I started reminding people that maybe this specific useful bit of information (that people keep asking about) would be useful to write down. A few of them started saying “OK, I can do that.”
1b) Ask encouraging questions to counter anti- documentation concerns.
But important in this is that I don’t tell people what to do. I ask very innocent, gentle questions. Here are examples of questions I’ve used when people have the impulse to not write documentation, which happened a lot at the beginning.
I would hear “If people can’t learn this part on their own, they probably can’t build successful projects, because this is difficult, so we really shouldn’t write it down.” OK, but that gives nothing to beginners who want to learn. So I asked “Can you write a ‘prerequisites’ list of what people should know before they start exploring on their own?” Somehow that didn’t feel like it would give everything away, and people started writing that.
When people said “Nobody pays attention to the docs, so we shouldn’t bother writing them”, I said that people would pay attention if we used the right teaching strategy. I asked these volunteers “What problems do people run into if they don’t read the docs? Let’s write down advice for these people too, so that when they show up on IRC and clearly did not read anything before they got started — very ‘exploratory’ learners — then we have a page for them, oriented toward people who tried something that didn’t work.”
Or I’d suggest to somebody to write something down, and they’d say “I don’t know enough to write this”, so I’d say “Can you add a ‘this is missing’ note to the right place in the wiki?” — and then often, magically, in the next few days somebody would fill out that spot. Having somebody point out that something is missing turns out to be valuable.
2) Think of it as a marketing problem. Make the homepage enticing to click!
As I was working on this, I realized…this is a marketing problem. Marketing is not a bad word. I’m trying to: identify the value of this documentation and communicate that value to people who need it, in order to get them to use it and contribute to it for other people. That’s the definition of marketing. The value of documentation is not obvious to everyone. Sometimes you have to figure out how to sell it!
Part of this was to make the homepage really enticing to click. Put the best articles way up front! Write a really grand tagline with a great statement of goals. I put a picture on the front page so that it had some kind of “visual identity”. Try to make it something to be proud of.
2a) More marketing: build new articles that attract more visitors.
Another part of marketing was that I helped build articles people wanted and then promoted those articles. For example, I helped with this giant table of open source projects that people can look at as example code. This made developers feel great since their projects were mentioned on the wiki, and this list felt valuable to people since it was a huge list of resources…so they kept sharing it on Twitter. Huh. This list was also really easy for people to contribute to, since all they had to do was log in and add their project, which meant lots of people signed up for wiki accounts (yesss).
This list was outside the normal scope of our documentation wiki, but that was OK. It attracted people to the wiki, and when people hear about it, some of them are going to want to start contributing.
3) Make writing more fun: show that people read it.
Many developers don’t ordinarily find it fun to work on documentation. Writing code is fun for them! They like discovering new things, and very importantly, they’re releasing them to an audience who wants them — an audience who says “Yes! Please give me more features! And here are all my support problems…” OK, maybe support isn’t that fun. But generally, releasing software is fun. You have this really good feedback loop with people who are using your work.
Contributing to the wiki felt lonely. Even if three people read your article that afternoon, you had no idea. Nobody said thanks — because they’d have to log into the wiki and click “edit”, and people don’t know how to edit, and they don’t know how to write on talk pages — so nobody was thanking anyone for working on the wiki.
So I wanted to show them that people are reading their work!
3a) Make it more fun by copyediting new stuff.
Whenever anyone added anything, I went in and copyedited it or added some formatting. This was an immediately visible way to prove to writers that somebody read their work. It added some feedback loop to the wiki process.
This also helped people feel more confident in contributing. A lot of these developers speak English as their third or fourth language, or writing just isn’t their main skill. And a lot of them are about fifteen — they don’t necessarily have a lot of technical writing experience yet. They appreciated getting some friendly feedback on their writing, and I added syntax highlighting to their code snippets, so it looked great. People like that!
3b) Make it more fun by making it look active.
Nobody likes hanging out in a ghost town. (OK, some people like hanging out in ghost towns, but they’re kind of weird. They’re cool, but they’re weird.) On a wiki, if there have been no edits for the past month, you’re going to think that nobody looks at the wiki, so why bother throwing your words into the void? I make sure that the “Recent Changes” page always has something on it, something in the past few days — even just some copyedits.
We list new articles on the homepage. It’s great if the homepage keeps changing with new stuff, so that it always feels fresh and active — something people feel they should check on. They know that if they add something, it’ll get featured on the homepage too.
c) Make it more fun by thanking people.
And we make it more fun by thanking people! If you write an article, and nobody says thank you, that is the definition of a thankless task.
Readers aren’t necessarily going to write thanks, even if they appreciate something, so this is something that I do. I write thanks to writers on their wiki talk pages, on IRC, on Twitter, everywhere. Writing thanks publicly on my work Twitter account shows that this is a priority for the community, and what’s funny is that by writing stuff on Twitter…who knew, you’re promoting the wiki again!
To write thanks effectively: do it right away, be really specific about what they did that was awesome, and say it publicly. [Credit: as discussed on the OpenHatch mailing list.] It makes people feel good, and it’s super easy. It’s the best.
4) Be there to give people permission.
Some of the people in my community felt like they needed permission to contribute to the wiki. These are often the very best people, because they’re very polite, and they’re very careful, and they don’t want to mess it up. Or they don’t feel like they’re qualified to write, a little bit of impostor syndrome.
So I’m there on IRC to be a person they can ask whether adding something would be a good idea. Of course, I’m always saying “Yes, go ahead! It’s OK if it’s not perfect, we’ll fix it!”
5) The docs system needs docs.
Here’s something that surprised me recently: the docs system needs docs! We had a jailbreaking conference last month, and I ran a little workshop for working on our wiki. Even though these volunteers are amazingly brilliant developers who can read assembly code, reverse engineer iOS, and write really complicated programs, they were asking me questions about MediaWiki editing syntax.
Because MediaWiki is a little frustrating and confusing for everyone, no matter how amazing they are. You need cheatsheet links and explanations of how to edit the wiki, even if your community is absolutely brilliant.
6) Leave rough edges for others to smooth out.
This part is a classic bit of wiki social engineering — you leave around a few obvious mistakes and easy tasks, like typos somewhere in the wiki, because that will entice new people to click “edit” and start contributing. They’re thinking “Oh that’s easy, I can fix that!” Once you get them to log in and make an account, that’s the first step — it’s good.
You can also make a list of easy “bite-sized” tasks for new editors, such as contributing to that list of open source projects. I put this in an obvious place on the homepage to help people get started.
6a) Write bad first drafts as motivation.
Another funny social engineering trick: writing bad first drafts as motivation for people to fix stuff. One of the best developers I know told me this recently: that if I want him to help with the wiki, I should write some really terrible documentation myself, even about something I don’t fully understand, and then show him what I did, because he’s going to be like “oh my god” and go fix it. That’s how to motivate him. It’s great advice.
This is, again, why beginners are solid gold. Experienced developers often have no idea what needs to be written — they need a draft, or an outline, or something else to get started with that isn’t a blank page. Beginners are perfect for writing this. Like me, as a beginner in a funny way since I’m not a developer.
Then I start wondering if this is going to end up with me becoming a developer too. What if I learned some Objective-C so that I could skip all of this work and just write documentation by myself? That starts to sound easier… This is one strategy I haven’t tried yet. It would be kind of hilarious. We’ll see.
Thanks! If you also have volunteers and you try to motivate them, I want to know what you do and learn about your strategies too.
In response to this talk, I got a nice email from a person who noted that for his team’s wiki, it was helpful to install a MediaWiki extension that automatically displays credit to article contributors. I like this idea and might try to convince our dev wiki maintainer to add it.
thursday, march 06, 2014
In August, I gave a talk at JailbreakCon, an annual conference that gathers together fans of jailbreaking and people who help make jailbreaking happen. This is a large and complex community: security researchers who develop the jailbreaks themselves, developers who make software for jailbroken iOS, designers who make themes for jailbroken iOS, repository managers (who host those software packages and themes), documentation and support forum helpers, bloggers and video makers, the three of us who work on Cydia as SaurikIT, and others. It’s pretty great to see each other in person, and to meet lots of other people who are into jailbreaking. (If this sounds interesting, JailbreakCon 2014 will be April 12-13 in the Bay Area.)
Instead of doing a typical JailbreakCon talk explaining something about security research or software development, I decided to look at the reasons why we care about those technical parts. Why have tens of millions of people figured out how to jailbreak their iOS devices and use Cydia, and why have hundreds of people spent money on planes and cars to talk to each other about these things in person? This is fascinating and exciting to me, and I’d like to convince you to be fascinated and excited too.
Here’s a video and a slightly-edited transcript for people who prefer reading. But the video might be entertaining; I’m pretty enthusiastic in it.
What I think is interesting to talk about is: why did you jailbreak your phone? Oh, I should introduce myself first; I work for saurik on community and support for Cydia. A lot of the time I stay a bit behind the scenes, but I moderate forums like JailbreakQA and /r/jailbreak (the subreddit), and I write some of the information inside Cydia.
So. Why did you jailbreak your phone? It’s sort of an obvious question. Usually people answer it with something like “I wanted to delete Newsstand”, or “I wanted quick-reply for text messages”, or “I wanted to toggle WiFi and 3G on and off more quickly, because Apple’s way of doing that is really lame”. These are very reasonable answers. But if you asked people a few years ago, they would have said: “I wanted to customize my wallpaper because Apple won’t let me”, or “I wanted to put apps in folders”, or “I wanted to record video”.
But these sound like entirely different reasons to jailbreak; there’s not much in common since the old reasons are part of iOS now. So, what’s going on with that? Do these reasons change all the time? Every time a new iOS version gets ready to be released, a bunch of tech blogs publish articles like this one:
They say, “Is jailbreaking dead? Is there any reason to jailbreak anymore, because all of the old cool features are now part of iOS?” But each jailbreak is more popular than the last one: evasi0n was even bigger than Absinthe, which was bigger than the ones before that. So something else is going on here, something strange.
My hypothesis is that even though you think the reason you jailbroke your phone was to get Five Icon Dock or WinterBoard — instead there was a more durable reason that hides in the background. I think this reason, at least for me, is to get access to this rich, complicated, hybridized primordial soup of software features. They’re not just the features and decisions that one company in California made, but this cornucopia of product decisions made by lots of people, such as the people in this room — with lots of conflicting and different ideas, like four or five different kinds of app switchers — which is awesome.
Something that I like, that most of you probably aren’t into, is fanfiction: where you take a TV show, or in this case an operating system, and you build new stories or new features on top of it, unauthorized. The quality of these stories and features may vary widely, and they may have conflicting plotlines — you have one TV show with sixteen fan stories that go off in different directions, or you have sixteen different features built on the same operating system with different ideas of how something should work.
And it’s really fun. People have these different visions of what software can be like. It’s creative, and it’s playful, and it generates a lot of good stuff along with the stuff that’s not so good. One company can’t cover everything that somebody wants out of a device. They can get to maybe 90% if they’re Apple, but there’s that last 10% of something that bugs you, or something that could be cooler, and jailbreakers are great at filling up that last 10% with awesome stuff.
We can take their pretty good operating system and write our own stories with their characters. We can fill in the missing scenes in Notification Center or the lockscreen, even if Apple wants to be the only person telling stories with this interface. Some of these features may be implemented by Apple someday, but there will always be new ones that we’ll make up, because you don’t run out of stories. A lot of them Apple will just never add, because they require extra battery or memory, or they’re confusing for ordinary people, or they’re just kind of goofy. Like this one, which is one of my favorites, called NyanSliders, where the sliders are Nyan Cats:
This should be animated; they do the little running dance as you change your volume. That’s cool! Jailbreaking is this big prototyping lab where we can experiment with what software interfaces can do, and how we can make them more fun. Instead of coming up with a concept in Photoshop, and everybody just thinks “that’s a cool way to do keyboards”, you can implement that feature right away. You don’t have to wait for Apple to maybe see your blog post, and maybe decide that it’s OK for them to implement it. You can do it right now, and see how it works. Like SwipeSelection, an alternate way to use your keyboard, which sounds kind of cool and kind of weird, and then you use it, and it’s interesting. It’s maybe not perfect, but it’s valuable to have this experimental attitude and experience.
That’s one reason to jailbreak! There are more reasons. I won’t list all of them, because I’ll be here all day. But one thing, that I think doesn’t get enough appreciation, is being able to turn off features in iOS. I maintain the featured packages list in Cydia, and one day we realized that we should have a special list of packages that start with “no”:
That’s NoCoverFlow, NoNewsIsGoodNews, NoPasscodeBlock, and NoStoreButton, and if you search Cydia for “no”, you’ll see a lot more of these tweaks that turn off annoying features that Apple doesn’t provide options to disable. Like “shake to undo” — a lot of people just find that feature irritating. And you can fix Apple’s default features that favor their own apps instead of App Store apps, such as BrowserChanger if you like Chrome, or MapsOpener if you like Google Maps, which makes a more level playing field. So that’s one set of reasons: you can add features and you can take them away, which is useful.
There’s a second reason that I find interesting, which is that you jailbreak because you can, because you should be able to jailbreak your device. To be able to use your phone as a general-computing device instead of a limited device, and to have the capability to do research on the software to verify that it does what Apple says it does, that’s cool.
It goes along with a third reason that is important to me: jailbreaking is a way to learn something, to explore a technical subject even for a lot of people who have no experience. These people can be frustrating — you have a lot of new people who ask…seemingly-dumb questions. But let’s say you’re a kid who doesn’t have your own computer, but you’re playing around with jailbreaking your iPod touch and asking questions about it, and you are on your way to learning something technical that you might not have had a chance to learn otherwise. This is great.
You end up learning this whole new vocabulary: what is a bootrom? What is a kernel? What are SHSH blobs? SHSH blobs are this complicated cryptography-related concept that millions of people are now dealing with on a regular basis — that’s amazing. When you open up iFile, the whole iOS filesystem is right there. Even a desktop computer will try to hide parts of the filesystem from you because it doesn’t think you can handle that. But in iFile, it’s there for exploring. You can even SSH into your phone and learn how to use the command line.
And if you mess up your phone, you can restore it. If you mess up your desktop computer, or your mom’s desktop computer, that is going to be a massive hassle, and it’s going to take you more than half an hour to fix that. If you restore your phone after deleting a system file, it’ll take you half an hour, and it’s kind of a hassle since you lost your jailbreak, but it won’t ruin your day. Well, maybe. But it won’t ruin your mom’s day, which can be important!
This educational reason might not be the first thing that occurs to people when you ask them why they jailbroke their phone. Nobody is going to say “I wanted to learn more about SHSH blobs”, but learning new things is a hidden and powerful reason that keeps people in the jailbreaking community. They can even start writing code without asking Apple for permission or paying Apple, which is great.
I see this on the forums that I moderate. Somebody comes in asking a “dumb” question, and a few months later you see them pop up again, answering a question about how to downgrade a baseband. You might be like “Whoa! Where did that come from?” — but that person has been learning and reading the whole time. It warms my little heart, and it’s a big part of why I work on this stuff. I like to imagine we’re training a whole secret generation of people who actually know how to tinker with computers.
So if somebody asks you why you jailbroke your phone, it’s probably still best to say “oh, I have this cool theme”, because if you try to explain all this, they might get confused and bored — but hopefully it’ll linger in the back of your mind that there are these deeper, more important reasons why we do this stuff and spend time with it.
I also convinced a few of the newer developers attending the conference to get up in front of everyone and give a series of two-minute talks after mine! Here we are among the other speakers:
saturday, july 20, 2013
Last month I went to AdaCamp and learned a ton partly because the Ada Initiative runs it both as a place to discuss solving problems and as a testbed for better ways to hold conferences. Lots of conferences try to encourage a diverse group of participants and speakers, but making conferences better is specifically part of the Ada Initiative’s mission, and this was especially fun because a bunch of the participants were community organizers/managers/coordinators like me. Among topics such as running real-life meetups for open source projects and the ramifications of using gender-neutral usernames, we talked a lot about AdaCamp itself!
I’m in Portland for Community Leadership Summit this weekend, I’ll be at Defcon soon, and I’m going to XOXO in September, so I’ve been thinking about things AdaCamp did that I’d like to see more conference organizers consider. Of course I like the idea of making tech events better for women, but this stuff is especially interesting to me because worthwhile efforts to make a tech event more welcoming to women also make the event more welcoming to other non-majority types of people (for example, including women means not just including able-bodied women). It’s the magic of intersectionality! Some of these ideas are conveniently compiled on the page of resources for conference organizers on the Geek Feminism Wiki, but here’s my list too:
- If you have an application process, like AdaCamp and XOXO do, it’s great for the application to be as encouraging and inclusive as possible, with detail about how the conference is aiming for a crowd that is diverse in x and y and z ways. This is because an application process can discourage people who tend toward “impostor syndrome”: the feeling that you’re not cool enough for that conference, even if you’re actually the perfect attendee. At AdaCamp we talked about how this type of self-doubt is common in women who work in technical fields, and I imagine it’s also common among other kinds of non-majority people (or even simply people with anxiety issues). A conference missing those people would not be the best possible conference!
- Before the conference, providing a list of nearby low-cost hostels and hotels. I’ve seen some conferences listing nearby hotels, but a lot of AdaCamp attendees appreciated seeing the lowest-cost hostel options as well as the usual options.
- Giving people a choice of badge lanyards: green meaning “photographs always ok”, yellow meaning “ask before photographing”, and red meaning “photographs never ok”. This can help people feel more comfortable, especially if they’re concerned about photos getting online with nasty comments attached to them. Defcon recently switched from “no photos” to “photos OK”; I don’t know whether switching to color-coded lanyards would be respected or mocked there, but I wonder if the organizers have considered it.
- Laying blue tape on the floor to mark access paths where people shouldn’t stand or put chairs/bags; you can label them “walk and roll” (ha ha). This is especially useful for people using wheelchairs and other tools to move around, but it’s also great for people who don’t like being stuck in crowds (pretty much everyone).
- Being explicitly inclusive of people of all gender identities, including considering labeling all-gender bathrooms along with men-only bathrooms and women-only bathrooms. The AdaCamp organizers emailed the attendee group with a proposal: since the venue provided two sets of women’s bathrooms and two sets of men’s bathrooms, and the conference would have 200 women and 20 men, and some people prefer single-gender bathrooms and some prefer all-gender bathrooms, how about re-labeling one set of men’s bathrooms as all-gender bathrooms (with a sign asking people not to use the urinals)? People agreed, and it worked well. I’d also be happy with organizers asking attendees for permission to re-label some women’s bathrooms as all-gender at conferences that generate long lines for men’s bathrooms (nobody likes long lines).
- Setting up a dedicated “quiet room” with a rule against talking in that room; people can use the space to nap or work/relax quietly. This is helpful for anyone who wants a moment to escape from the relentless socializing of conferences, since not everyone always has a nearby hotel room. (And not a “chillout” lounge like DefCon has, which is supposed to be low-key but isn’t very relaxing — music mixing with the sounds of people trying to hire each other, bad efforts at flirting, and groans of sleep deprivation.)
- Having a series of 90 second (1 slide) lightning talks - I thought 90 seconds sounded impossibly short compared to normal 5 minute lightning talks, but it turned out to be great. It’s fun to see tiny windows into what people find important enough to share, and it almost feels like watching a game that tests people’s sense of timing. The rules excluded doing recruiting pitches or ads for commercial products, which helped keep things interesting. 90 seconds is also short enough that even inexperienced speakers can plan something without a lot of preparation, giving them confidence for future speaking. (I told AdaCamp how playing Nethack as a kid gave me a sense of familiar territory when I later encountered the command line, and I was delighted that people enjoyed my tiny speech.)
- For evening meals: creating a spreadsheet on Google Docs with a list of nearby restaurants, and inviting people to type in their names to create small groups for dining out. There can also be a spot for naming a theme for the group (such as “open source community building” or “feminist nonprofits”), to help people find a group to join. At AdaCamp, this was a pleasant way for even shy people to opt into meeting new friends; the spreadsheet limited each group to ten people to keep things reasonable.
I haven’t been to WisCon, but its “Universal Design” accessibility policies and details go into more depth than I learned about at AdaCamp…a mind-boggling level of depth.