When we released Django, we took our structure from the Python community, appointing Adrian Holovaty and me as "Benevolent Dictators for Life". Turns out, "... for life" is a pretty long time — who knew — and this role turned out not to be sustainable.
About a year and a half ago we resigned, and Django transitioned to a completely community-run project.
This is a story about this journey: how I became a BDFL, what worked and didn't about that, how I burnt out and "retired" — and what I've been doing in open source since.
In 2005 Jacob Kaplan-Moss joined the "Lawrence Journal-World", a locally owned newspaper in Lawrence, KS, and helped develop and eventually open source Django. He later founded the Django Software Foundation and served as its president for several terms. Today, Jacob is the director of security at Heroku.
Now that your event or project has a code of conduct, how do you ensure it's effective? Are you prepared to deal with incident reporting and to resolve issues that come up? How can you tell if your code of conduct is actually working?
I'll draw on several years of experience working with code of conduct outreach and enforcement on open source projects, user groups, and a major conference to show you the steps to take to make sure your code of conduct is an effective tool for inclusion, safety, and building a stronger community.
We'll talk about reporting processes, documentation, creating a team or committee to handle reports, what responses are or aren't effective, and dealing with problems in the heat of the moment.
Identifying and discouraging negative self-talk is a simple thing, but it can have a huge impact on your community in a positive way. It increases self-confidence, improves morale, and generally results in happier, more productive community participants. This, in turn, will make you happy.
Negative self-talk is a pervasive, invasive, and unproductive way of thinking. It can trigger a cascade of things, from abandoned patches (“I am not smart/talented/good enough to figure this out”), to withdrawl from the community (“I screwed this up and everyone knows and hates me”), to general discouragement (“I suck, and have nothing valuable to contribute here”).
In this talk, I’ll discuss the various methods Dreamwidth and other organizations use to handle negative self-talk, and the best way to deploy those techniques. I will also discuss things to keep an eye out for in your community that may be at the root of this type of self-talk, and processes you can go through to eliminate them. Finally, there will be a quick overview of impostor syndrome, and the role it plays here.
I've heard it before from people in positions of privilege - "If you don't feel represented, then why don't you create something of your own?" After more than two-and-a-half years working in the tech industry, I always felt that living on the intersection of race and gender were seldom addressed in tech initiatives, and in work spaces I seldom encountered other professional women of color outside of the service staff.
In an effort to get over the feelings of isolation, a friend and I created a Twitter chat using the then-underused #WOCinTech hashtag in an effort to bridge the geographic and workplace barriers and connect with women of color already in the tech industry and connect with each other.
The chat has since grown to become a full-fledged community made up of women of color and nonbinary POC technologists, and our two-person team has responded to the needs of this community by creating initiatives that target these groups specifically.
In my talk, I'll discuss my experiences living at the intersection of race and gender, the #WOCinTech chat origin story, how connecting with women of color has empowered me professionally, and how the community wants to help others on their path to a career in tech.
Too often we get caught up in our own biases, even the most compassionate of us. When we do, we lose sight of how to design and build platforms and experiences that work for all our users. We end up building for ourselves, the person who knows the system inside and out, the power user. And while people like us are important, they rarely make up the majority of users.
We need to build things that anyone can learn quickly, use efficiently, making the user feel confident and powerful. Through examples of atypical users, I’ll walk through things to consider when designing tools and applications that empower the greatest number of users to achieve more.
You've heard empathy is a learned skill. Let's really talk about it. What does it mean to have empathy? Why does it matter, anyway? And if empathy is useful (I hope to show you how it is), how do you get better at it?
In this session, you'll learn real stuff about what's in your own heart, and how to connect to the people you encounter. Less feeling shitty, more enjoying projects!
Many tech projects are anglocentric. The de facto language used to develop and document a project is English, and it is often overlooked that a project is used largely by non-English speaking communities.
We programmers like to think "code is the universal language," but getting to speak code still involves overcoming language barriers. Even after you speak code, your experience working on project involves a lot of cultural references and language use specific to English. So let's pause for a moment talking about the newest features and technical specs, look at the experience of a silent majority, and talk about how we can welcome them to your project today!
On International Workers' Day I asked the world to #talkpay, and many people did. Pay transparency is critical in order to address pay inequity in our field, as well as others, but there's more to it than that. I'd like to discuss why this taboo surrounding pay got started, illustrate just how concerted of an effort there is to prevent workers (including tech workers) from pushing for higher pay, and why, exactly, we NEED to talk about pay.
Most great epics tell of how against all odds, our heroine champions over incredible hurdles to accomplish their dream and create a massively successful project. I'm here to tell you that the story isn't over after the happily ever after. Instead, the hard work is just beginning.
True legends don't form from one successful deploy, or one successful workshop run. Success is dictated by longevity and key points of interest.
Now that you've figured out and climbed your mountain, how are you going to keep your project alive? How can you ensure stability?
In 2013, I set out with a very manageable goal of running a RailsBridge workshop in New York City. The second part of my goal was to create a self-sustaining organization that would continue to run workshops to teach the underrepresented minorities in tech while keeping the values set by the RailsBridge founders Sarah Mei and Sarah Allen.
It's easy to run workshops, it's a lot harder to develop a healthy culture within a volunteer organization.
In this talk I will highlight key points from my two years as a RailsBridge chapter founder and go through the challenges I faced through strategies in real-time communication, documentation, and code curriculum sharing through technology.
In games, a valuable team is made up of characters with varied talents and skills. They need to be adaptable, to communicate, and most of all, to work together. As a team, they can accomplish even the most intimidating quests. It's time we took this mentality to the open source community.
Roleplaying games can teach us a lot about diversity and working as a team if we dig a little deeper. In such games, players take on the role of a fantasy character and participate in quests and adventures with a group of other players. During this talk, I will take popular fantasy classes and relate them to the variety of people who contribute to open source communities every day.
Just like a roleplaying party would fail with only type of character, open source needs the unsung heroes: the technical writers, the artists, the testers—to make the project a reality. By building our 'party' around diverse interests and welcoming newcomers with open arms, open source communities can prosper.
In the tech industry, and especially in the open source community, there are many frustrations and problems that everyone experiences. It is no secret, however, that these problems are not evenly distributed. Those who tend to be underrepresented in the industry find their feelings of marginalization compounded by behavior that has come to be viewed as the norm.
And while it is also no secret that speaking out about these issues can in itself be a problem, it is not as simple as it seems. Will standing up to injustice harm your career? Are harassment and *-ism just something you should expect? Is there a certain initiation/hazing period that you have to simply suffer through before you can be taken seriously? Do certain marginalized subgroups have it worse than others, and what does that mean for those who don't have it the worst? In this talk, we'll take a deep dive into the many not-often-discussed nuances of a widely known problem.
Managing open source projects exposes a maintainer to the vagaries of the internet. For all the joy and convenience that a bit of technology may bring to its users, users typically show up when they are in an unhappy place, and the job of the maintainer can quickly become an overwhelming source of stress and burnout.
This talk will introduce Non-Violent Communication as a toolkit for helping users at their worst, and also prevent the flood of bad vibes from becoming a source of toxicity. By exposing our vulnerability in a direct and honest way, we can turn conversations away from blame and antagonism, towards meaningful connection and opportunities for growth and collaboration. Open source is a social machine, and compassion helps keep the gears from grinding to a halt.
We interact with people in chat rooms, issue trackers, pull requests, discussion boards, meetups, hallways, or conferences.
How do we provide feedback constructively? Are we perceived as friendly as we think we are? How exactly do our cognitive biases unconsciously affect our human interactions? How do we become conscious of them? What assumptions does our language carry?
Effective communication is critical particularly for project leaders. As leaders, we open the doors to our gardens, and the first interactions define the tone for the group, shaping today's atmosphere as much as tomorrow's. In this talk, we'll explore how to communicate effectively. Always, and with everyone.
This talk will cover my view of documentation within programming culture as it has grown over the years. As a primary person involved with Read the Docs (the largest open source doc hosting website) and Write the Docs (the largest OSS doc conference), I have seen a lot of angles, and appreciate documentation more every year.
I believe better documentation is a fundamental aspect of how we can improve programming culture, and an often misunderstood part of outreach and education. Projects with good documentation are able to get contributors in a much more reliable fashion, and, more importantly, projects without documentation only attract users who have time to waste.
This talk will make you think more deeply about the social impact of documentation, and hopefully make you question if it should be a higher priority in your development. You should understand the role of documentation in both technical as well as social realms.
"911, what is your emergency?" is the question that starts every call. My job, for three years, was to negotiate the caller's emotional minefield to gain life-saving information and insight.
In this story-centric talk, I show how working in software and with open source communities is similar to emergency services.
Participants will hear stories that reveal human nature and understand some of the system and training that creates order from emotional chaos. UX designers and software developers can use these same techniques to uncover their users' needs, manage volunteers, communicate effectively, and prioritize development.
Bryan Liles works on strategic initiatives for DigitalOcean. In layperson's terms, this means he writes open source software for DigitalOcean and others. He helps communities move their software to the public cloud, and gets to speak at conferences on topics ranging from machine learning to building the next generation of developers. When not thinking about code, Bryan races cars in straight lines and around turns, and builds robots and devices.
It's generally considered a good thing when companies open source their software. They're giving back to the community and being good citizens. Unfortunately it's not always the case that companies are good actors in our community. Sometimes they are bad actors, with practices including deceptive promises of open participation and exploiting free labor in the form of community contributions.
This talk explores patterns in company-sponsored open source projects, actions which influence the acceptability of those projects by the open source community, and opportunities for companies to participate wholeheartedly in the open source community. Let's talk about the patterns demonstrated by good corporate open source citizens.
For the past year in Chicago, I’ve been teaching beginning coding workshops for mothers and daughters. I began the series inspired by my own experiences teaching my daughter HTML, and, most importantly, as a single mother navigating a tech career, who knows firsthand that most tech communities are not designed with the needs of people like me in mind. And, yet, we’re out there, willing, capable and ready, trying to find our ways in anyway.
If we truly want to improve the diversity of our tech communities, we need to talk about how childcare responsibilities disproportionately affect the marginalized, and how to have more empathy for those with those responsibilities. Let’s talk about how to create successfully family-inclusive events, how to care for the carers, and how we can all work together to build a strong, open pathway for the next generation.