The Unbearable Vulnerability of Open Source

Video thumbnail (Frame 0) Video thumbnail (Frame 2018) Video thumbnail (Frame 3585) Video thumbnail (Frame 5936) Video thumbnail (Frame 6687) Video thumbnail (Frame 7503) Video thumbnail (Frame 9153) Video thumbnail (Frame 11419) Video thumbnail (Frame 12225) Video thumbnail (Frame 13035) Video thumbnail (Frame 14524) Video thumbnail (Frame 17381) Video thumbnail (Frame 19261) Video thumbnail (Frame 20450) Video thumbnail (Frame 21208) Video thumbnail (Frame 22186) Video thumbnail (Frame 24615) Video thumbnail (Frame 26390) Video thumbnail (Frame 27486) Video thumbnail (Frame 28558) Video thumbnail (Frame 31923) Video thumbnail (Frame 33301) Video thumbnail (Frame 34416) Video thumbnail (Frame 35361) Video thumbnail (Frame 36793) Video thumbnail (Frame 38284) Video thumbnail (Frame 39118) Video thumbnail (Frame 40173) Video thumbnail (Frame 41214) Video thumbnail (Frame 42683) Video thumbnail (Frame 43839) Video thumbnail (Frame 45216) Video thumbnail (Frame 47556) Video thumbnail (Frame 48447) Video thumbnail (Frame 50280) Video thumbnail (Frame 52673) Video thumbnail (Frame 57373)
Video in TIB AV-Portal: The Unbearable Vulnerability of Open Source

Formal Metadata

The Unbearable Vulnerability of Open Source
Title of Series
Number of Parts
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this license.
Release Date

Content Metadata

