The Unbearable Vulnerability of Open Source
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 69 | |
| Autor | ||
| Lizenz | CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben. | |
| Identifikatoren | 10.5446/37805 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
Ruby Conference 201712 / 69
2
5
8
11
13
19
20
21
32
33
34
35
37
40
43
44
52
54
55
56
57
58
62
64
65
67
00:00
Offene MengeComputervirusSystemprogrammierungSpeicherabzugProgrammbibliothekSystemtechnikMereologieSpeicherabzugVersionsverwaltungProgrammfehlerKartesische KoordinatenInteraktives FernsehenTwitter <Softwareplattform>BildschirmmaskePhysikalisches SystemXMLUMLComputeranimation
01:21
SoftwareBitMereologieOpen SourceMultiplikationsoperatorSoftwareschwachstelleMobiles InternetOffene MengeComputeranimation
02:23
PunktwolkeKontrollstrukturCliquenweiteMinkowski-MetrikBefehl <Informatik>DatenbankDatensatzProfil <Aerodynamik>Projektive EbeneSpeicherabzugProgrammfehlerWeb-SeiteKartesische KoordinatenFramework <Informatik>MinimumElektronische PublikationMultiplikationsoperatorZweiMinkowski-MetrikSystemaufrufProzess <Informatik>SoundverarbeitungMixed RealityAtomarität <Informatik>Computeranimation
03:57
Repository <Informatik>Wort <Informatik>MultiplikationsoperatorBesprechung/Interview
04:27
Projektive EbeneMultiplikationsoperatorSoftwareschwachstelleBesprechung/Interview
05:00
SoftwaretestDesintegration <Mathematik>Physikalisches SystemVakuumMUDLokales MinimumBenutzeroberflächeCodeSoftwaretestEntscheidungstheoriePhysikalisches SystemProjektive EbeneHypermediaProgrammfehlerOpen SourceNP-hartes ProblemMultiplikationsoperatorComputeranimation
06:06
CodeComputerspielProjektive EbeneEreignishorizontOpen SourceMultiplikationsoperatorSoftwareschwachstelleEinsMAPComputeranimation
07:37
CodeComputersicherheitOpen SourceSoftwareschwachstelleDokumentenserverPeer-to-Peer-NetzComputeranimation
08:09
VersionsverwaltungVorzeichen <Mathematik>CodeProgrammbibliothekAggregatzustandProgrammfehlerOpen SourceEinsProjektive EbeneFormation <Mathematik>VerkehrsinformationComputeranimation
08:41
DefaultMomentenproblemProjektive EbeneProzess <Informatik>Open SourceComputeranimation
09:41
MathematikRückkopplungTelekommunikationProgrammierumgebungProjektive EbeneSoftwarewartungCASE <Informatik>EnergiedichteOpen SourceMultiplikationsoperatorSoftwareschwachstelleMobiles EndgerätTeilmengeComputeranimation
11:35
CodeTelekommunikationCodeTelekommunikationKette <Mathematik>Kontextbezogenes SystemPunktArithmetisches MittelSoftwarewartungFormation <Mathematik>Wort <Informatik>Disjunktion <Logik>Patch <Software>Computeranimation
12:50
Dynamisches SystemLeistung <Physik>Projektive EbeneSoftwarewartungEnergiedichteUmsetzung <Informatik>MultiplikationsoperatorFreewareProdukt <Mathematik>Arithmetisches MittelComputeranimation
13:38
DatenbankProdukt <Mathematik>Exogene VariableBenutzerschnittstellenverwaltungssystemMultiplikationsoperatorOrdnungsreduktionBitrateGamecontrollerComputeranimation
14:08
SoftwarewartungOpen SourceEinfache GenauigkeitMultiplikationsoperatorSoftwareschwachstelleEndliche ModelltheorieComputeranimation
14:47
Open SourceSoftwarewartungOpen SourceProdukt <Mathematik>Ideal <Mathematik>Projektive EbeneProzess <Informatik>MultiplikationsoperatorComputerspielDatenstrukturInzidenzalgebraVektorpotenzialComputeranimation
16:25
Open SourceSoftwareProdukt <Mathematik>ResultanteSoftwarewartungElektronische PublikationOpen SourceBitReibungswärmeVollständiger VerbandComputeranimation
17:36
CodeSelbst organisierendes SystemSpeicherabzugProgrammfehlerRechter WinkelComputeranimation
18:19
Codierung <Programmierung>CodeEntscheidungstheorieDruckspannungBildschirmmaskeGruppenoperationSoftwarewartungHilfesystemElektronischer ProgrammführerTwitter <Softwareplattform>E-MailPunktChatten <Kommunikation>Computeranimation
19:02
Elektronischer ProgrammführerComputersicherheitInklusion <Mathematik>TemplateCodeInformationInhalt <Mathematik>Lokales MinimumPASS <Programm>AnalysisSoftwarewartungProjektive EbeneOpen SourceCodeMathematikRoboterSpieltheorieTypentheorieTeilmengeProgrammfehlerKartesische KoordinatenInklusion <Mathematik>SkriptspracheVerkehrsinformationElektronische PublikationMultiplikationsoperatorSchlussregelDokumentenserverProdukt <Mathematik>MereologieSchnittmengeComputeranimation
21:17
MathematikSoftwarewartungPunktHilfesystemMultiplikationsoperatorProjektive EbeneCASE <Informatik>Prozess <Informatik>BestimmtheitsmaßComputeranimation
22:12
Repository <Informatik>DokumentenserverDatenstrukturZeichenketteSchlüsselverwaltungMathematikProjektive EbeneFlächeninhaltHilfesystemDruckspannungSoftwareschwachstelleProfil <Aerodynamik>Einfacher RingComputeranimation
22:57
CodeProjektive EbeneSoftwarewartungBildverstehenGemeinsamer SpeicherHilfesystemWeg <Topologie>MultiplikationsoperatorEntscheidungstheorieVersionsverwaltungSummierbarkeitComputeranimation
23:34
Projektive EbeneSoftwarewartungGüte der AnpassungUmsetzung <Informatik>MultiplikationsoperatorInklusion <Mathematik>Computeranimation
24:32
TelekommunikationProjektive EbeneFlächeninhaltSoftwarewartungUmsetzung <Informatik>MultiplikationsoperatorComputerspielArithmetisches MittelOpen SourceComputeranimation
25:31
CodeSpeicherabzugOffene MengeProgrammierumgebungCodeWärmeleitfähigkeitCodierungGruppenoperationProjektive EbeneSoftwarewartungTopologieComputeranimation
26:05
SoftwarewartungProfil <Aerodynamik>Projektive EbeneHilfesystemMultiplikationsoperatorComputeranimation
26:47
UnendlichkeitRechenwerkSteuerwerkPROMProzessautomationCodeProfil <Aerodynamik>Projektive EbeneVerschlingungTemplateWeb-SeiteOpen SourceStandardabweichungDokumentenserverWärmeleitfähigkeitDeskriptive StatistikGebäude <Mathematik>Computeranimation
27:29
MereologieProjektive EbeneSoftwarewartungHilfesystemElektronische PublikationOpen SourceMultiplikationsoperatorMathematische LogikProfil <Aerodynamik>SoftwareschwachstelleComputeranimation
28:27
BetragsflächeGruppenoperationSoftwaretestRechenwerkKreisbewegungKlon <Mathematik>MathematikErwartungswertProjektive EbeneOpen SourceHinterlegungsverfahren <Kryptologie>DokumentenserverProdukt <Mathematik>Computeranimation
29:14
TelekommunikationProjektive EbeneSoftwarewartungOffene MengeTopologieRoutingWort <Informatik>VerkehrsinformationOpen SourceMultiplikationsoperatorComputeranimation
30:09
Projektive EbeneOpen SourceOrdnung <Mathematik>MereologieSoftwarewartungBildverstehenProgrammfehlerKartesische KoordinatenMultiplikationsoperatorTopologieProdukt <Mathematik>TeilmengeKontextbezogenes SystemMessage-PassingComputeranimation
31:42
CodeProgrammfehlerProjektive EbeneSoftwarewartungProzess <Informatik>HilfesystemOpen SourceCodeGebäude <Mathematik>COMProgrammfehlerElektronischer ProgrammführerMultiplikationsoperatorComputeranimation
32:18
CodeGebäude <Mathematik>Projektive EbeneSoftwarewartungExogene VariableGemeinsamer SpeicherHilfesystemOpen SourceMultiplikationsoperatorSoftwareschwachstelleOffene MengeInteraktives FernsehenComputeranimation
33:31
SystemprogrammierungProjektive EbeneOpen SourceSoftwareschwachstelleLie-GruppeSoftwarewartungExogene VariableProzess <Informatik>MultiplikationsoperatorDemoszene <Programmierung>Besprechung/InterviewComputeranimation
35:07
CodeSoftwareSpeicherabzugSoftwarewartungGüte der AnpassungProzess <Informatik>ProgrammfehlerOffene MengeSkriptspracheWeb logMultiplikationsoperatorSoftwaretestGeschlecht <Mathematik>Gleitendes MittelSoundverarbeitungFigurierte ZahlVorlesung/Konferenz
38:15
COMXML
Transkript: Englisch(automatisch erzeugt)
00:13
and you should tell. I live in upstate New York, about two hours north of the city, in a city that was the first capital
00:22
of New York, until Sam Phippen and the British burned it down, like twice. You can find me anywhere online at the handle AileenCodes. That means like Twitter, Instagram, email, GitHub, anywhere that I actually want you to find me.
00:44
I'm a senior systems engineer on GitHub's Platform Systems team. Platform Systems is the team that's responsible for Rails and Ruby and other libraries and how those interact with the GitHub application. I'm also the newest member of the Rails core team, which means that I'm allowed to tweet
01:01
from the Rails Twitter account. Woo! Which is the only important part of being a Rails core team member. But for those of you who don't know, we're also responsible for defining the future of Rails, releasing versions and fixing the bugs for all of you. Sometimes.
01:22
Today we're going to talk about the unbearable vulnerability of contributing to open source. Before we deep dive into that, I want to give you a bit of background on my involvement in open source and what I mean by vulnerability. When I talk about vulnerability and open source, I'm specifically referring to contributing to open source
01:42
and how that exposes our insecurities and makes us feel like we're not good enough to contribute. The vulnerability that we feel when contributing can inspire us to change the software we use and the communities we belong to, or it can be so unbearable that it's paralyzing because our vulnerability makes us afraid of contributing.
02:05
I've been contributing to open source for a long time and I still feel vulnerable, especially when I contribute to a new project or build a major feature. Vulnerability is an inherent part of contributing to open source and I don't think that's something
02:21
that I'm ever going to get over. I opened my very first pull request on GitHub in 2012. It was a pull request to fix a typo in a readme of a project that I had been using. The PR was never merged because the project had been abandoned for a few years. Almost a full year later,
02:41
I opened my second pull request. Mini-profiler is a database and request profiler for Rails applications. I noticed while using mini-profiler that there was this little extra space at the bottom of the page that was super annoying and I thought, oh, this is a CSS bug. So easy to fix. I quickly found out it was not CSS
03:01
and it took me two days to find the invisible UTF-16 character that was hiding in like it was a JavaScript file or a CSS file or something. It was so bizarre. And even though I had spent lots of time looking at that issue and I was confident that I had fixed the bug, I was still worried that I was wrong or that my contribution wouldn't be welcome.
03:22
I felt vulnerable because I didn't know what to expect. After giving a talk in 2014 at Mountain West Ruby, I learned that I had found a bug in active record. Aaron Patterson, who most of you know is a Rails and Ruby core team member or just as tender love,
03:41
asked if I wanted to pair with him to implement a fix for the problem. Shortly after pairing on that fix, I opened my first pull request for the Ruby on Rails framework. Even though I had worked with Aaron and knew that I had the right fix, I was still really nervous about opening a PR
04:01
against a repo where 2,000 people get notifications every time you open an issue or pull request. I felt vulnerable because I was a new contributor. What if somebody thought my fix was stupid? What if somebody thought I was stupid? These thoughts might seem irrational, but they are embedded in contributing to open source because we're dealing with people, not code.
04:24
The other side of that fear though is the high you get when your pull request is merged. I continued to contribute to Rails regularly after that first pull request. Maybe it was because I had someone mentor me
04:41
and help me understand the Rails internals. Maybe it was because I had such a good experience contributing that first time. One of the goals of this talk is to provide ways in which you can improve your community so more contributors experience that high instead of the unbearable vulnerability when contributing to your project.
05:01
This past year, I worked on a large feature for Rails called system tests. Previously, a lot of my work on Rails had been refactoring code, fixing bugs, or improving performance, all that stuff that no one actually cares about. This was my first experience adding a major feature to Rails, and by major, I mean it was literally
05:20
the highlight of the Rails 5.1 release. Working on this project reminded me how hard contributing to open source can be. I had been contributing to Rails for over two years, but I was nervous opening this pull request. I had those familiar thoughts. What if everyone hates this feature? What if someone thinks my code is bad?
05:42
Even though DHH, the creator of Rails, literally asked me to build this feature, I still had to deal with the reviews and the comments and defend my decisions that I made. When I opened the pull request, I had already put three months of work into it. The project was personal to me because I had spent nights and weekends working on it,
06:01
and I became attached to the code. In the time the pull request was open, I received over 150 comments and 11 reviews. That's a lot of other opinions to deal with. I felt stressed and vulnerable, just like I had when I opened my first pull requests. Someone even tweeted about the PR, which only drew more attention to it.
06:22
Don't get me wrong, attention is good and reviews are good, but I was drained by the endless bike shedding and nitpicking of details. None of the reviewers meant any harm. They were really excited about the feature. Still, a level of discomfort gnawed at me. I had been an avid contributor of Rails for two years and released Rails 5, and I had commit rights,
06:43
so why was opening this PR a nail-biting, stress-inducing event in my life? I figured I'd be over the unbearable vulnerability by now. While thinking about that, something hit me. I realized that even if we get used to working on open source, we can still experience vulnerability
07:01
when we work on a new project or a large feature. The more time we spend on open source, especially free time, the more attached we become to the work that we're doing. And there's only one explanation for why this happens. If contributing to open source was only about writing code,
07:20
it would be easy. Well, we all know contributing to open source isn't easy. We're not just dealing with code or ones and zeros. No one would be worried about opening a pull request if open source was about writing code. So if open source isn't about writing code, that means that open source is really about people, and it's the people who make us feel vulnerable.
07:43
Contributing to open source is about our insecurities, our fear of being wrong, and our fear of showing our peers our work. Often just the thought of pushing code to a public repository can cause anxiety for me. Given that, while people are the source
08:00
of our vulnerability, they are essential to the open source ecosystem. Let's take a minute to think about what open source would be like without people. Say you write a gem or a library in open source state. Sure, it's public for anyone to use, but if no one downloads it, is it really an open source project?
08:20
Open source doesn't work without users. Otherwise, you're not really sharing your code with anyone. No users means no bug reports, which means your work doesn't improve. And if you stop improving it yourself, no one's gonna notice because they don't use it. While your code might be public, it's just public code until someone uses it.
08:43
Let's say you have tons of users but no contributors. Sure, you get to control the project and you never have to deal with other ideologies, but is that really open source? If you stop improving the project or move on to something else, the project won't really be useful anymore. Open source can't survive without contributors.
09:02
Imagine a moment for a world where Matz created Ruby but had no contributors. Would it be as robust as it is today? Definitely not. Would all the engineers who learned Ruby and got jobs not writing Java be as happy as they are today? I don't know. Maybe everyone would have adopted PHP instead,
09:23
but the community and tools would be very different from where they are today if we had done that. I wouldn't be here today giving this talk if it wasn't for Ruby, Rails, and its success, and all of those contributors contributing to that success.
09:40
So I've convinced you that you need people as users and contributors to have a successful open source project. In that case, what are we going to do about the unbearable vulnerability? Vulnerability can be harnessed as a motivator for change or it can deter us from contributing.
10:00
There are ways we can foster a welcoming community and attract more contributors rather than deter them. Before we explore ways in which we can make better open source communities, we're going to look at ways in which maintainers make vulnerability unbearable. Vulnerability can be a deterrent for many new and long-time contributors.
10:21
Feelings of inadequacy can keep folks from contributing to your project, which means maintainers lose out on changes from other viewpoints that can make their project more robust and stable. We want to avoid creating an environment that fosters fear of contributing in favor of an environment that's welcoming and inclusive. We want to create environments and communities
10:41
that cultivate creativity and inspire contributors. One of the ways maintainers deter contributors is closing pull requests without providing feedback. When maintainers do this, they don't leave room for the contributor to improve in the future. Maintainers should always explain why a pull request
11:01
wasn't accepted, otherwise contributors might take it personally. Contributors spend a lot of time and emotional energy on contributing and it can be demoralizing to not have your pull request accepted. Ask clarifying questions if you don't understand why a change was made or what their use case is. Being dismissive and not giving feedback
11:20
will cause contributors to feel like their time isn't respected and they may not contribute to your project again. Another way in which maintainers can make contributors feel more vulnerable is through violent communication. An example of violent communication is saying, this code sucks or did you even try to fix the problem? This communication style passes the blame
11:41
onto the contributor and shames them. This will lead to contributors feeling defensive and more vulnerable. It will deter them from contributing in the future because they don't feel respected. It's easy for context to get lost over in communication, so try to over communicate with nonviolent techniques to get your points across
12:00
so you don't alienate contributors or future contributors. If you want to learn more about nonviolent communication, you should watch this talk by Nadia, who's sitting right there, called This Code Sucks, A Story About Nonviolent Communication. Her talk explores what nonviolent communication means and the benefits for using it in your communications at work.
12:22
Often I see bad behavior being tolerated by someone who's a high impact member of the team. They respond to lots of pull requests or they send lots of patches. Even if a contributor or maintainer may seem like an asset if they're abusive towards new contributors, that will deter other contributors in the future from joining your community.
12:42
It's important to protect your contributors from bad actors and to not tolerate behavior that's exclusive or offensive. A power dynamic exists between maintainers and contributors. It's important to recognize this because maintainers inherently have more power than contributors.
13:00
This will always be true because maintainers decide what gets merged and who gets to contribute. Because of this power dynamic between contributors and maintainers, it's up to maintainers to set and reset the tone of the conversation. There are always going to be assholes who come into your project and demand free time from you, but most of the people contributing to your project
13:21
mean well. It takes a lot of energy to be rude to people. Wouldn't maintaining it be easier if we could learn to diffuse stressful situations instead of making them worse? As a maintainer myself, I have felt the pull to tell someone off. When that happens, I try to put myself in their shoes and take a walk before responding.
13:43
They're probably frustrated. Maybe their boss is breathing down their neck to get this fixed. Maybe they dropped a production database. Often taking the time to tell the contributor that I know they're frustrated quickly turns the conversation from defensive to productive. This doesn't mean giving the contributor
14:02
everything they want. It just means treating them the way that you want to be treated in a stressful situation. Vulnerability can be harnessed as a motivator as well. Being vulnerable isn't a bad thing and we have all felt it before. Every single maintainer and contributor has at one time felt vulnerable
14:20
and probably will feel vulnerable again. But when we feel safe being vulnerable, we're more creative, more inspired, and more open. If we can change our open source communities to be more welcoming and supportive, they will be more sustainable and the vulnerability will be bearable. So why is it important that we create a welcoming and supportive open source community?
14:42
Why does it really matter if contributors don't feel safe being vulnerable? Open source is a funnel. At the top you have your users. Some of those users become contributors and some of those contributors become maintainers. The more maintainers you have, the more sustainable open source can be
15:02
because you have more backup. Making our open source communities more welcoming will attract more users to become contributors and more contributors to become maintainers. If we don't do this, we'll end up on an island alone maintaining projects by ourselves. This leads to less users because you can't sustain the project alone, less job offers because no one is using your project,
15:22
and less friends because, let's face it, you're spending all of your time working on open source instead of having a life. Imagine a world where instead of burning out on that island, the funnel didn't lose so many potential maintainers. I just realized how much death has been talked about at RubyConf and I just threw a skull up on there.
15:43
It's the theme. But don't worry, you will all live. You will learn to live better. What would the ideal open source world look like? It might look like something like users and contributors and maintainers all moving equally among roles.
16:01
In today's open source world, maintainers often stop being users of their own product. Some even stop contributing beyond approving and merging pull requests. It doesn't have to be like that, but I also think that this ideal world is very hard to achieve because of open source and the political structure of everything.
16:20
So if this ideal world isn't really possible, what is possible? I'd like us to aim to get the funnel to be a little bit more like this. Users are still the majority of people who are involved in your product, but users are more likely to become contributors and contributors more likely to become maintainers in the previous funnel. I'd also like there to be less friction to move from users to contributors
16:41
to maintainers and back again. Open source needs contributors. Without them, open source will cease to exist and thrive. We need to make open source more sustainable so that people continue to contribute to open source. Open source software is the present and future of technology, and without it, innovation will stagnate.
17:03
So how do we create a welcoming and supportive open source community so that new contributors join and open source communities thrive? There are a lot of ways in which we can make open source a better experience for everyone. Healthy communities benefit maintainers, contributors, and users.
17:26
One way in which maintainers can attract and retain more contributors is through mentorship. Many of my first contributions to Rails were the result of pairing with Aaron Patterson. Mentorships don't need to be official and can happen organically. I met Aaron at a conference,
17:41
and after my talk, he told me I discovered a bug in Rails and offered to pair with me to fix it. Before I made my first commit to Rails, I never thought I'd be on the Rails core team. Rails is a really complicated code base, and it can be difficult to get used to working on. On top of that, the community is massive. Rails has over 2,000 contributors,
18:01
and at least 2,000 people get notifications when issues in PRs are opened. I didn't think that I had something more to offer than they did. Aaron and I started pairing regularly, which helped me learn faster and feel more comfortable contributing. It didn't erase all of my anxiety, but instead of feeling unbearable dread
18:21
when contributing to Rails, I was excited. Aaron's guidance helped me navigate both the code base and the community, making contributing to Rails less stressful. I knew he had my back and would help me defend decisions in PRs we made, mostly because those decisions were his crazy idea.
18:43
Mentoring can happen in many forms, from pairing to email to inviting contributors to a group chat with other maintainers. I've helped folks get their first contribution through Twitter DMs, pairing, and email. Mentoring doesn't have to be official or time-consuming. The point of mentorship is to act as a guide for your mentee and help them feel welcome in the community.
19:04
Writing up clear guidelines for contributing can help make maintainers feel more welcome to your project. It's always easier to contribute to a repository that's explained what's expected rather than guessing. Each open source project has their own rules for contributing. For example, the Rails project doesn't accept
19:21
feature requests on the GitHub issues tracker. Other projects are fine with this type of issue, so clearly setting up the guidelines for your project will allow contributors to focus on contributing rather than being worried about breaking unspoken rules. Be sure to add a contributing markdown file to your GitHub repository. Include any rules about contributing that are unique to your project,
19:41
like requiring all pull requests to be a single commit or not allowing cosmetic changes to the code. The Rails team provides bug report scripts that can be used to replicate bugs experienced in Rails applications. This means that users don't need to provide us a full application to reproduce the bug that they're experiencing. If the bug can't be reproduced with one of our scripts,
20:02
then we know it might be a gem or something weird that's about their data specifically with their application. This helps us triage issues faster because we can see directly where the behavior is caused from instead of playing guessing games and figuring out a reproduction. This helps contributors by reducing the amount of work
20:21
they need to do to give us a reproduction, so they spend less time stressing out about potentially being wrong and can just give us what, and then it's easier for them to contribute after that. When possible, use bots or scripts to handle pull request triaging or to remove personal bias or ensure contributors don't feel ignored.
20:44
On the Rails project, we use a bot to auto-assign a pull request to maintainers. Rails gets so many pull requests that it's hard to give everyone attention, but with the assignment bot, we can mostly focus on what's assigned to us. It still gets overwhelming. This helps new contributors know that someone is paying attention
21:01
and will respond to them soon. We also use linters to tell contributors what needs to be fixed, which reduces bike shedding and nitpicking about small details because nobody wants to argue with a bot. Everyone makes mistakes, so if you see a new contributor fail to add CIskipped for a documentation change
21:21
or open a feature request on the issues tracker, don't shame them. This is my dog, by the way. Her name's Aria. You can follow her online at ariadog. Kindly tell them how to contribute better in the future. This will ensure that even if, in that case, their pull request isn't merged or you asked for changes, they don't feel like you were nitpicking on them
21:43
and picking on them and making them feel bad for making some tiny little mistake that doesn't really matter, so Travis runs one extra time. Big deal. I mean, it's probably a bigger deal for Travis than me, but there's no point in putting someone down, so that will only chase folks away
22:01
who are trying to help you. When you're a maintainer of a project, it's easy to think that you have to do everything yourself. I think it's important to know when and how to ask for help. You can use your readme to document areas where your project needs help. When I first started contributing to mini-profiler, I knew exactly what Sam Safran wanted help with
22:20
because he laid it all out in his project's readme. In fact, he still needs help in some of these areas, so if you're interested in getting your first contributions, this is a really great project where you know exactly what to help with, and Sam is super awesome. Contributors will feel more welcome to push changes to your project if they know the work they're doing is wanted.
22:41
This reduces vulnerability and stress when opening that initial pull request. Asking for help in your documentation is a great way to get the contributions you need and bringing contributors who are passionate about helping your project. One of the ways that you can ask for help is by promoting contributors to maintainers.
23:02
Rails wouldn't be as successful as it is today if DHH didn't share the burden of making decisions, releasing new versions, and sculpting the future of Rails with us. Rails Core currently has 12 members. That means that all of us don't need to be available all the time for Rails to thrive. While smaller projects aren't likely
23:20
to have a team as large as Rails, it's important to find contributors that you trust to cultivate the community around your project and help maintain your vision for the code base. Trying to maintain a project by yourself is a fast track to burn out. We can create more sustainable communities if we're nice to and respect everyone.
23:41
Maintainers set the tone of the conversation. Yes, assholes will always exist, but the majority of contributors come to your project with good intentions. One of the most important things to remember as a maintainer is to not review pull requests before you've had your morning coffee. If you're like me, you are very grumpy before coffee, and you maybe haven't even recovered
24:02
from the nightmares you had the night before. I have personally jumped to snap conclusions when I review pull requests before having coffee. Often, it's more likely I'll be short with the user and dismiss the pull request without a proper review. Take the time to take care of yourself before reviewing pull requests. Contributors will feel more welcome
24:20
and won't have to put up with your crabbyness. Being dismissive or rude because you haven't had your coffee could prevent contributors from helping you in the future, which, let's face it, is only going to make you grumpier. As we talked about earlier, employing nonviolent communication tactics is the best way to interact with contributors. You probably should employ nonviolent communication methods
24:41
in all areas of your life, but right now we're just talking about open source. Using nonviolent communication will keep the conversation open. Remember that as a maintainer or contributor of a project, you set that tone of the conversation. Recently, we had a situation on the Rails project where an issue got closed quickly without a conversation.
25:02
This, of course, resulted in the contributor getting defensive because we weren't listening to them. I took the time to respond to the contributor and let them know that I understood how they felt, and I asked what solutions would work for them. This immediately changed the tone of the conversation. Instead of being annoyed, we were able to talk about solutions.
25:21
This doesn't mean the contributor is gonna get exactly what they want or that we're going to fix the issue, but they no longer feel that the problem is they were ignored or dismissed. As a maintainer, you can show respect, you can show that you respect your contributors
25:40
and future contributors by adding a code of conduct to your project. This will attract new contributors because they know that you're serious about maintaining a professional and respectful community. While codes of conduct benefit everyone, people from underrepresented groups are more likely to feel comfortable and welcome contributing to your project if you implement a code of conduct
26:00
and ensure that all of maintainers and contributors treat each other with respect. Maintainers can use GitHub-provided tools to signal that their community is healthy and welcoming. A great feature that GitHub added a few months ago is the first-time contributors badge. This badge clearly indicates when contributors are new to your project.
26:20
When you see this badge, give that contributor a little extra time and be a little extra helpful. When I see this badge, I like to take the time to congratulate the contributor on their first pull request. As a maintainer of Rails, I want contributors to have a good experience, and letting them know that I appreciate the time they put into Rails, especially as first-time contributors, they will be more likely to contribute again
26:41
in the future. Another GitHub tool that was rolled out recently to everyone is the community profile. The community profile tool is a tool that shows GitHub's recommended standards for creating a welcoming and sustainable open-source community. The community profile is located under the repository insights tab via a link called community.
27:03
The community profile page will show you six items that make a healthy open-source project, a description, a readme, code of conduct, contributing guidelines, a license, and issue and PR templates. Each of these items will help make your project more approachable and sustainable. If your community profile is not complete,
27:21
GitHub provides a wizard to help you add the missing items, like a code of conduct, or picking a license that works for you and your project. We've talked a lot about how maintainers can build better communities. All of this is to help contributors who feel welcome and inspired. The goal is to make vulnerability bearable
27:40
for our contributors. Now we're going to look at ways that contributors can find healthy open-source communities where they know their contributions will be welcome. One of the easiest ways to find a project to contribute to is to look at the tools you use every day. If you build rouse apps, go look in your gem file for ideas of projects that might need your help.
28:01
That's how I ended up contributing to mini-profiler. Contribute to the tools that you use because that's where you'll be most useful. In open-source, users become contributors and contributors become maintainers. So with that logic, the easiest way to become a contributor or maintainer is to first be a user. A great way to find a community or project
28:21
you want to be a part of is spend some time observing the behavior of the maintainer or other contributors. First, make sure the project is active. Active projects have recent commits. Look at the top bar in GitHub repository to see when the last commit was.
28:40
Projects that are active will have pull requests, merge or issues closed in the last few days to months. My first open-source contribution was for a project that had been long abandoned and it didn't feel good to make a contribution that would never be accepted. There are a few ways you can go about making changes to abandoned projects. You can offer to take over maintaining the project
29:02
or open a PR with the expectation that it won't get merged. Don't open an issue that asks, is this still maintained? Especially when it's very obviously not maintained. Once you're sure the project is active and accepting new contributions,
29:22
take a look at how maintainers respond to new issues or pull requests. Subscribe to a few of those pull requests on the project and see how maintainers treat contributors. Are they kind or dismissive? Do questions go unanswered or do they help them get the pull request merged? This will help you know what to expect when you open that first issue or pull request.
29:42
Most maintainers are volunteers, so being unresponsive doesn't mean they're rude. They're just busy or burnt out. But knowing the communication style of maintainers upfront can help you be more prepared when you open that first issue or PR. Just as most maintainers are volunteers and open source,
30:01
you're a volunteer too. You don't have to work for free for assholes. If a maintainer or other contributors aren't respectful of you and your time, it's okay to say nope and go work on other open source projects.
30:24
There are projects that I have used in the past and applications that I wouldn't contribute to because I didn't think the maintainers treated people the way that I wanted to be treated. I didn't want to have to interact with them in order to get my bug fixed and then just feel like shit all the time because they were rude to me.
30:41
There's no requirement that you voluntarily work on open source projects where maintainers or contributors are rude to you. A big part of contributing to open source is learning how to accept rejection. It's really demoralizing to not have your pull request accepted, but often maintainers have a vision for their projects and that's a big reason
31:01
why pull requests are accepted or rejected. I've had many pull requests rejected and I know that it's not fun. But don't take the rejection personally. It's all part of contributing to open source. Ask for advice on how to do better next time and apply that to your future work. Once you do find a community and projects that you want to contribute to,
31:20
be as respectful as you want the maintainers to treat you. Hitting a bug in an open source project is really frustrating, but maintaining a project is hard too. Most maintainers are volunteers so while the majority of this talk was about how maintainers can do better, contributors can do better too. Treat maintainers the way you want to be treated
31:40
if you were a maintainer. There are a ton of resources to help contributors and maintainers have a better experience and build more sustainable open source communities. Firsttimersonly.com, yourfirstpr.github.io and codetriage.com help new contributors find projects that need help and are actively seeking out new contributions.
32:03
Open source.guide is written by my lovely colleagues at GitHub and it's a resource for contributors and maintainers with ideas about building more welcoming communities, finding your first pull request and implementing open source Fridays at your job. Open source isn't about writing code.
32:22
Open source is really about people, our insecurities, interactions, our unbearable vulnerability. The thought of contributing to open source or interacting with toxic communities can be paralyzing, but open source cannot survive without contributors. It's our responsibility to build welcoming communities
32:42
so that open source is sustainable and inspirational instead of paralyzing and toxic. We can do this by mentoring, asking for help when we need it and demanding that we all treat each other with respect. Let's build a world where instead of ending up on that island,
33:00
burning out from maintaining projects alone, we get to work with bright minds and share ideas in a healthy sustainable community. The benefits are endless. Building a better community will attract more contributors. This makes open source communities more stable and sustainable. Maintainers and contributors are less likely to burn out because there are more people to share
33:21
the burden of contributing with, less demand on their time and more emotional support. Let's build open source communities where less contributors experience dread when contributing because they're vulnerable and afraid and more contributors experience that high because they were inspired by their vulnerability to build something amazing for your project.
33:43
We must all work together to create more sustainable open source communities. The future of open source depends on all of us. I hope the maintainers in this room are inspired to go out and build better open source communities. I hope the folks in this room who've never contributed to open source are inspired to move past their vulnerability
34:01
and contribute. And I hope that everyone will respect each other and recognize the vulnerability everyone has to overcome to contribute to open source. The job of growing these communities doesn't lie solely on one maintainer, one contributor, or one project's shoulders. The responsibility is all of ours to build a community we want,
34:20
whether we're a contributor, maintainer, or user. Together, we can make sure open source thrives by building welcoming and sustainable communities. Together, we can make the unbearable vulnerability of open source bearable. Thank you.
34:50
Anyone has questions? I think I have time. Wait, do I have time? I have time, okay. And afterwards, I have stickers from GitHub.
35:01
So if you haven't gotten enough stickers, I have more. I have about five minutes. Okay, questions. Okay, the question is how much time do I spend triaging, reviewing, and other things? I would say that since joining the Rails core team in February, I spend less time writing software
35:22
for Rails and more time triaging and pull request merging. I don't know exactly how many hours I spend because some weeks I don't work on it at all and some weeks I spend more time, probably maybe five.
35:40
I should spend more time on it is really what I'm getting at. I don't feel like I'm spending enough time because we have issues trackers and saying right now. But that's why all of you need to become contributors of Rails so that you can join the core team and then we'll never have inbox zero. It's fine. But you can all help me triage issues.
36:02
I don't think that was a good answer to your question. I'm sorry. So I talked about the funnel and how users move to contributors and maintainers. And what I also talked about how Rails has a lot of open issues and doesn't seem like maybe we're not
36:22
moving that funnel around a lot and how we can improve that funnel. I think that Rails is a hard example for that because it's such a complicated code base. I think there are things that we could do better.
36:41
We could mark issues that are easy more often. We don't really do a good job of that. I think we could pair more with new contributors. I think we could do a better job
37:00
of explaining how we figured bugs out because I think there's a lot of people who think that we on the Rails core team are like magic unicorns who understand Rails internals. But it still takes us hours to figure out problems sometimes too. And if we talked more about, I don't know if I've even seen Richard's names when he does his blog post about I debugged a thing.
37:22
And they're really good. We should do more of that too. Everyone who spends time investigating bugs in open source, it would be great if we all, and I say that as me too, I should do this. It would be great if we all wrote more about finding those problems and solving them because sometimes they're not,
37:41
sometimes they are really hard and sometimes they're just, oh, I knew that this was in this gem and this is how to make a script to test it and here's how to bisect and then that's how you, that's most of the time how we figure it out. Yeah, get bisect, best tool ever. Does that answer your question?
38:03
Okay, I don't see any hands. But I will be around. Come ask me questions. I have stickers and thank you.