Disambiguation, In-Jokes, and Name Collisions: What You Need to Know When Naming a Python Project

Content notes: codes of conduct, colonization, natural disasters, ageism, racism, interpersonal violence, actual snakes

I gave this talk at North Bay Python. I’ve included the text of the talk below, as well as the video.

Names matter.

Names set expectations: a conference with a location name in its title  is probably in that location and a Python module with the word “test” in it will do something to do with testing. If North Bay Python took place south of the Bay, we’d all have some questions for the conference organizers.

Names create first impressions. Just reading the name of a project can immediately tell someone whether they’re going to use or contribute to that project. I’ve seen plenty of offensive library names and I’ve decided not to use those libraries just because of their names. I don’t need to look for a code of conduct or at the quality of the code of a project with an offensive name. I just move on. If you really want examples of those names, talk to me privately because I frankly don’t want to say them in public. 

There’s a business case against using software modules with problematic names, if you work in the sort of organization that requires a business case to do the right thing: any core maintainer unable to respond to feedback about a problematic name will be unable to  consider security risks that don’t impact them directly.

Names endure. Think about where we are right now. Petaluma. Sonoma County. California. The United States of America. The US got its name during the American Revolution. It was purposely structured to make a bunch of colonies sound like they were all working together and knew what they were doing. California is named for a magical island in a 16th-century Spanish romance novel. So, yeah, we use a name from a bunch of Spanish conquistadors thinking fondly of the love stories they read growing up.

Sonoma and Petaluma both come from Coastal Miwok words made to sound more acceptable to the Europeans who colonized this area. Sonoma’s root word means “Valley of the Moon”. Péta Lúuma was the name of the Miwok town located roughly here prior to the area being controlled by the Spanish, the English, the Spanish again, the Russians, the Mexican Empire, the Mexican Republic, the California Republic, and the United States.

Most dialects of Miwok are now extinct, due to the US’s genocidal policies with some European help. Before 1579, Coast Miwok tribal land included all of Marin County plus southern Sonoma County. By 1817, the only land still directly controlled by the Miwok was the Pacific Coast of the Marin Peninsula, from Point Reyes north to Bodega Bay. In 1920, Miwok and southern Pomo tribes tried to move to the 15 acre Graton Rancheria, held in trust by the federal government, but only 3 of the acres were actually habitable. The US government dissolved that trust in 1958 and ended federal recognition of the tribe until the Graton Rancheria Restoration Act was passed in 2000. 

The name “Petaluma” endures. 

Humans relate to names in deeply emotional and often unnoticed ways. Let’s go to natural disasters for a potentially less depressing example: researchers at the University of Michigan looked into whether people are likely to donate to hurricane aid causes if they connect with the hurricane’s name. Folks who shared a first initial with the hurricane’s name were significantly more likely to donate. That means that Kelly’s, Kai’s, and Khadija’s were more likely to donate to relief efforts for Hurricane Katrina than Hurricane Mitch. 

Correlation isn’t causation, but I will guarantee you that there is someone out there thinking about how much money they could raise by choosing a hurricane naming schema with a distribution of first initials more closely matching the distribution of first initials of all our names. 

Names don’t exist in a vacuum. Making sure we understand the context and nuances of potential names is a necessary first step.

Python Naming Schema

Question for the audience: Who here knows what inspired the name of the Python programming language?

Monty Python — that’s right!

Monty Python is a British sketch troupe who have turned 45 episodes made between 1969 and 1973 into a bunch of movies, books, games, a musical, and a few other things. 

I’m making sure to describe exactly what Monty Python is, because we can’t assume that everyone using the Python programming language also is culturally fluent in Monty Python. I have heard: “Monty Python? I think my grandparents used to watch that.”

That’s because Monty Python turns 50 next year. We might as well be asking programmers to get references to The Beverly Hillbillies, Petticoat Junction, or Green Acres. That in itself isn’t necessarily a problem, but some jokes age better than others. Monty Python isn’t aging particularly well. 

By expecting Python programmers to be familiar with Monty Python’s body of work, we’re sending them to look up sketches with titles that include the N word. I don’t think any of us want to accidentally endorse something like that. 

I’m not saying you can’t ever make a Monty Python reference again. I am saying we all have to consider the context of our references before slapping them on projects we want to share with the whole world. I’d ask you to think about it the same way you might think about putting a picture of an actual python in the middle of killing its prey up on your project’s homepage. No matter how cool all of you are with snakes, I am more interested in snake jokes and references than I am in snakes themselves.

Within the Python programming community, we’ve established some standard naming schemas, both formally and informally. 

We have PEP 8, the style guide for Python code, which includes naming conventions for variables, method names, and such. It doesn’t include suggestions for how to name projects, though there is a little piece of advice I’d love to have engraved on something shiny: avoid names that include the lowercase letter “l”, uppercase letter “O”, or uppercase letter “I”. I think that these suggestions should be followed for more than just single character variable names. They just make names easier to read and retype.

We also have less formal systems, especially for project names. For instance, many Python conferences and user groups include the city they’re located in their organizational names. Geography is a relatively easy way to disambiguate different local communities from larger overarching communities. We can tell that PyLadies Atlanta and PyLadies Santo Domingo are two separate groups. It gets even easier because there are unique identifiers for different locations in the form of IATA codes. IATA makes sure airport codes are unique, since there are very important differences between Portland, Oregon and Portland, Maine, if only because my cats are in Portland, Oregon and they expect me to fly to the correct city today in order to feed them dinner. IATA’s codes are so convenient that sometimes cities use them as nicknames or identifiers . Not all cities’ IATA codes are exactly intuitive. Chicago airports, you better believe I’m looking at you right now.

And while I will always struggle to remember that tickets to both ORD and MDW will get me to Chicago, the sort of “Py*” prefix used in PyLadies has become an easy-to-remember signal that a module is meant for use with Python. There are a variety ways “Py” has slid into Python project names, beyond just the prefix.

Some projects have chosen words whose letters already include “Py”, like Pyramid. “Pi”, spelled with an I instead of a Y, is pronounced the same way (at least in English), so there are also names that use nonstandard spelling like Project Jupyter. And then there’s the word “Pie”, which sounds like “Py” and is generally delicious. CherryPy, for instance, follows this naming schema.

A lot of projects have developed their own internal naming schema as well and for good reason. When related projects are branded together, users are more likely to realize that they can use all the different pieces you create. BeeWare, for instance, uses a combination of puns — so many puns — bees, and history, to create impressively descriptive names. First off, BeeWare has a subtitle, a full name, if you will. It’s BeeWare: the IDEs of Python. As in, what Julius Caesar was told in Shakespeare’s play of the same name, just before he was assassinated by a bunch of dudes in togas, except they’re referencing interactive development environments, rather than the middle of March.. 

As it happens, Toga is the name of a BeeWare library which provides wrappers for GUI APIs. Because of course, it is. Just like, of course, the name of BeeWare’s prevalidater is Beefore, with two Es. 