Subject Area
If contributing to open source was only about writing code, it would be easy. In reality open source exposes our insecurities and makes us feel vulnerable. Vulnerability can inspire change, but can also paralyze us for fear of not being good enough. In this talk we'll look at how vulnerability affects open source contributors and explore how maintainers can foster a welcoming community. Contributors will learn how to identify projects with empathetic leaders who value GitHub’s community standards. Cultivating a better environment for contributing makes open source more sustainable for all.
Computer virus Core dump XML Cartesian coordinate system Open set Twitter Software bug Revision control System programming Form (programming) Library (computing) Systems engineering Physical system
Web page Greatest element Open source Multiplication sign ACID Mereology Software bug Profil (magazine) Spacetime Software framework Statement (computer science) Vulnerability (computing) Point cloud Mobile Web Clique-width Projective plane Sound effect Bit Database Control flow Cartesian coordinate system System call Process (computing) Software Mixed reality Spacetime Row (database)
Word Software repository Multiplication sign Projective plane Vulnerability (computing)
NP-hard MUD User interface Open source Code Multiplication sign Decision theory Disintegration Projective plane 1 (number) Maxima and minima Event horizon Software bug Hypermedia Video game Software testing Software testing Physical system Physical system Vulnerability (computing) Vacuum
Sign (mathematics) Open source Code Repository (publishing) Projective plane Revision control 1 (number) Musical ensemble Information security Traffic reporting Vulnerability (computing) Software bug
Open source Multiplication sign Projective plane Moment (mathematics) Feedback Software maintenance Food energy Portable communications device Mathematics Process (computing) Integrated development environment Personal digital assistant Telecommunication Vulnerability (computing) Default (computer science)
Point (geometry) Context awareness Word Arithmetic mean Exclusive or Telecommunication Telecommunication Patch (Unix) Chain Code Musical ensemble Software maintenance
Boss Corporation Dynamical system Game controller Multiplication sign Projective plane Software maintenance Food energy Product (business) Power (physics) Arithmetic mean Bit rate Reduction of order Data conversion Freeware
Open source Single-precision floating-point format Open source Endliche Modelltheorie Software maintenance Vulnerability (computing) Product (business)
Open source Computer file Multiplication sign Projective plane Open source Incidence algebra Software maintenance Product (business) Vector potential Process (computing) Software Ideal (ethics) Video game Data structure Resultant
Right angle Software bug
Group action Code Codierung <Programmierung> Decision theory Electronic program guide Online help Software maintenance Twitter Form (programming)
Open source Computer file Code Mountain pass Multiplication sign Robot Maxima and minima Set (mathematics) Mathematical analysis Content (media) Mereology Rule of inference Software bug Product (business) Subset Mathematics Information Traffic reporting Scripting language Electronic program guide Projective plane Code Software maintenance Cartesian coordinate system Template (C++) Inclusion map Game theory Information security
Point (geometry) Area Multiplication sign Projective plane Online help Software maintenance Mathematics Coefficient of determination Process (computing) Ring (mathematics) Personal digital assistant Profil (magazine) String (computer science) Software repository Repository (publishing) Key (cryptography) Data structure Vulnerability (computing)
Revision control Trail Goodness of fit Code Decision theory Multiplication sign Projective plane Summierbarkeit Online help Data conversion Software maintenance Machine vision
Area Inclusion map Arithmetic mean Open source Multiplication sign Telecommunication Projective plane Video game Data conversion Software maintenance
Group action Code Network topology Projective plane Code Core dump Integrated development environment Software maintenance Thermal conductivity Code Open set
Web page Execution unit Empennage Standard deviation Building Open source Code Multiplication sign Programmable read-only memory Projective plane Infinity Software maintenance Profil (magazine) Repository (publishing) Automation Thermal conductivity Descriptive statistics
Execution unit Computer file Open source Multiplication sign Projective plane Online help Group action Software maintenance Mereology Rotation Product (business) Expected value Mathematics Logic Profil (magazine) Repository (publishing) Software testing Relief Vulnerability (computing) Cloning
Word Open source Multiplication sign Telecommunication Network topology Projective plane Software maintenance Routing Traffic reporting
Software bug Context awareness Building Open source Code Multiplication sign Projective plane Electronic program guide Code Online help Coma Berenices Software maintenance Mereology Cartesian coordinate system Machine vision Product (business) Subset Software bug Message passing Process (computing) Network topology Order (biology)
Dependent and independent variables Open source Multiplication sign Projective plane Interactive television Shared memory Online help Open set Software maintenance Vulnerability (computing)
Dependent and independent variables Process (computing) Open source Multiplication sign Projective plane System programming Lie group Software maintenance Demoscene Vulnerability (computing)
Scripting language Gender Multiplication sign Sound effect Coma Berenices Open set Software bug Process (computing) Software Blog Moving average Software testing Figurate number
the the the the the
the the the the I really I'm eileen you should I live
in upstate New York about 2 hours north of the of the city in in that as soon as the 1st couple of New York up until and the British burned down I twice so you can find me anywhere online at the handle and encodes now that means like Twitter is mouth get home anywhere that I actually want you find me I'm a senior systems engineer idea spot form systems team popcorn systems is that she was responsible for Rouse and Rabin the other libraries and how was interact with the get application and also the newest member of the Rose team which means that I am allowed to be rails to account could this is the only important part of or else between members but for those of you don't know our also responsible for defining the future of rails releasing versions and you know like fixing the bugs for all of you sometimes
David on to talk about the unbearable wanna ability of contributing to open source but for a 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 on specifically referring to contravene open source and how that exposes a insecurities and makes us feel it were not good enough to contribute the vulnerability that we feel when contributing can inspire us to change the software reuse and the communities we belong to or can be so unbearable that it's paralyzing because our vulnerability makes is afraid of contributing I've Inc 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 1 mobility is an inherent part of controlling open source and I don't think that's something that I'm ever going to go get over I open my very
1st call request on get out in 2012 it was a pull-request effects of a typo in every of a project that I had been using the PR was never emerge because the project had been abandoned for a few years almost a full year later I open my 2nd pull request many Profiler is a database and request profiler for applications I notice while using a profiler that there was this like little extra space at the bottom of the page there was super annoying and I thought this is a CSS but so is the effect what we found out was not see assets and it took me 2 days to find the invisible UTS 16-character was hiding it hiding in like user jobs compiler ACIUS as follows was so was and even though I had spent lots of time with at the issue and I was confident that I fix the bug I was so worried that I was wrong or that my contribution will be welcome I felt vulnerable because I didn't know what to expect after giving a talk in 2014 amount west I I learned that I found a bug active record and Patterson who most of you know as rousing require team member Justice tender love acid by 1 parrot him to implement a fix for the problem shortly after pairing on that fixed I open my 1st pull request for the Ruby on Rails framework even though I had worked with Aaron and knew that I would like to have the right mix I was still really nervous about
opening a P R against a repo word 2 thousand people get notifications every time you open issuable request I felt horrible because I was a new contributor when somebody thought might fix was stupid was me that I was stupid these thoughts might seem a rational but they are embedded in contributing to open-source because we're dealing with people not code the other side of that fear though is the high you get when you poor presses
merged I continued to contribute to Rowell's regularly after that for 1st pull request maybe it was because I had someone mentor me and help me understand rails internals maybe it was because I had such a good experience controlling that 1st time 1 of those in this talk is to prime ways in which you can improve your communities so more contributors experience that high instead of the unbearable vulnerability of to your project
this past year were large feature for Els called system tests previously a lot of my work on rails had been refactoring code fixing bugs or improving performance you know all that stuff and no 1 actually cares about this is my 1st experience adding a major feature to roust and by media I mean it was literally the highlight of the rails 5 comma decimal 1 release working on this project for reminding me how hard contravene open source can be I am entry into me Darelle's for over 2 years but I was a nervous opening this poll request I had this familiar thoughts what everyone hates this feature what someone things my code is bad even though DGH decreed aroused nearly asked me to build this feature I still had a deal the reviews and the comments and that and defending my decisions that I when I open the pull request I had already put 3 months of work into it the project was personal to me because I spend nights and weekends working on it and I became attached to the code in a time for questions open I received over 150
comments and 11 reviews at a lot of other opinions to deal with I felt stressed and vulnerable just like how I open my 1st pull requests somebody between about the PR which only drew more attention to it I don't know your intention is good reviews a good but I was trained by the endless bike-sharing indicating of details None of reviewers many harm they were really excited about the future still a little discomfort not any I had been an avid contributor arouse for 2 years and released rose 5 in I had that writes so why was opening this P R a nail-biting stress-inducing event in my life I figured I'd be over the unbearable vulnerability by now while openly about that something in me I realize that even if we use a working on open source we can still experience vulnerability when we were hunter new project or age of a large feature the more time we spend on open-source especially free time the more attached become to the work that we're doing this'll only 1 explanation for why this happens controlling open-source was only about writing code it would be easy but we all know culture in open source is easy were not just dealing with coder ones and zeros no 1 would be worried about opening a pull request it open source was about writing code so what resources in about writing code that means that open source is
really about people it's the people who make us feel vulnerable did you mean open source is about in securities are fear of being wrong and our fear of showing appears or work often just the thought of pushing code to a public repository can cause anxiety for me given that while people are the source of a vulnerability there essential to the open source ecosystem was taken and to think about what this was would be like without people
so you write and general library and of to shirt public for anyone to use but if no and I is really an open source project Misses as a work without users otherwise you're not really sharing the code of anyone know users means no bug reports which means you worked as an improved and if you start improving yourself no one's going to notice because they don't use it wire code many public it's just public code until some music let's say attends of users
but no contributors sure you get to control the project and you never have to deal other ideologies but is that really open source if you stop improving the project we want something else the project won't really be useful anymore open Source can survive without contributors a magic moment for world where Matt's created ruby but had no contributors would be as a masters is today definitely not with all the engineers who learned through not jobs not writing job will be as happy as they are today I don't know marry everyone would have adopted in PHP instead of the community and tools will be very different from where they are today if we had done that I wouldn't be here today giving this talk it was for revere else and its success and all of those contributors contributed contributing to that success so I'm
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 born ability can be harnessed as a motivator for change or to deter us from contributing there are ways you can foster a welcoming community and attract more contributors rather than deter them before we explore ways in which we can make that better open-source communities relying on the ways in which maintainers make portability unbearable more ability can be a deterrent for many new a longtime contributors feelings of inadequacy can keep folks from contributing to your project which means maintainers lose out on changes from other viewpoints that we can make the project more robust and stable we want to avoid creating an environment that fosters fear of contributing in favor an an environment that's welcoming and inclusive we want to create environments and means that cultivate creativity and inspire contributors 1 of the ways maintainers deter contributors is closing pull request without providing feedback when antennas do is they don't leave room for contributors to improve in the future maintain should always explain why pull request was accepted otherwise contributors might take it personally engineer spend a lot of time and emotional energy on contributing a Kameda moralizing to not have your Pull request accepted ask clarifying questions if you don't understand why changes made war with the use cases being dismissive and not giving feedback will cause contributors to feel like they're their time is a respected and they may not contribute to your project again another way in which maintainers commit contributors feel more marble is through violent communication example of i communication is saying this concert
sordid you and try to fix the problem this
communication style passes the blame onto the
contributor and chains them this will lead
to contributors feeling defensive and more viable
it will deter them from contributing in the future because
they don't feel respected It's easy the context get glossary communications so tried over
communicate with nonviolent techniques to get your point
across don't alienate contributors for future
contributors if you wanna learn more about by communication you should watch this talk by idea missing right there called this coincides a story about Nobel and communication her talk explores were not buying communication means and the benefits for using it in your communications at work often I see bad behavior being tolerated by someone who's a high-impact member of the team responding a phonological requests really open some lots of patches even if a contributor a maintainer may seem like an asset if they're being sent words new contributors that will deter other contributors for in the future from during your community It's important protector contributors from bad actors into not tolerate behavior that exclusive bands of how a dynamic exists between
maintainers and contributors it's important to recognize this because maintainers inherently have more power they contributors this will always be true because maintainers decide what gets emerged 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 becoming a product demand free time from you but most of you know controlling a project meanwhile it takes a lot of energy to be rude to people when maintaining the easier we can learn to diffuse stressful situations instead of making them worse as a mean to myself I have felt the pull the tell someone off when that happens I try to put myself in their shoes and take a walk before
responding they're probably frustrated maybe the boss is breathing down their neck to get this fixed many they dropped a reduction in rates often taking the time to tell the controller that I know the fracturing quickly turns turned the conversation from defensive to productive this doesn't mean giving the contributor everything they want it just means treating them the way that you wanna be treated in a stressful situation 1 of making the hard as a
motivator as well the model is a bad thing we have all felt it before every single maintainer contributor has a one-time fell bobble and probably will feel vulnerable again but but we feel safe honorable were more creative more inspired a more open it we can change our own research community is to be more welcoming and supportive they'll be more sustainable and the vulnerability we bearable so why is it important that we create a welcoming in support of open source community why doesn't really matter if contributors don't feel safe being vulnerable only serves as a final others how 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 because you have more back making our open-source communities more welcoming will attract more users become contributors and were contributors become maintainers we don't do this 1 on an island alone maintaining product by ourselves
this leads to less users because you can sustain the product alone less job offers because no 1 is using your project and less friends because let's face it you're spending all your time working on open-source instead of having a life a world incident burning up on that island the final don't lose so many potential maintainers and Israel is like how much debt has been talked about the company justice for of men is the thing the dowry all live you learn to live at of when the ideal open source world look like I'm not like something like users and contributors and maintainers all the equally among roles in today's open source world maintainers often stopping users of their own product something even start contributing beyond approving and merging pull requests it is and have to be like that but I also think that this ideal world is very hard to achieve because of open source and like the political structure of everything so this ideal world is it really possible what is possible unlike is to to get the
final you'll be more like this users so the majority of people who are involved in our in your product but users are more likely to become contributors and contributors were likely commentators the previous file I also like in the less fortunate move from users to contributors to maintainers and back again or as news contributors without them open source will cease to exist and thrive we need and we need to make open source more sustainable so that he will continue to contribute to a or source software is the present and future of technology and without innovation will stagnate so how do we create a welcoming in support of open source community so that new contributors joined and open source communities thrive there are a lot of ways in which we can make open source a better experience for everyone helping communities benefit maintainers contributors and users 1 way in which maintainers can attract and retain more contributors this through mentorship many of my 1st contributions to sterols were the result of pairing with Patterson Mendez studied in the official again
happen organically and that are at a conference after right at the end of my talk he told me I discovered a bug in rails and often apparently a fix it before I made my 1st commit Terrell's I never thought I'd be on the rails QWERTY rather don't really complicated could base and it can be difficult to get used to working on on top of the community is massive well says over 2000 contributors and at least 2 dozen people get notifications when issues of Artur open I don't think that I had something more often than they did on ice appearing regularly which help me learn faster and feel more comfortable contributing it didn't erase all of my anxiety but instead of feeling unbearable
dried with contributing to rails I was
excited as guidance how we navigate both the code base and the community making continue rouse less stressful and you have my back would help me defend decisions in pure as we read mostly because those decisions for his crazy idea
mentoring can happen in many forms from pairing to e-mail to inviting contributors group chat with other maintainers I've help folks get the 1st contribution through twitter Deanne's pairing now mentary doesn't have to be official or time-consuming the plant mentorship this act as a guide for your men t and held until welcome in the community writing a clear guidelines for
contributing can help make maintainers feel more welcome your project it's always easier contribute to repository that's explained what's expected rather than guessing each open source project has their own
rules for contributing for example the Rell's project doesn't accept feature requests on GitHub issue tracker other products are fine with the set of issues so clearly set up the guidelines for your project will allow contributors to Focus on contributing rather than being worried about breaking unspoken rules we should add a controlling markdown files you get have repository include any rules about contributing that you need to your project like requiring all pull request b a single commit or not aligned cosmetic changes to the code the summarized bug reports scripts that can be used to replicate how bugs experience and rails applications this means that users don't need to provide as of full application to reproduce the public they're experiencing if the bond can be reproduced with 1 of our scripts then we know it might be a jam or something that's about something where there's about the data specifically with the application of this House's triage issues faster because we can see directly that the main where the behaviors scores from instead of playing guessing games at figuring out a reproduction this helps contributors by reducing the amount of work they need to do to give us reproduction so they spend less time stressing out about potentially being wrong and just give us what then the it's easier for them to contribute back about 1 possible use bots or scripts to handle it pull requests triaging or to remove personal bias for ensure contributors feel don't feel it not on the rest part use about to auto assign a pull request to maintainers Wells gets so many pull request that it's hard to give everyone attention but with the Simon Bott weakens mostly focus on what assigned to us it's still it's a this helps new contributors know that someone is paying attention and will respond to them soon we also use tell contributors what needs to be fixed which reduces by chatting and picking out small details because nobody wants argue about everyone makes mistakes so if you see a new contributor felled NCS skipper
documentation change or if you or open and feature requests on issues tracker shame them this is my dog right away and diarrhea you can follow our online it on kindly tell them how to contribute better in the future is on show that even if in that case the poor process merged or are they you ask for changes they don't feel like you're in you're not thinking on them and taking on making them feel bad for making some tiny little mistake that doesn't really matter so Travis runs 1 extra time to go this time bigger deal for Travis and me but there's no point in putting someone down so that will only chase folks away who are trying to help you when you're maintainer of a project is easy to think that you have to do everything yourself I think it's important to know when and how to ask for how you can use your reading a
document areas where your project needs help when I 1st started entering a mini profile I knew exactly what sense afferent wanted help with because he laid it all out his projects really in fact he still his help in some of these areas so if you're interested in getting a 1st contributions this is a really great project where you know exactly to help with incentives to prosper contributors will feel more welcome to push changes to your project if they if they know what they're doing is wanted this reduces vulnerability and stressed when opening that initial asking for help your documentation is a great way to get contributors you need and bring contravene ring you get the contributions you need every contributors who are passionate about helping a project 1 of the ways
that you can ask for help is by promoting contributors to maintainers rel sum wouldn't be as successful as it is today DH aged and share the burden of making decisions releasing new versions and scope in the future rails with us well score currently has 12 members it means that all of us don't need to be available all the time throw while smaller planets are likely to have a team as large as well so 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 as a fast track to burn out we
can create more sustainable communities if we're nice to respect everyone maintainers at the time of the conversation yes assholes always exist but a majority of contributors come near project with good intentions 1 of the most important things to remember as a maintainer it's not review before you've had your morning coffee you're like me were very grumpy before coffee
and you maybe haven't even recover the nightmares you have for I have personally understand inclusions when I review pull requests before having coffee often it's more likely all be sure the user and dismissed the pull request without a proper review take the time to take care of yourself before reviewing polar contributors will feel more welcome and more have to put up the crabbiness 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 grab beer as he talked about earlier employing online
communication tactics is the best way to interact with contributors you probably should employ online communication methods in all areas of your life or an hour just talking about open source using nonviolent communication will keep the conversation open remember that remember that as a maintainer or contributor of a project you set that tone of the conversation recently had a situation on the rails project were issued are closed quickly without a conversation is of course resulted in the contributor getting defensive because we weren't listening to them as in the time to respond to the contributor and let them know that I understood that how they felt and I asked what solutions to work for them is immediately she's how the conversation is I mean in a way that we we're able to talk about solutions this doesn't mean the contributor is gonna get exactly what they want where there were going to fix the issue but they no longer feel that the problem is there were ignored or dismissed as a
maintainer you can show you can show respect that the show let you respected contributors 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 a conduct benefit everyone people from underrepresented groups are more likely to feel comfortable and welcome contributing to your project if you want a code of conduct and ensure that all maintainers and contributors tree each other with respect maintainers
can use get have provided tools to signal their community is healthy and welcoming a great
feature that could have added a few months ago is the 1st time in 2 years badge This badge clearly indicates to readers a new to your project we see this badge give back into we're a little extra time to be a little extra helpful when I see this battling to take the time to come to congratulate the contributor on the 1st pull request as a maintainer or else I want contributors to have a good experience and letting them know that I appreciate the time they put into rails especially as 1st time engineers building more likely to contribute again in the future another again to low was rolled out recently to everyone is the community profile the community profiled
tool is a tool that shows that has recommended standards for well for creating a welcoming sustainable open-source community the community profile is located on the repository insights tab building called community the new profile page will show you 6 items that make healthy open-source project a description a README code of conduct contributing guidelines a license an issue and PR templates each of these items will help make your project more approachable and sustainable if the community profile is not complete get help provides a wizard prior to help you add the missing items like the code of conduct or picking a license that works for you in your project we talked a
lot about how maintainers can build better communities all of this is to help contributors to feel welcome inspired the goal is to make vulnerability bearable for contributors now the way is that contributors can find healthy open-source communities where they know their contributions will be welcome when the easiest way is to find a project to contribute to is to look at the tools we use every day the Mg that's still looking at file for ideas of projects that might need your help That's how I up into a new many profilers contributed the tools that you use because that's really the 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 1st the user a great when a finite community a project you want to be part of it is spent some time observing the behavior of the maintainer or other contributors
1st make sure the product is active active projects have reason commits look in the top on their repository to see when the last commit was projects the active will help pull requests merged or issues close the last few days to months my 1st open-source contribution was for a project had been long abandoned and 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 abandon projects you can often take over maintaining the project or open a PR with the expectation that it will get merged don't open an issue that asks is this still maintain especially when it's very obviously not maintained once you show the product is active
and accepting new new contributions 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 tree contributors are they kind of or dismissive today to questions go unanswered or word may help them get the pull request merged this will help you know what to expect when you open that 1st issue report quest most maintainers are volunteers to being unresponsive doesn't mean they're route is busier burnt out but knowing communication style of maintainers upfront can help you be more prepared when you open that 1st issue of just as much as maintainers are volunteers an open source Europe volunteer to you don't have to work for free for assholes if maintain other contributors are respectful of you time it's OK to say no and go work on other
open-source projects that their projects
that I have used a pass in applications that I wouldn't contribute to because it didn't think the maintainers treated people aware that I want to be treated I don't wanna have to interact with them in order to get my butt fixed and then just feel like shit all the time because they're rude to me there is no requirement they voluntarily work on open source projects were maintainers or contributors are read to you a big part of into open source is learning how to accept rejection it's really demoralizing a lot harder poor quest accepted but often maintainers have a vision for their projects and that's a big reason why pull requests are accepted or rejected I have many pull requests rejected and I know that it's not fun but don't take their rejection personally it's all part of intruding open source as for mice and how to do better next time and apply that your future work what you do find a community in projects to they wanna contribute to be as respectful as you want the maintainers to treat you hang about an open source project is really frustrating but maintaining a product is hard to most maintainers are volunteers so while the majority of this talk was about how maintainers can do better contributors can do better to tree maintenance the way you wanna be treated if you were making there are a ton
of resources to help contributors and maintainers have a better experience and build more sustainable open-source communities 1st time only dot com your 1st pr out they have died and code triage dot com help new contributors find projects that need help actively seeking out you nuke contributions source that guide is written by my lovely colleagues a get out and it's a resource for contributors and maintainers with ideas about building world more welcoming communities finding your 1st full request and implementing open-source your job open source isn't about writing code
source is really about people are insecurities interactions are unbearable vulnerability the thought of entering 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 so that source sustainable and inspirational instead of paralyzing and toxic we can do this by mentoring asking for help when we need it and demanding nearly all treat each other with respect let's build a world where instead of ending up on the ending up on that island burning out for maintaining projects alone we get a woman bright minds and share ideas in a healthy sustainable community the benefits are and minus building a better community will attract more contributors that this this makes open open-source community is more stable and sustainable maintainers intruders are less likely to burn out because there were killed the share of the burden of intruding with less demand on their time and more emotional support let's spilled open source communities were contribute where less contributors experienced dread when
contributing because they're vulnerable afraid and working 2 years experience that high because they
were inspired by the vulnerability to build something amazing for your project 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 never contributed to open source are inspired to move past the momma ability and contribute I hope that everyone will respect each other and recognize the vulnerability everyone has to overcome to contribute to open source the job during these communities doesn't lie solely on 1 maintainer 1 contributor or 1 project shoulders the responsibilities of all of our to build the CUNY want where there were a contributor maintainer or user together we can make sure open-source thrives by building well scene will communities together we can make the unbearable ability of open-source terrible until the so if anyone has questions of thing that have time waiting to enter time for that and afterwords I have stickers from get out so if you have a of stickers have more about 5 minutes of that questions that was the question is
how much time they spend triaging reviewing and other things so I would say that since join arose him in February I spend less time writing software for more time triaging and pull request urging I don't know exactly how many hours they spend his like some we said a worker at all and some weeks I spend more time probably but I think maybe 5 I thought I should spend more time on it is really what I'm getting I and feel good as the time because we are like the issues trackers same but that's why all of you need become intruders arouse the you can join the party and then we can i'd have will never have enough 0 it's fine you cannot help me tragedies I don't know is a good answer your question answering so I I talk about all and how like intruders move users moved to contributors and their maintainers and but I also talked about how Wells has a lot of open issues and there's it seem like maybe were not moving that final around a lot and we know how we can improve that final I think that rails is a hard example for for that because it's such a complicated could base I think 1 so I think there are things we can do better we can we can Mark issues that they're using more often we don't really do the job of that having the compare more new contributors I think we can I think you do a better job of explaining how we figured bugs out because I think there's a lot of people who think that we honor roll squirting like magic unicorns you understand roles internals but it is still takes us light hours to figure out problems and has to and if we talk more about that in a various seemed like Richard seems when he like does his blog post about ID but a thing and like they're really did we should do more of that to let everyone everyone like everyone who spends time investigating bugs and was 1st in the great of we on I say that is me too I should do this I have it would be great if we all wrote more about finding those problems and solving them is sometimes they're not sometimes they are really hard and sometimes they're just all I knew that like this was in this gender like this is how to make a scripts to test in here's how to bisect and that's high that's most of time how you figure it out yeah but the bisect best will ever that answer questions effect on any hands but I'll be around you can ask me questions I have stickers and thank you the home