If it sounds like I’m saying a lot of names, that’s because we name a lot of things. We name them pretty fast, too — fast enough that there are multiples sets of projects sharing a name. I’m willing to bet that most of us in this room have heard of Django, the Python-based web framework. But there’s also a piece of tablature software for musicians, also named Django. 

Name collisions are annoying when you’re debugging a program, but they are a full on pain in the rear when you’re trying to search for help online. How many times have you walked away from a meetup or a conference with a Python module in mind to look up once you get home? You really only have three hopes for success for remembering the name:: the project has a memorable name, your new contact remembers to forward you that link, or you manage to find it through a search engine. You might wind up adding a bunch of keywords to your search terms, adding and removing words until you fight the right incantation to summon whichever library you’re looking for.

And if you’re looking for Python modules to help you with your herpetology research, I don’t even know what to tell you, except that I guess some herpetologists might have made the situation much more complicated by naming a species of python after Monty Python. 

Name collisions are our future, by the way. Unique identifiers are hard.

Name Selection

As we’re choosing names for Python projects, we have to keep all of these things in our head. Because that seems like an easy way to manage such a big decision, right? Nah, I’m just joking, that sounds super hard.

I actually just went over all of that stuff with you so that I could go over this checklist:

  • Check for how this name may be used elsewhere
  • Talk to actual humans about the name and what it means to them
  • Maaaaaaaaybe talk to a lawyer
  • Listen to the actual humans, no matter whether they respond positively or negatively
  • Make sure you can get any necessary accounts
  • Write down the meaning and history of your project’s name before you forget about it

In short, we’re going to go through a due diligence process before finalizing a name for a new project. Some of these steps can happen in different orders, but I want you to check off every item on this list before buying another sweet domain name. 

And if you’re worried that these rules will eliminate all the good domain names, rest assured that isn’t an issue. Let me put it this way: despite following these steps, I still own way too many domain names.

Check for how this name may be used elsewhere

Checking how a particular name is used can be as simple as running some online searches. Start with Google or DuckDuckGo or whatever flavor of search engine you prefer. Go a couple pages deep into those results. Depending on the words you’re looking at, you may get a Wikipedia disambiguation page, which honestly does a lot of the work here for you. On a practical level, we want to make sure there isn’t a major module out there already under a name you want to use. Wikipedia tends to be more up-to-date about programming modules than a lot of other topics. 

Do the same on Twitter, and click around to all those tabs that show up on the search page. You can look at what tweets mentioning your keyword are the most popular, usernames which include the keywords and so own. I’ve found that this is one of the easier ways to check both newly evolving words and to surface name collisions in other languages.

Go to Urban Dictionary, too. Before you actually type things into search boxes, though, I should definitely point out that Urban Dictionary is routinely NSFW. Twitter is also routinely NSFW, but for entirely different reasons. In this use case, you’re looking for NSFW terms that relate to your name — things that you may be too mature to respond to, but that other users would giggle at or find offensive. As such, maybe don’t assign this job to an intern or first-time contributor.

Basically, we’re looking for any terrible ways a bored thirteen-year-old can twist your project name. We can’t preempt every comment, but we do not have to make it easy. 

Talk to actual humans about the name and what it means to them

Next, and this is probably the hardest part, I’m going to need you to talk to actual humans, starting with any stakeholders interested in whatever project you’re working on. Depending on what kind of project you’re naming, your stakeholders could include employers and their lawyers, contributors (including documentation writers, who will need to type that name over and over again until it loses all meaning), and all of your friends who will have to listen to you talk about this project incessantly. 

You’re going to also want to check in with your potential users about your name. Spend just as much time on talking to potential users about naming as you do on more visual user experiences. Check how they spell the name when they hear it for the first time. Check how they pronounce it if they read the name before hearing it. This might sound like a marketing exercise, but it’s really a question of usability and accessibility. If a user can’t figure out how to spell a product name, they’ll have to deal with a high level of friction before even deciding whether learning about a given tool is worth scrolling. 

Tempting as it may be to ignore asking anyone outside of tech, I want you to make a point of running of names past at least three people who don’t work in tech. If you’re headed home for a holiday visit, feel free to ask your family to talk to you about your name idea. You can never guess who will run into what information and interact with it. You certainly can’t control it — if you could, every member of my family would be banned from ever seeing the word “Bitcoin”.

Your family members count as one person in this case, by the way. You can probably assume that your family’s background is close enough to your own that you’ll want to make sure to get some other opinions. You want to talk to folks who come from backgrounds different than your own because they’ll help you predict responses to that name from more people. 

Personally, I like to ask a kid about any names I’m considering. At the very least I will immediately hear any possible poop jokes about my name selection, long before any adult will work up the courage to discuss possible scatological references.

A person with a little distance from the project can also help you catch names that are hilarious to you but rely on insider knowledge. Sometimes those sorts of in-jokes confuse or exclude people, making it even harder to get up to speed with a new library. If you can’t explain the joke in the time it takes us to walk to wherever we’re eating today, your sense of humor may be too subtle for the rest of us.

One more note about humor: think about who you are making fun of. Punching up is funny. I feel comfortable snarking about Monty Python because the members of that comedy troupe have made serious bank and have legions of fans ready to talk about the good points of their careers. Punching down is boring. If I want to watch someone make jokes at other people’s expenses or use humor to be a bully, I can just watch the news. 

Check in with folks who speak languages you don’t, along with speakers of different dialects. Python is used all over the world, in more than 150 countries, so you’re never going to be able to check against all languages, but do what you can. 

Maaaaaaaaybe talk to a lawyer

Occasionally, a lawyer may be useful in this process. I am not a lawyer and therefore all I can say that there are very few situations in which I would personally feel the need to consult a lawyer before finalizing the name for a new project. It’s pretty much just edgecases, like wanting to use a name already claimed by a multinational corporation. Future Thursday may hate me for this, but any smaller legal issues are her problem. Do your own risk assessment, though.

Listen to the actual humans, no matter whether they respond positively or negatively

Why is listening a separate step? Because we don’t just want first impressions. We want to know what sort of connections endure. We want to know about those jokes that take people a minute to remember. We want to hear any “Oh crap do you know what that sounds like?” moments.

Make sure you can get any necessary accounts

On a purely practical level, you’re going to need to know if you can get domain names, GitHub repos, or any other accounts you might use. If you’re reusing a name that’s already been associated with one software project, you’re going to have to do a little extra running around before you can finalize your name.

Very few platforms have a system for aging out old accounts yet, so there’s no clear date when any software project is permanently inactive. Some open source projects go years between releases, with no real need to update a website or a Twitter account in between. You have to use your best judgement.

Check the old project’s materials for trademarks, copyrights, and other indicators of intellectual property. No matter how any of us feel about intellectual property laws, I think can assume none of us really want to get sued. It’s not impossible to unravel intellectual property from a defunct project. I have never found a name I consider worth that level of effort. 

Luckily, since we’re already talking to humans, we can just add the person last known to be running a given project to the list: if there’s a maintainer listed or even a contact form, just reach out and ask what’s going on with the project. If it’s actually defunct, ask if you can have their domain names and platform accounts. Make it as easy as possible on the other person and offer to pay for any fees, like domain transfer fees.

Even if there isn’t a pre-existing project, domain names can be tricky. Anyone working on anything related to any of the items on that Wikipedia disambiguation page could have already bought the domain name you want. Luckily, most Python projects are targeted towards audiences familiar enough with the internet to not flinch at the sight of non-dotcom domain names, like .io. That opens up options. Options for more research, I mean: That domain name is assigned to a part of the Indian Ocean currently referred to by the name British Indian Ocean Territory. Previously, that area was known as the Chagos Islands, mostly to the Chagossians, who the British forcibly removed from the Chagos Islands in 1966. Oh, look, another terrible example of how names reflect colonization! Using a .io address means taking this information into account.

Write down the meaning and history of your project’s name before you forget about it

Lastly, PLEASE PLEASE PLEASE document at least a little information about your project’s name. Just stick it in your README or some other piece of your documentation where it’s easy to find. Your documentation is a great place to put information about your project’s name and why you chose it. 

Write down the pronunciation of the name that you use, even if you think it’s obvious. If you really want to know why I started working on a Python-specific style guide, it’s because of PyQt. That’s four consonants in a row, just hanging out. I’m pretty fond of vowels, so I wasn’t sure at first how to pronounce PyQt. I googled it, but I did not have a lot of luck.

Address any potential issues right away. Make a note of what other uses of the project’s name that you’ll need to disambiguate from. Django documentarians might make a note about music, for instance, so that someone creating a Django plugin meant to be used by musicians will pick a name that will actually be searchable. Address any potential problems head on, as well. Including context about a location name, for instance, will let you make sure people know which Portland you live in. 

Go ahead and tell any jokes that go along with your project’s name right there in the documentation. Humor is amazingly memorable, but we only get that memory boost when we get the joke. It’s okay if not everyone gets the joke at first — jokes are still funny after they’re shared.

Takeaways

  • Names matter, even names that have existed for hundreds of years
  • Maybe don’t use Monty Python as a key part of your naming conventions
  • Complete due diligence on any name you consider

Glitter, Radical Protests, and Tee Ball on the South Lawn.

Saul Alinsky’s Rules for Radicals

The whole book is a useful read, albeit a bit dated — it was published by a professional organizer in 1971. But Alinsky’s rules remain widely applicable:

  1. Power is not only what you have, but what the enemy thinks you have.
  2. Never go outside the expertise of your people.
  3. Whenever possible, go outside the expertise of the enemy.
  4. Make the enemy live up to its own book of rules.
  5. Ridicule is man’s most potent weapon.
  6. A good tactic is one your people enjoy.
  7. A tactic that drags on too long becomes a drag.
  8. Keep the pressure on. Never let up.
  9. The threat is usually more terrifying than the thing itself.
  10. The major premise for tactics is the development of operations that will maintain a constant pressure upon the opposition.
  11. If you push a negative hard enough, it will push through and become a positive.
  12. The price of a successful attack is a constructive alternative.
  13. Pick the target, freeze it, personalize it, and polarize it.

A Glitter-Infused Protest

Reading today’s headlines would have made Saul Alinsky proud: around 200 activists grabbed the national news cycle by holding a dance party. Of course, holding the dance party outside of the vice president-elect’s home in Washington, D.C. definitely helped.

A Brief Buyer’s Guide: Glitter

I do not like the aftermath of glitter. Glitter gets everywhere and stays there for approximately the rest of forever. Seriously, glitter is so good at adhering to things that forensic scientists have written lengthy odes to glitter’s value in solving crimes.

But we’re going to need a lot of glitter for protest dance parties in the near future, so let’s talk about the environmental impact of glitter. On Amazon, you can buy glitter by the pound for under $20 per pound (which I’m not linking to, because no one should have that sort of power). When you buy a pound of glitter, you’re buying a pound of tiny pieces of plastic you fully intended to scatter around. Glitter is really does stick around forever.

So we need to switch to the biodegradable stuff. Luckily, biodegradable glitter comes in a variety of lovely colors, perfect for adding that something special to your next protest. No word yet on what forensic scientists think of biodegradable glitter, though.

Fireworks, Another Bright and Sparkly Option

Every American Inauguration Day has been celebrated with fireworks. The president-elect is keeping the fireworks for tomorrow’s festivities, even though he fired Charlie Brotman, who has announced every American presidential inauguration since 1957, when Brotman swore in Dwight D. Eisenhower for a second term. Brotman also was the stadium announcer for the Washington Senators, as well as announcing tee ball games on the South Lawn of the White House.

via GIPHY

A Partial List of Style Guides Everyone Should Read

Before deciding to create The Responsible Communication Style Guide, I spent years looking for a style guide that filled that niche. I didn’t find one style guide that covered topics like race and gender and health all in one place.

Instead, I found dozens of style guides, covering a huge range of topics. I compiled this list as a starting point for folks who want to explore these topics and who want to dive a little deeper.

This list is really just a starting point, though. For The Responsible Communication Style Guide, we’re going to focus on five specific facets of identity: sex, gender, race, religion, and health and well-being. Within each of those sections, we’ll suggest key words and phrases to use when discussing these topics. We’ll also have a set of essays giving broader advice about writing inclusively. Throughout this process, we’re using technology as a lens to focus our coverage.

Each section editor has lived experience with the topic they will cover, as well as experience with writing and an understanding of our intersectional approach.

And if you’re interested in helping us fund a new style guide that covers identity with an intersectional approach, check out the Kickstarter for The Responsible Communication Style Guide. (Pro tip: at the $15 level, you’ll get a digital copy of our new style guide so that you can use it in your own writing as soon as possible.

AAJA Guide to Covering Asian America

Prepared by the Asian American Journalists Association. Covers terminology for covering topics of interest to Asian Americans.

Highlight:

JAPANESE NAMES:

In Japan, typically family name first, personal name second. But in the United States, Western word order is common. Women’s names often end in -ko, or “child,” as in Michiko.

American Sociological Association Style Guide

(Link to Bookshop listing!)

Prepared by the American Sociological Association. Covers style and terminology used in the publications of the ASA.

Highlight:

Race and Ethnicity

The classification and terminology of race and ethnicity are complex and have changed over time. Avoid racial and ethnic stereotyping of groups. Authors using racial and ethnic terms should aim to be as specific and precise as possible when identifying a person’s origin or group. For example, Cuban is more specific than Hispanic; Japanese is more specific than Asian.

Apple Style Guide

(Direct link to PDF!)

Prepared for internal use at Apple. Covers brand and company-specific terminology.

connector

Use to refer only to an item that can be plugged into a receptacle (such as a slot, port, or socket). Use the following terminology: edge connector: the connector on the edge of a peripheral card; fits into a slot minicircular connector: an 8-pin connector [Don’t use mini-DIN.] plug: a connector with prongs or pins In user materials, describe connectors by their shape and size, by the icon that appears on the connector, or in another way appropriate to the context. The user should be able to identify the connector easily even if she or he doesn’t know the terminology. Chapter 2 Style and usage 38 Avoid obscure names such as power input unit in favor of more direct terms, such as plug. Don’t use male or female to describe types of connectors.

BuzzFeed Style Guide

Prepared by Emmy Favilla and Megan Paolone for BuzzFeed. Covers publication-specific terminology and style.

Highlight:

LGBT Identification:

• Unless you already know based on research, it should be standard to ask how people identify themselves: gay, bi, genderqueer, queer, trans, etc.
• A person can be trans WITHOUT also being gay or lesbian. Don’t assume.
• Use “cisgender” (rather than “non-trans”) to refer to a person who is not transgender.

The Christian Writer’s Manual of Style

(Link to Bookshop listing!)

Prepared by Robert Hudson for publication by Zondervan. Covers terminology and styles used by the Christian publishing industry.

Highlight:

you, You (deity pronoun, second person)

Lowercase the second person of the deity pronoun as you would lowercase the third person. An exception is sometimes made in books of devotion or prayer when the capitalized, second-person pronoun is used to address God directly. (For more detail, see “Deity Pronoun, The” as well as “thou, thee, thy, thine.”)

Disability Language Style Guide

Prepared by the National Center on Disability and Journalism. Covers recommended language with an emphasis on specificity.

Highlight:

Handicap/handicapped

Background: The Oxford English dictionary defines a handicap as “a condition that restricts a person’s ability to function physically, mentally or socially.”

NCDJ Recommendation: Do not describe a person as handicapped unless it is central to the story. Avoid using handicap and handicapped when describing a person. Instead, refer to the person’s specific condition. The terms are still widely used when citing laws, regulations, places or things, such as handicapped parking, although many prefer the term accessible parking.

Conforms to AP style

The Diversity Style Guide

Prepared by Rachele Kanigel, for the Center for Integration and Improvement of Journalism. Covers a variety of terminology; however, this style guide is sourced from a variety of other style guides, rather than in-house development.

Highlight:

gender-neutral pronouns

Some people don’t feel that traditional gender pronouns, such as she/her and he/him, reflect their gender identities. Transgender, genderqueer and other people who step outside the male-female gender paradigm often adopt new pronouns for themselves. If a person doesn’t identify as male or female, it’s best to ask which pronouns they prefer.

The Economist Style Guide

Prepared by The Economist for its writers. Covers publication-specific information and style.

Highlight:

Gender

Gender is nowadays used in several ways. One is common in feminist writing, where the term has a technical meaning. “One is not born a woman, one becomes one,” argued Simone de Beauvoir: in other words, one chooses one’s gender. In such a context it would be absurd to use the word sex; the term must be gender. But, in using it thus, try to explain what you mean by it. Even feminists do not agree on a definition.

Gawker.com Style Guide

Prepared by Lockhart Steele, Choire Sicha, and Gina Trapani for Gawker.com. Covers publication-specific information and grammar.

Highlight:

WORDS AND PHRASES THAT YOU MAY NEVER USE

A long list, sure, but it is topped by “interesting” and “funny” and “of interest.” If it’s funny or interesting, that’ll prove itself, and it’s actually not funny or interesting if you have to describe it as such. See also: “Arguably.” (Fuck no.) This list also includes “lede” and “hed” and other sorts of made up journo-words. Gag. Finally, do not ever suggest in your writing that you do not care about something, or are bored by it, or that you do not know about something, or that you are above it. If you don’t care, are bored, or are confused, or the like, don’t write about it. Or fake it. Nothing is more off-putting for a reader than arriving at a post pre-bored and pre-disinterested. No apologies, no regrets.

GLAAD Media Reference Guide

Prepared by GLAAD. Covers terminology for “reporting on lesbian, gay, bisexual, and transgender lives, issues, and stories.” Note, portions of this guide is sourced from the AP and New York Times style guides, rather than in-house development.

Highlight:

Coming Out

A lifelong process of self-acceptance. People forge a lesbian, gay, bisexual or transgender identity first to themselves and then they may reveal it to others. Publicly sharing one’s identity may or may not be part of coming out.

Media Takes: On Aging

(Direct link to PDF!)

Prepared by the International Longevity Center and Aging Services of California. Covers terminology for the “accurate portrayal of aging.”

Highlight:

Handicap

Not a synonym for disability; describes a condition or barrier imposed by society, the environment or by one’s own self; can be used when citing laws and situations but should not be used to describe a disability; for example, the stairs are a handicap for him

NABJ Style Guide

Prepared by members of the National Association of Black Journalists, including Jerry McCormick and Angela Dodson. Covers “terms and language usage of special interest or relevance to our membership and our community.”

Highlight:

African, African American, black

Hyphenate when using African American as an adjective. Not all black people are African Americans (if they were born outside of the United States). Let a subjects preference determine which term to used. In a story in which race is relevant and there is no stated preference for an individual or individuals, use black because it is an accurate description of race. Be as specific as possible in honoring preferences, as in Haitian American, Jamaican American or (for a non-U.S. citizen living in the United States) Jamaican living in America. Do not use race in a police description unless the report is highly detailed and gives more than just the persons skin color. In news copy, aim to use black as an adjective, not a noun. Also, when describing a group, use black people instead of just blacks. In headlines, blacks, however, is acceptable.

NIDA Media Guide

(Direct link to PDF!)

Prepared by the National Institute on Drug Abuse. Covers terminology for policy discussions, scientific discussions, and health discussions, as well as media resources.

Highlight:

Cognitive-behavioral treatments

A set of treatments that focus on modifying thinking, motivation, coping mechanisms, and/or choices made by people.

NLGJA Stylebook

Prepared by the National Lesbian and Gay Journalists Association. Provides terminology to improve “inclusive coverage of lesbian, gay, bisexual and transgender people, includes entries on words and phrases that have become common, and features greater detail for earlier entries.”

Highlight:

coming out

Short for “coming out of the closet.” Accepting and letting others know of one’s previously hidden sexual orientation or gender identity.

A Progressive’s Style Guide

(Direct link to PDF!)

Prepared by Hanna Thomas and Anna Hirsch for SumOfUs. Covers core terminology for progressive activists in order to combat discriminatory language. Note, Hanna Thomas wrote about her experiences creating the guide.

Highlight:

Disability

Most times there is no need to refer to a person’s disability, but when the need arises, choose acceptable terminology for the specific disability or use the term preferred by the individual.

Race Reporting Guide

(Direct link to PDF!)

Prepared by Race Forward, the Center for Racial Justice Innovation. Covers terminology for “reporting on specific racial and ethnic groups. Also includes terminology and practices to avoid.

Highlight:

Ethnicity

A socially constructed grouping of people based on culture, tribe, language, national heritage, and/or religion. It is often used interchangeably with race and/or national origin, but should be instead considered as an overlapping, rather than identical, category. See the section “Covering Key Issues with a Racial Lens” and the term “Racial & Ethnic Categories.”

Religion Stylebook

Prepared by Religion Newswriters Foundation. Covers “the major religions, denominations and religious organizations journalists often encounter.”

Highlight:

Bible Belt

Areas of the United States that are noted for a prevalence of strict evangelical Christian teachings, particularly in the South and Midwest. Writer H.L. Mencken coined the phrase in 1925 while reporting on the Scopes Trial in Tennessee. It can be considered offensive in some contexts so the term should be used carefully.

Style Guide for NASA History Authors and Editors

Prepared by Steve Garber for NASA History. Covers preferred language, units of measurement, and publication-specific information.

Highlight:

Manned Space Program vs. Human Space Program:

All references referring to the space program should be non-gender specific (e.g. human, piloted, un-piloted, robotic). The exception to the rule is when referring to the Manned Spacecraft Center, the predecessor to the Johnson Space Center in Houston, or any other official program name or title that included “manned” (e.g. Associate Administrator for Manned Spaceflight).

Style Guide: Reporting on Mental Health

(Direct link to PDF!)

Prepared by TEAM Up and the California Mental Health Services Authority. Covers preferred language and language to be avoided.

Highlight:

relevance

Do not assume that there is a link between an event that seems irrational and the mental health of someone in the story. Not preferred: “A man whose neighbors said he seemed depressed left his sprinklers on for days, leading to neighborhood flooding.” Preferred: “Sprinklers that appeared to have been left on for more than 80 hours led to damage in three nearby houses, water officials said.”

The Supreme Court’s Style Guide

(Link to Bookshop listing!)

Prepared by Jack Metzler with the Office of the Reporter of Decisions, Supreme Court of the United States. Covers terminology, cases, and styles used in Supreme Court decisions.

Highlight:

Repeating citations

(a) “Hereinafter” shortened form. If in the text or (more commonly) in a footnote frequent citations are to be made of a certain secondary source, it is often desirable to use a shortened form for the subsequent citations. This is generally done with a parenthetical that immediately follows the citation of the source and precedes all other parentheticals. Where a specific page is cited in the subsequent reference, do not then use “at” or “p.” Simply use the shortened form followed by the page number.

The Yahoo! Style Guide

(Link to Bookshop listing!)

Prepared by Chris Barr for Yahoo! and revised for print. Covers style for materials written for online publication.

No highlight available.

Looking for design or development style guides and pattern libraries? Start with these posts!

Put Your Damn Money Where Your Mouth Is

Diversity is important to tech, right?

We want the makeup of our company to reflect the vast range of people who use Twitter. Doing so will help us build a product to better serve people around the world. — Twitter

Intel is committed to setting the industry standard for a diverse and inclusive workplace culture. — Intel

At Facebook, we value the impact that every individual can have. We are dedicated to creating an environment where people can be their authentic selves and share their own diverse backgrounds, experiences, perspectives and ideas. — Facebook

Most of these companies have backed their words with money — funds that are earmarked for improving diversity. And they do back some good things, like events specifically meant for the demographics those companies are trying to add to their own workforces.

But the money that most tech companies have set aside for diversity isn’t going towards the infrastructure necessary to truly create a sustainably inclusive tech industry.

I’ve been an organizer with the local PyLadies group for a few years now, and we have no shortage of companies that want to buy us pizza so that they can tell our members about job opportunities. When someone talks about offering childcare at broader meetups, everyone agrees that the idea is sound, but no one wants to pay for it. The same is true for tech conferences. As co-chair of Open Source Bridge this year, I hoped to find a sponsor specifically for childcare — a simple change that would make it easier for attendees with families. The business case seems pretty obvious: no matter their gender, senior programmers routinely have families. If those programmers work remotely, are single parents, or split care with another parent, finding childcare can be difficult. Weekend conferences, in particular, can be hard because a parent might have to leave their children with someone overnight.

Providing childcare means that parents are more likely to attend conferences or other events and therefore have a better chance of interacting with a recruiter for a given company. That sort of infrastructure dramatically improves the number of people able to attend.

Adding infrastructure like childcare services to the technology industry’s norms is a prerequisite for making the industry more diverse. Recruiters have to be able to find diverse candidates if they’re going to connect them with employers. That means funding the infrastructure that gets those diverse candidates into the room.

So why is it so hard to get sponsors for things that make diverse conference attendance easier, even for relatively inexpensive additions like providing ASL interpreters?

I offered myself up as a walking billboard in our crowdfunding campaign in order to cover our childcare costs at Open Source Bridge. I asked numerous sponsors if they would be interested in being our childcare sponsor. The lack of enthusiasm compared to our standard sponsorship levels and even compared to sponsoring diversity scholarships was obvious. (Surprise: Even guaranteeing that a company get their logo on one of the most visible people at a given conference isn’t enough to get money for childcare. We managed to cover the cost of childcare, but it was a near thing.)

Apparently the name on the label is very important to sponsors: specifically labeling a sponsorship level as a diversity opportunity gets potential backers excited because they like having their names associated with the word ‘diversity.’

Don’t get me wrong. I’m all for diversity scholarships. They play an important role in making conferences more accessible. But each scholarship only helps one person. The right infrastructure will make tech events, along with the rest of the industry, more accessible to a much larger number. I may be hung up on childcare, but by offering childcare at no additional costs makes a world of difference for people who can afford a ticket to a conference but can’t afford the $100+ cost of a babysitter for a single day . For instance, think about developers whose employers will pay for their ticket and travel but won’t cover any other costs. And when you consider that multiple attendees will face that sort of expense, eliminating the cost of childcare means multiple attendees will find a conference financially accessible.

From a strict business perspective, this is ridiculous. And it’s easy enough to fix, provided tech companies truly want the diversity they keep talking about.

It’s time for tech companies to put their money where their mouths are.

In terms of conference sponsorships, that means funding real accessibility. The bullet points below are my personal wish list for conferences I run, but every conference needs different things:

  • An accessible venue
  • On-site, free childcare
  • Transcription and ASL interpretation
  • Multiple food options, including at snack times (vegan, halal, etc.)
  • Swag other than t-shirts

(Liz Abinante has a more exhaustive list here.)

There are plenty of other opportunities to develop better infrastructure in the tech industry in general, too:

  • Scholarship funds (not just individual scholarships) for code schools
  • Dry (alcohol-free) parties and other events
  • Childcare for meetups and other networking events

Dry events, in particular, would be a welcome addition. There is no doubt that the tech industry has a drinking problem. Even casual meetups often focus as much around a keg as they do around a technical talk. That excludes so many people: folks who have alcohol intolerances, folks who are pregnant, folks who need to drive home, and — perhaps the elephant in the room—folks who struggle with sobriety. An estimated one in 12 people have problems with alcohol abuse; they’re at every meetup, happy hour, conference, or other tech event we go to and have to face the choice of fitting in or taking care of themselves. And yet, many of these events don’t even have an alternative to drinking (asking for water can be difficult). We need not only alternative beverages, but alternative types of events that don’t rely on booze.

Because this sort of infrastructure doesn’t yet exist, many people are shut out of the tech industry. If you can’t go to the next networking happy hour for tech companies in your town — whether you can’t get a sitter, you can’t drink, or for some other reason — your chances of getting a job in the tech industry go way down.

A few people make it in anyhow, by paying what amounts to a tax on being more diverse than the next programmer over: finding a way to pay for whatever tools necessary to cover the cost of fitting in is the only way past those problems. In an ideal world, tech companies should give giant signing bonuses to candidates who improve their diversity numbers, if only to cover those candidates’ costs of getting into the industry in the first place.

The wage gap makes me think that sort of bonus will never happen, so pay for the infrastructure your company needs to recruit these people.

Want an easy way to start putting your money into the infrastructure the tech industry really needs? Cut a check to an organization today. Even $25 makes a difference, so if you benefit from that aforementioned wage gap, consider putting money in personally as well as through a company.

PyCon, by the Zines

I spent last week at PyCon NA (in Portland this year — how convenient!). I made a zine to hand out explaining the Python community in Portland, along with suggesting some events for out-of-towners.

Here’s a PDF you can download if you want to check it out.

Even better, I wasn’t the only zine maker at PyCon!

Jessica Garson organized a zine open space where I met a few other media makers. Jessica also gave a lightning talk about teaching with zines (her slides are here).

Roxanne Johnson presented during the poster session (Data People: Learn Python) and brought a zine she made called “Build Your Skills in Data Analysis.”

Audrey Eschright was working on The Recompiler while at PyCon and announced the next call for contributors, covering hardware.

Seriously, How is Spec Work Still a Thing?

Speculative work is a bad bet, both from the point of view of a creative and from that of an entrepreneur. Asking people to do free work (or doing that work yourself) is rarely the most effective way to move a project forward — and yet I keep seeing calls for spec work.

I would like to think most people understand that spec work isn’t an effective option, but that’s clearly not the case. The best I can do is to continue to refuse to do spec work and to try to convince you to take the same stand.

My Time is My Money

As a creative, a request to submit spec work is disheartening. Your ability to land paying work is based on your ability to win a contest. It’s like hearing that every piece of work in your portfolio is worthless: that your body of past work doesn’t actually prove you’re capable of completing a project. Personally, I find such requests irritating at best. I prefer to assume that suggestions I work on spec are attempts to get me to work for free, because I’d rather be angry than to think that a prospective client doesn’t believe I’m capable of the project in question.

Either way, though, spec work is a clear indicator that a prospective client doesn’t value my time. That worries me because my income is directly tied to the number of hours I can spend on paying work. Despite what these clients seem to think, I’m not working just to have something to do during the day — I need to earn a living. There’s a price tag on every hour in my day.

That lack of respect for my time is worse when a prospective client asks you in person or on the phone. I’ll admit to occasionally ignoring emails asking for a trial post or some examples on spec — ignoring an email is easy. But when someone asks me for a trial post during a phone call, the question trips me up: I’ve set aside time out of my day to talk to this person (time I’m not being paid for), and they want even more of that scarce resource? It gets worse when you consider the amount of unpaid work that can go into pitching a project before you can guess whether you’ll get the gig, like writing proposals and query letters.

A request for spec work in the moment forces me to keep my cool on an issue that actually makes me pretty angry, while talking to someone I hope to impress. Worse, it puts me in a position where I look like I don’t want to work on a project right off the bat. I’m willing to dig in my heels now, but there have been times in the past where I needed the work badly enough to back down.

I’ve always regretted those times, though: perhaps one spec project out of every ten has turned into paying work. And that number is only as high as it is because I’m counting those articles I wrote for publications that refused them, but that I was able to sell elsewhere. Stock article sites will take anything, it turns out, but they pay a fraction of what I would have earned if I had spent that time pitching projects that wouldn’t be done on spec.

Spec Work Means Useless Effort From Everyone

As bad as spec work is from a creative’s perspective, though, it’s a bad business practice for clients as well. It’s time-intensive and requires far more coordination than any other approach to handing out client work.

The source of this particular rant was a conversation with a prospective client, where the individual on the other end of the phone made it clear that they were talking to quite a few different bloggers at this point, implying more than ten. The phone call was being used to winnow down the numbers of respondents. That information is irritating, if only because I’m a big believer in the value of time (I categorize more than five interviews for a contract like this as “doing it wrong”). But then the interviewer said that they were asking allthe bloggers they were considering to provided a trial post.

EXCUSE ME?

I can understand asking for two or three bloggers to put together trial posts, so that you can tell the real differences between a few really good writers. I don’t agree with that approach, but I can understand it. But asking ten or more potential contractors to put together free work is ridiculous on multiple levels:

  • On a purely selfish level, asking for that much work means that you have to go through the results. Even ten short blog posts work out to a lot of reading.
  • Your network will likely suffer. You’re going to irritate people who you might want to work with in the future by asking them for free work and then turning them down for the overall project.
  • You’re taking advantage of people who you need to continue to do their best for you long after they turn in that first post. You’re not exactly starting your relationship off with your best foot forward.

Even when a creative will do spec work, a client probably won’t get the ideal end result. Most spec work projects aren’t perfect because there’s no way to get the sort of back-and-forth collaboration that ensures a client gets what they want. Writing a creative brief that addresses every nuance of a project is impossible — but so is answering project questions from a dozen different creatives. As a result, spec work is more like a sketch than a finished project, even though many people will request spec work with the expectation that they’ll get something they can use right away.

What’s the Practical Alternative?

Running a business is always a question of deciding how to most effectively spend your time. If you’re not careful, a creative project can be a crazy time suck that doesn’t get you the results you need (whether you’re doing the work or commissioning it). So, how can creatives and clients work together without wasting time?

The Client Side of the Equation: There are three factors that will tell you whether you’ll get the results you want far more effectively than asking a creative to do the work on spec.

  • Reputation
  • Communication skills
  • Past work
    Seeing a creative’s portfolio should tell you whether that creative is capable of the level and style of work you need. From there, you need to know whether that creative can do the work in a professional manner in terms of timeliness and responsiveness to criticism. You can get that information from talking to the creative’s past clients — send ten quick emails, rather than trying to go through ten speculative projects. Here, I’ll even give you a template to copy:

So and so,
Creative X has a piece of work in her portfolio that she did for your company. I’m considering hiring her for a project of my own and I was hoping to get your opinion of Creative X’s work. Could you answer a few questions for me?
How was Creative X to work with?
Did Creative X complete the project in a timely fashion?
Would you work with Creative X again?
Thanks!

You can usually find the email addresses you need on websites or LinkedIn. You don’t even need to go through the creative you’re checking up on.

The Creative Side of the Equation: Give prospective clients your portfolio. It should stand on its own. If your portfolio isn’t effective, invest the time you would otherwise spend on spec work into improving your portfolio. Given how inexpensive it is to put work up online, consider just launching some projects of your own. Write your own blog, launch your own web app, or design your own line of motivational posters. If that scares you, here are a few other options:

  • Do pro bono work for a cause you believe in.
  • Create stock work for the many marketplaces online (most have lists of types of work that are most in demand).
  • Offer yourself as an intern or apprentice (paid) to a creative already working in the industry who does a high volume of work.

Avoid Spec Work, Please

Spec work is bad for business, whether you’re a creative or a client (or both). Tempting as the idea may be, either as a way to get in with a new client or as a way to see a bunch of work from different creatives, just say ‘no.’ There are always better ways to get what you want.

A Brief Review of PyCon 2015, Based Entirely on Swag

Last week, I flew up to Montreal for PyCon. I’m now home, without any new international incidents to add to my record. It was my first PyCon, but it won’t be my last.

If Python (or open source development in general) is your thing, all of the talks from this weekend appear to already be on YouTube. Since I mostly stuck to the hallway track, I’ll be watching a lot of these videos myself and don’t feel qualified to offer a review. However, the hallway track was fantastic and I would recommend it in future years.

I can review the swag I gathered at PyCon, though. Based on t-shirts alone, I’m pretty pleased. I found not one, not two, but three ladies tees that I liked enough to take home. Considering that booths at most other tech conferences only offer men’s shirts, the availability of ladies’ tees is a good indicator of an inclusive community.

Even better, though, there was plenty of non-shirt swag. Since I’m trying to make sure my wardrobe doesn’t entirely look like it came from a trade show hall, I’m always excited to see other swag that I’m actually interested in. I’m now stocked up on small notebooks for quite awhile, including a few that have a variety of pages for sketching different types of wireframes. I’m also up a beer glass, breath mints in reusable tins, and some pretty cool fake tattoos that I’ll actually wear.

I’d like to note that I’m totally cool with the booths that didn’t offer a whole lot of swag (or any at all) — I’m just as thrilled to just talk about cool products that I didn’t know about in advance and see some demos. I don’t have to have swag, but if it’s on offer, I like to see a variety that’s appealing to all sorts of conference attendees, rather than just to stereotypes.

And, as an added bonus, next year’s PyCon is here in Portland. If you’re interested in attending, keep an eye on the PyCon website. Just a head’s up, though: my couch is already booked for PyCon 2016 and tickets are guaranteed to sell out.

Investors Always Want to Be The Coolest Kids in the Room

16651427749_19a457f155_z

Investing in an amazing startup is like buying the hot new gadget that’s just come on the market. Just being able to lay down your cash, either for an investment or a gadget is a good social signal, telling the rest of the herd that you’re cool.

But sometimes you get the iPod and sometimes you get the Microsoft Zune. (Here’s a Wikipedia link in case you don’t remember the Zune, the necessity of which may just drive home this particular point.) One tells the world that you have taste and money and one of them tells the world that, well, you bought a gadget that turned out to be not nearly as cool as something else on the market.

Venture Capital Works the Same Way

There’s not really a good way to predict precisely what investment opportunities are going to do better than others: putting your money into a company that has barely an idea of what they may offer customers, let alone any source of revenue, is risky. If it wasn’t risky, after all, we’d all be startup billionaires.

But that means that investors still have to make a decision to invest in this opportunity but to pass on that one.

Investors can weed out some of the options on the table. Details like potential audience size and the relative spending power of that audience can help an investor exclude anyone that can’t make the risk worthwhile. But there’s still far more startups looking for capital than there are investors ready to put money on the line.

That leaves gut instinct to guide an investor through choosing where to invest. Gut instinct, more often than not, takes you to the company you want to see in the world — the seriously cool offer.

The Cool Factor Minimizes Diversity

Choosing companies to invest in based mostly on what seems cool — on what will signal to your friends that you are awesome — limits investments dramatically. What’s cool right now? Well, that depends on your friends. If your friends each have their own bucket load of money and they all live in San Francisco, though, they’re going to define ‘cool’ very specifically. Buying things online is cool, hence all the Bitcoin startups. Being able to pay someone else to deal with the sucky parts of life is cool, hence the appeal of getting things done by Magic. Wine, beer, and whiskey are all cool, hence more startups around those beverages than non-alcoholic drinks.

What’s not cool? How many apps have you seen get funding for simplfying divorces? What about effective logistics management? What about anything for the unexotic underclass?

The lack of diversity isn’t just a question of picking startups with ideas that seem cool to the right people, either. What people are most likely to have ideas that you think are cool? People who are very similar to you across a spectrum of characteristics.

Is There a Solution?

The venture capital system is based, ultimately, on gut instinct. There’s no real way to predict that one startup will succeed or another will fail, which means that investors have to decide based on whatever criteria they choose. Coolness is no better and no worse than any other decision-making tool, especially when someone is deciding how to invest their own money.

Want to see a dramatic uptick in diversity among venture-backed startups? Get investors with a much wider collective definition of cool — more women, more people of color, more parents, more military veterans, and so on. Of coures, there’s a chicken and an egg problem that people who do not already match investors’ ideas of good founders are less likely to have money to invest. That’s a harder problem, though I can see some options (though all come with their own particular problems):

  • Figure out a way to encourage more people to bundle small investments together into startups
  • Add more diverse decision makers at investment firms
  • Use governments and non-profits to come up with investment capital

A more practical option may be to look for more opportunities to opt out of the venture capital system in general. There are plenty of arguments for other strategies: venture capital is likely creating another bubble, it’s creating businesses focused only on exits, and it’s definitely driving price wars.

Bootstrapping, or taking only a small round of investment from friends and family, is the fastest route away from venture capital. It won’t work for all companies — anything needing a big upfront investment in research or equipment is out — but bootstrapping is always worth considering. And the number of ideas that can be bootstrapped today is surprising; 3D printers, marketplaces offering time on expensive equipment, and amazingly cheap software tools have brought down the cost of building anything.

Image by Flickr user Got Credit

A New Use for Hemingway: Ghostwriting

I’ve been finding Hemingway surprisingly useful when working on ghost-writing projects lately. It’s a useful sort of a writing hack to get some quick insights when you’re trying to mimic someone else’s writing style.

Of course, Hemingway is fundamentally intended to help writers sound more like the man himself. But it does that by highlighting certain characteristics of writing:

  • passive voice
  • adverbs
  • vocabulary

By putting in writing samples from a client who I need to mimic, I can see pretty quickly how they use words. I can do that sort of analysis by hand, but it’s tedious enough that I don’t actually do so except on really well paying projects.

If you’re trying to mimic the style of someone’s writing, I suggest looking at several examples of someone’s writing through Hemingway’s lens, not just one. Getting the style right on a ghost writing project is hard enough when you’ve got multiple samples — getting style right off of just one sample is impossible.

Putting in several samples can be time-consuming, though. I do wish Hemingway had an API so that I could integrate it with some of my other writing tools, as well as automate the process of putting writing samples into the app. But I don’t absolutely need an API to keep finding new ways to use Hemingway — it’s just something that would be nice to have.

Community-Run Conferences: The Most Bang for Your Conference Buck

Unconference Scheduling

I recently had the pleasure of attending Open Source Bridge and noticed several factors that made it an incredibly useful and enjoyable conference to attend. Open Source Bridge is an annual conference that takes place in Portland, Oregon (just like OSCON). It covers a variety of topics related to open source software, also similarly to OSCON. But while a full-access pass to OSCON runs about $2,000, a ticket to Open Source Bridge is $300. I love community-run conferences!

Full disclosure, I received a press pass for Open Source Bridge. (I’ve also received free passes in the past to other conferences I might reference in this post through volunteering, sponsorships, or client relationships.)

Community-run conferences are a much better opportunity for many people than many other types of events. Don’t get me wrong; there’s plenty of value to be had at mega-conferences and other types of events, as well. But considering the lower prices associated with community-run conferences, I always come away feeling like I’ve gotten so much for my money. Here’s why.

Community-Run Conferences Have More Room for Dissenting Opinions

The voices you hear at big conferences are often those speakers who are well-established authorities within their specialties. Obviously, big events need speakers who the widest possible audience will recognize in order to sell tickets. But when you have the ‘official’ opinion up on the stage, it’s harder for a speaker with a dissenting opinion to get on the schedule. The decision may be as simple as "We’re covering that topic already, so why should we have a second speaker discussing the same material?"

But that process does mean that different points of view are automatically excluded. The same doesn’t hold true at a community-run conference. Because a community-run conference almost always looks to the community first to choose speakers, there are more opportunities for diverse opinions:

  • Community-run conferences are generally more welcoming to newer speakers, including those with very different perspectives from the status quo.
  • Community-run conferences don’t have to toe the sort of party lines that a company-run conference must. This might explain why all the major hacker conferences are actually community-run events. Even big sponsors only have a limited impact on what can be said at a community-run conference.
  • Community-run conferences can afford to take risks on niche topics that may only appeal to ten or twenty people out of the entire set of attendees. Big conferences have to fill rooms to make economic sense.
  • Attendees at community-run conferences are more likely to pay for their own tickets out of pocket, so they don’t have to justify a particular event to a manager who controls the company budget for conferences. In turn, that means that community-run conferences can afford to offer more sessions on non-business topics.

The sort of variety that a community-run conference offers is more fun (at least for me). I’m far more likely to wind up at a session covering something I know very little about but that will dramatically change the way I see a particular issue. One of the first sessions I attended at Open Source Bridge, for instance, was on OpenMRS — an open source software project I was entirely unfamiliar with — which offers open source medical record management software. I chose the talk because I’m interested technology and health, but I learned a great deal about the problems international open source projects face, how a project can create software that’s usable in places with limited power and internet access, and even the unexpected localization issues that a hospital in Somalia might have as opposed to a hospital in Kenya. Perhaps more importantly, I got a very different perspective on open source technology as a whole that I can already tell will influence my own work.

Community-Run Conferences Have More Opportunity for New Connections

The argument that smaller conferences are easier to meet people at than their larger counterparts seems counter-intuitive. But large conferences are overwhelming even for the most outgoing people. We’re more likely to find a few people to hang out with at a time, to provide a buffer against the thousands of attendees at a conference like OSCON. It’s a paralysis caused by too many people. Personally, at particularly large conferences, I tend to find a "conference buddy" who I cling to to make sure I don’t get washed away in the sea of humanity.

At smaller conferences, however, I’m more likely to go around and introduce myself. I noticed at Open Source Bridge that I knew a large number of attendees and, as a result, I felt very comfortable and was better able to introduce myself to new people. After all, if I were to encounter a problem, I could always retreat to talk with people who I already knew.

Those connections occur outside of the actual length of the conference, as well. Conference organizers have varying levels of passion for the events they create. On the less passionate end of the spectrum, those individuals who are paid to organize particular conferences probably care about the events they manage, but not to the point where they’re talking about their next conference constantly. In contrast, someone organizing a conference out of sheer passion is going to tell everyone they know about the next event. Even the problems will be more visible, because that organizer’s friends will get to hear every last detail about the argument with the venue staff (whether anyone wants to or not).

The community is more long-lived as a result. Rather than moving on to the next conference at their employer, the organizer of a community-run conference’s next event is likely to be either next year’s conference or a closely related event. The organizers can pull the community along, maintaining excitement throughout the year between conferences.

Community-Run Conferences Have More Room to Experiment with New Improvements

A code of conduct seems like such a simple thing. And, yet, many large conferences of every type seem to struggle with implementing such codes.

Of course, there are community-run conferences without codes of conduct still. But many are more open to the idea of adding on a code of conduct — and seem more willing to adopting an existing, proven code without feeling that they need to develop a new code entirely from scratch. Those communities who aren’t willing to add such codes, well, that information can be valuable, too.

Because a community-run conference has the ability to quickly evolve from event to event, such conferences have more opportunities to experiment with better practices. As a for instance, when attendees registered for this year’s Open Source Bridge, they each had the opportunity to choose between three colors of badge lanyards: blue, yellow, and red.

  • A red lanyard indicates that the wearer does not want their photo taken at all.
  • A yellow lanyard indicates that would-be photographers need to ask before taking the wearer’s photo.
  • A blue lanyard indicates that the wearer is comfortable with having their photograph taken at the conference.

It’s a simple visual cue that can make a world of difference in making a wider variety of attendees comfortable with a particular event. There are a whole host of reasons that people may not wish to be photographed even if they’re at a public event. The default for most events is that everyone who happens to be carrying a camera (which you can read as all of us) can take photos and even recordings of anyone who happens to be at the event. I’m not entirely sure how this became the norm, but it’s not actually a reasonable approach. Event organizers may ask for a bulk permission to photograph or otherwise record attendees, but other attendees don’t usually take any steps to make sure that their photography subjects are comfortable with the situation.

This year’s lanyards aren’t Open Source Bridge’s first experiment in providing visual cues about appropriate behavior. Last year, the conference offered stickers for people to place on their name badges to express photography preferences

I can’t categorically state that lanyards are the best way to communicate these sorts of preferences; the only way to figure out such factors is to run an experiment or two. Community-run events seem more willing to do so, if only because the logistics of testing a new approach with a few hundred attendees is far easier than with a few thousand. Even better, most community-run events are put together by passionate people — and passion is rarely exclusive. If you are willing to do the hard work to bring information about your topic of choice to a wider audience, perhaps you’re also more willing to figure out the mechanics of running inclusive events.

Support Your Local Community-Run Conferences

I’ve always been lucky to be parts of communities where community-run conferences happen regularly. I grew up going to conventions for various bits of science fiction and fantasy fandoms. I used my student status in college to get cheap passes to all sorts of conferences (including a ton of writing events). When I started learning more about technology (especially programming), I went to BarCamps and other unconferences, as well as other small community-run conferences of a more traditional nature.

I’m happy to pay money for these sorts of conferences, but it’s also important to support them in other ways. Even small conferences take a ton of work, especially when they’re first starting up. Helping on even basic tasks like setting up chairs in a conference space is good. Open Source Bridge ran smoothly because around 70 volunteers put in their time. Some of those volunteers worked for months to handle every detail of the conference; some put in a few hours of work in exchange for a free ticket. Either way, they made the conference possible.

Especially if you come from a community that doesn’t have a strong tradition of organizing its own conferences, consider what you can do to volunteer. You never know — you might wind up organizing one of those community-run conferences yourself.

Image by Flickr user Reid Beels