Don't Be A Hero
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Part Number | 7 | |
| Number of Parts | 94 | |
| Author | ||
| License | 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 | |
| Identifiers | 10.5446/30661 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Multiplication signElectronic program guideInternetworkingMathematicsOpen sourceSoftware engineeringEndliche ModelltheorieComputer animationLecture/Conference
00:55
Point (geometry)Data managementSlide ruleMobile appBridging (networking)WhiteboardEndliche ModelltheorieSelf-organizationHacker (term)Set (mathematics)SpacetimeLocal ringElement (mathematics)Open sourceCartesian coordinate systemEvent horizonFreewareBitMultilaterationComputer animation
01:33
Open setInheritance (object-oriented programming)Open sourceComputer animation
02:01
Bit rateMultiplication signMobile appBitComputer animation
02:38
BitSoftware maintenanceDoubling the cubeOpen sourceElement (mathematics)Different (Kate Ryan album)Data storage deviceMusical ensembleExistential quantificationComputer animation
03:06
Context awarenessMusical ensembleDecision theoryProjective planeoutputSoftware bugComputer animation
03:49
Right anglePoint (geometry)NumberSingle-precision floating-point formatComputer animation
04:23
Projective planeSoftware maintenanceFrequencyQuicksortCommitment schemeComputer animation
04:45
Dependent and independent variablesProjective planeQuicksortPoint (geometry)
05:09
Projective planeDependent and independent variablesMultiplication signSoftware maintenanceOnline helpVideo gameComputer animation
06:09
BlogRange (statistics)CodeProjective planeExistenceSoftware maintenanceComputer animation
06:57
Web crawlerOnline helpStrategy gameData recoveryOpen sourceSoftware developerMereologySelf-organizationComputer configurationComputer animation
08:08
Projective planeCollaborationismMereologyCodeData managementComputer animation
08:33
Suite (music)Projective planeLibrary (computing)AreaCartesian coordinate systemMobile appSoftware testingComputer virusElectronic mailing listGroup actionReading (process)EmailComputer animation
09:21
CollaborationismLink (knot theory)FrictionMaxima and minimaLatent heatFile formatCodeOpen sourceProjective planeSoftware maintenanceReading (process)
10:19
Resampling (statistics)Electronic mailing listQuicksortDependent and independent variablesRandomizationTask (computing)
10:48
Online helpProjective planeBridging (networking)Process (computing)Data managementComputer animation
11:13
Process (computing)Projective planeArmElectronic mailing listMathematicsDisk read-and-write headData managementConsistencySet (mathematics)Open sourceChemical equationQuicksortBridging (networking)Pivot elementComputer animation
11:55
TrailMobile appMereologyPhysical systemComputer animation
12:25
Observational studyCodeLaptopSpring (hydrology)EmailElectronic mailing listProjective planeData managementMultiplication signInheritance (object-oriented programming)Musical ensembleSoftware maintenanceComputer animation
13:45
Dependent and independent variablesDecision theoryoutputShared memorySoftware maintenanceProjective planeLibrary (computing)Software developerMathematicsBitSound effectMobile appComputer animation
14:35
Multiplication signTheory of relativityBitLibrary (computing)Software developerMobile appCartesian coordinate systemCurveLink (knot theory)Computer animation
15:24
CodeEmailDependent and independent variablesMereologyCartesian coordinate systemMobile appProjective planeRight angleComputer animation
16:03
Mobile appExpected valueOpen sourceComputer animation
16:35
QuicksortOnline helpProjective planeSpreadsheetWhiteboardEmailMobile appNeuroinformatikSoftware developerProcess (computing)Point (geometry)CodeBuildingElement (mathematics)Coordinate systemDoubling the cubeComputer animation
17:21
Public key certificateBoss CorporationCodeComputer animation
17:44
Software maintenanceObservational studySoftware bugOptical disc driveBitDirection (geometry)Cartesian coordinate systemCodeLibrary (computing)GradientComputer animation
18:33
Game controllerSoftware bugDoubling the cubeComputer animation
19:22
HTTP cookieTable (information)Imperative programmingContext awarenessBridging (networking)Projective planeSoftware maintenance
20:13
Regular graphProjective planeMechanism designMathematicsSurfaceResultantMultiplication signLattice (order)Food energyProcess (computing)Figurate numberTraffic reportingFeedbackWhiteboardContext awarenessScheduling (computing)Right angleQuicksortComputer animation
21:47
Projective planeLink (knot theory)Bridging (networking)Software maintenanceComputer animation
22:30
PasswordMobile appEmailAddress spaceData managementRight angleTrailComputer animation
23:03
Reading (process)Library (computing)Projective planeDot productDimensional analysisOnline helpMathematicsMusical ensembleSoftware maintenanceComputer animation
23:39
CodeRight angleIncidence algebraCellular automatonQuicksortOpen sourceComputer animation
24:01
Lattice (order)Algebraic closureLibrary (computing)Projective planePole (complex analysis)Direction (geometry)CodeFood energyFeedbackSoftware maintenanceQuicksortImplementationComputer animation
25:01
Software maintenanceFeedbackLocal ringMultiplication signVideo gameCycle (graph theory)CodeProjective planeComputer animation
25:26
Open sourceVideo gameProjective planeBand matrixBlogSoftware bugOpen setComputer animation
26:25
Open sourceProcess (computing)Projective planeResonatorOrder (biology)Task (computing)Vector spaceMultiplication signSpacetimeFreewareMereologySound effectQuicksortComputer animation
28:19
Single-precision floating-point formatPoint (geometry)Projective planePlanningSoftware maintenanceGoodness of fitTerm (mathematics)Computer animation
28:45
Projective planeComputer animation
29:08
Lecture/Conference
Transcript: English(auto-generated)
00:14
Welcome to RailsConf. Let's just like start on time, I guess. That'll be exciting.
00:21
My name is Lily Shaleen. My last name is in no way phonetic, so here's a little guide for you. Lily Shaleen, very strange. You can find me on the internet as Lily Albert in all the places. I'm a software engineer at Omada Health where we help people avoid chronic disease by supporting behavior change.
00:41
And I'm really grateful to Omada for covering my flight and my hotel and giving me time off to come to Atlanta and talk to y'all about open source. When I am not thinking about things at Omada, I'm usually thinking about RailsBridge. RailsBridge is an organization that puts on free weekend workshops to help make the Ruby community more diverse.
01:01
We maintain a set of open source curriculums and an event management app that we call BridgeTroll. I'm currently the chair of the board. And when I'm not thinking about Omada or RailsBridge, I'm usually thinking about Double Union, which is a feminist hacker maker space in San Francisco where I'm the CTO. And I maintain our membership application
01:21
and management app. So at some point today, these slides will be at this bit.ly, but they're not there now. Right now it's just linking to, I don't know what it's linking to. So check that out later. So what are we gonna talk about? Three big things. What is a hero in open source?
01:41
How to recover from being a hero in open source? And tips for being a contributor. So what is a hero? I tend to think of heroes in the Ruby community as being a lot like superheroes. Some of them have special abilities that they use to make our lives better.
02:00
Like contributing so much so consistently has got to be some kind of superpower, right? But a lot of heroes are just regular people who started helping out, figured out how to get things done, and who we've come to depend on over time. When you first think of a Ruby hero,
02:21
you think of someone who's up on a pedestal, someone who's a highly visible member of the community. But a lot of our heroes are actually members of the crowd. They're people who maintain gems, who make working on a Rails app so great, and you don't necessarily see them a lot. So, quick confession, I am a little bit of a hero.
02:41
I am the solo maintainer of Double Union's open source membership app, and I do rather a lot of different heroic things for RailsBridge. So this is kind of great sometimes for me. It's pretty great for the community. We have these heroes that do so much stuff and make writing Ruby and Rails apps so wonderful.
03:02
And there are some upsides for the heroes as well. So when something's busted for the Double Union app, or we need a new feature or something, I can swoop in and I have all of the context in the world, and I can help out. And that leaves me feeling all warm and fuzzy, and it's great. It can also be really nice to work by yourself
03:22
because you guys kind of fly solo. You already know where everything is in the app, so you can get things done quickly. I get to make large and small decisions for my projects without necessarily getting other people's input, and I don't have to worry about other people breaking the build or introducing bugs. I pretty much just have to worry about myself
03:40
introducing bugs, which I do. And if you make enough contributions or get involved with the right project, sometimes people do gain some notoriety in the community, right? Like, who doesn't want to be Ruby famous? So, sold, we're all gonna be heroes. Let's do it right now.
04:01
No, sorry, it's not that easy. There are some real downsides to being a hero. And I think the number one reason that having heroes is bad for our community is that despite all of the amazing work they do and how much gets produced,
04:21
every single hero we have is a single point of failure. Silos are really bad and we know that, but they're impossible to avoid if you're the only person working on your project. And if nobody else has commit access, your users might be kind of screwed if you disappear or get eaten by a dinosaur. So, that alone, I think, is a good enough reason
04:41
to stop being a hero. But heroism can also really suck for the maintainer. I've definitely felt trapped by my responsibilities, especially on projects where I'm sort of the only person pushing things forward. If I leave, I worry that the project might fall apart, and then I worry that if I leave and the project falls apart and nobody cares, then what was the point in the first place?
05:01
And then it's just existential dread and everyone's sad. So, how do I get here? I personally am a responsibility sponge. When I join a community, I work on fixing whatever problems I see, and then I end up becoming responsible for the pieces that I fixed. And if you repeat this enough time on any project,
05:23
it's burnout town. So, it just doesn't work to do too much by yourself. I've actually quit RailsBridge twice in the last four years from being overwhelmed and not seeing how I could make it fit in my life. And when we use gems, sometimes the maintainer
05:42
just kind of slows down their contributions, pull requests and issues pile up, and sometimes the maintainer will ask for help and nobody ever comes. And so they sort of keep half maintaining the project. And sometimes they just silently disappear and the users have to fend for themselves and you see an issue that's like, hey, this seems abandoned, what do we do about that?
06:03
So, that quietly is a way that people burn out. But we also have visible members of the community who just rage quit. They just write a blog post about how Ruby totally sucks and they're over it and that's really no good either. One distinction though that I'd like to make
06:21
is that not all prolific contributors are heroes, right? Writing a lot of code doesn't make someone a hero. It's awesome that people get things done. When I think about heroes, there are people who hold projects up by themselves. There are people who are silos, who are necessary for the project's existence.
06:40
And sometimes it happens because the maintainer doesn't want other people's help or doesn't trust other people to actually give contributions, and that's terrible. But I think a more common reason that people become heroes is that they just kind of fall into it by accident. You're bitten by a radioactive spider and now you have 50 stars on GitHub
07:01
and a bunch of users to talk to. So, what can we do to help? What are some strategies for recovery? First off, I think it'd be really great if we paid people to do open source development. I think part of why people are heroes
07:21
is for a lack of resources and we would have more resources if people could actually pay their rent with open source work, if people didn't have to spend their evenings and weekends supporting open source, which then supports lots and lots of businesses making lots and lots of money. One organization I'm super excited about is new
07:40
and it's called Ruby Together. It's a new non-profit trade organization, a 501c6, apparently. And they are supporting the Ruby tools and infrastructure with money donated by individuals and businesses, so you should totally check them out and get your companies to sponsor because they're pretty rad.
08:02
So, for you though, if getting paid to do open source isn't an option for you, what else can you do? So, three big things that I would encourage you to think about are documentation, project management, and recruiting collaborators. Sadly, none of these things is write awesome code,
08:22
but you should totally do that anyway because that's why we're here. A big part of what makes a hero is that they're the only one with the tools to solve the problem. If everybody in Gotham had a Kevlar suit and a Batmobile, they wouldn't need Batman, but things would probably be a lot worse. So, documentation though,
08:42
is one of the ways that you can give people the tools that they need to help. And the first place to start, I think is kind of obvious, your README. So, you shouldn't just include how to use your library or your application, but also how to contribute. How to get the app running and the tests passing,
09:01
where you track your features and bugs, how you'd like to communicate if you use IRC or Slack or you have a mailing list or a Google group, giving people the basics to actually start contributing. And you probably already have some of this stuff in your README, and it can be hard to see what's missing because you already know your project like the back of your hand. So, what you do next is you find someone
09:22
who doesn't know your project. I went through this with double union but not with a hippo, and it was incredibly useful to get some fresh eyes on my README and see what I was missing. Ben Balter of GitHub has a great post about open source collaboration
09:40
that I'll link to in the notes for this. But one thing that stuck out from that to me was this idea of minimizing friction for contributors. So, everything that we're doing here is trying to minimize friction so that people can get involved and you can not be as much of a silo. So, your documentation can help with that a lot. You want to communicate your preferences
10:02
like if you like squashed commits or specific formats for documentation. Letting people know up front so that you're not just nitpicking their pull requests and you can focus on actually doing code review in pull requests can be really helpful because you don't want to disenfranchise people who are excited about your project. The next thing that you need to do is write down everything you do as a maintainer.
10:23
There are probably a lot of things that you do that nobody knows about and nobody can help you do the things that they don't know you do. I actually recently went through this exercise with RailsBridge and I found this long list of random tasks that I'd sort of accrued over the years and a lot of them would be great responsibilities
10:40
for a new contributor but I've just been hogging them because it was way easier. So, once you have this list, you can share it with people and ask for help with some of these things. So, you can be less of a silo and other people can get a better understanding and more invested in your project. I admit I have not actually done this
11:00
with my RailsBridge jobs. This stuff is hard but I'm publicly saying I'm gonna do it on the flight back to San Francisco. So, hold me to that. Next up, project management is hard and that's why people have jobs doing it but unfortunately, we still have to do it. The workflow you use for your project matters.
11:22
When you start off by yourself, you can kind of keep a list of future changes in your head. This unfortunately is very hard for other people to access. So, you start writing things down but the tooling for this is not great. Most of the project management apps kind of assume that people will be consistent and open source projects often have
11:42
completely inconsistent sets of contributors. And so, I do not have a silver bullet for that but you do need to find a balance between sort of your personal preference and then what is accessible to other people. On BridgeTroll, we use Pivotal Tracker to keep track of our upcoming features and we inherited it from the people who started the app
12:02
and it works pretty well because the people who do most of the contributing like Tracker and use it and I have suspicions that it's not helping people get involved because they do have to kind of ask permission to be part of the team so they can hit the start button and then maybe that hurdle is too great but so far nothing else has seemed significantly better
12:21
and Inertia wins, so, eh. On Double Union, we use GitHub for everything which means we can't prioritize anything but we can get creative with tags. And it's great because it's super easy to find but not everybody is looking at GitHub issues proactively. So, what I've found helps is just emailing out the mailing list
12:40
and saying like, hey, these are five issues that it would be great to get some help with and so far it's worked. Like, people have picked up issues and then I know people that I should sort of like try to convince to do more things. Another piece of project management that is critical is the timing that you have when you reply to people's pull requests.
13:00
Mozilla did a study of contributor engagement and they found that if somebody receives a code review within 48 hours, they were exceptionally likely to come back and make more contributions but if someone had to wait longer than seven days, there was almost no chance that they were gonna come back and give another contribution. So, this is obviously challenging
13:20
if you're a solo maintainer because maybe you wanna go camping for three days or four days and now the PR is sitting there but you should totally go camping. You should not like bring your laptop with you and your wifi hotspot so you can respond to pull requests. You really instead want to find other people who can help review those pull requests
13:41
so that you're not the only person doing that. Which brings us to recruitment. How can we actually find like these fabled contributors and co-maintainers to share our responsibilities with people we trust and know will help our project grow and succeed? When you're making big feature decisions
14:01
or just any feature decisions like who do you talk to, hopefully you do get some input from your users talking to people is generally a good idea when you're making changes in the app but it has this wonderful side effect of letting you, helping you find the people who are passionate about your project or maybe just slightly interested and whose opinions you find valuable
14:20
and then you can try to recruit some of those people to help you. When I'm talking to people who use the Double Union app, they're sometimes Rails developers but mostly not. So I have to do a little bit more targeted outreach to potential contributors which is pretty different if your project is a library. If you maintain a library, your users are obviously developers and they're probably Ruby developers which is awesome
14:43
because it means all of your users are potential contributors. But most people do work on apps in their day-to-day lives at work and library development is pretty different from application development. Sarah May actually gave a talk at Nickel City Ruby that I'll link to in the notes called Multitudes where she uses RSpec as an example
15:01
of how different the internals of a library are from its API and so there's a steeper learning curve for application developers when they're working with a library for the first time. So keep in mind that even people who have been professional Rails devs for a while might need a little bit more support as they get started helping with your library
15:20
and that's okay. So all of this can sound pretty painful. Instead of writing code, I'm asking you to do all of this other stuff, this documentation and maybe emailing people. But I actually really don't want you to do this by yourself. I want you to not just become the PM of your project
15:43
but find someone else to share all of these terrible responsibilities with. You want other people to help you with coding and documenting and communicating so that you're not a silo for any part of the application. And when you are recruiting people, it can be scary. If you're working on an app that you're really invested in,
16:01
you don't know if someone's gonna turn out to be evil. Right, like they could be actually evil and try to ruin your app. But it's much more likely I've found that people will just not do anything at all. They'll like show up and talk to you and then disappear. So in open source, I've generally just learned to manage my expectations of everyone
16:22
which means, it has the plus side, I get really excited when anyone does anything. So the bar is kind of low. When you've done recruitment and you've found other people and you have contributors, what can you do to sort of help them grow in your project?
16:42
I first started at Double Union as the membership coordinator which meant that I had like all these spreadsheets and I had to write emails to people and I had to do all of these things that were very obviously good for computers to do. And luckily, I'm a Rails developer and we had a Rails app. So I was like, oh, I will just add features to make my job easier and it was awesome.
17:03
To the point that I was like, hey, what if I never email anyone and I can just focus on writing code and building tools? And so I became, I just worked on that. Somebody else got to be the membership coordinator. It was great. The board of Double Union noticed that I was like working really hard on the app
17:20
and they actually gave me the role of CTO. And I was like, woo, that's awesome. And they gave me a title and a gift certificate for a massage and I was like, that's awesome. But unfortunately, it did somewhat reinforce my heroic tendencies because I'm like, oh, I'm the boss of the code. This is awesome. I'll do everything. But after a year or so of doing that,
17:42
I've now shifted and I'm trying to find someone to be a co-maintainer and I'm trying to build out a team instead of doing everything myself. So you want to help people move from using your application or your library to maybe helping fix bugs to maybe adding a feature
18:03
and then a small, small minority of them maybe could become co-maintainers. There is a funnel, right? And how can you help people move through this funnel? Mozilla in that same study found that showing someone the next bug that they could work on would dramatically improve the odds of them contributing again.
18:21
So just giving people a little bit of direction and encouragement can go a long way. But having other people adding code and reviewing code and maybe things are getting onto master without you seeing them does require you to let go. You might be like me. You might really love being in control of things.
18:41
I really, I know I can get things done quickly, but that just reinforces this silo that I've built for myself. So I try to remind myself that I have to let other people help even if it's slower. And even if sometimes things fall on the ground, even if sometimes things don't go well.
19:01
I would suggest maybe non-critical bugs or features that are not super, super high priority that are simpler can be reserved for new folks and marked as bite-sized in your backlog. Because getting people used to your workflow with smaller things means they'll be more comfortable making larger contributions in the future. One of the things I learned from some folks at Double Union was this amazing phrase,
19:23
don't lick the cookies. I don't know if you've heard of it before. It's the idea that when you're working on a project with someone, if you say you're gonna do a thing and then you don't do it, you have just licked the cookie and then just put it back on the table. And that's really gross.
19:41
So try to not lick the cookies. As a maintainer, it's especially easy because people hear you say, oh, I have an opinion about this thing. And even if you didn't say, I am doing this definitely, they might think, oh, well, Lily's got that. She obviously cares, she'll take care of it. And so it's imperative that I, if I notice that I have licked a cookie,
20:01
to let everybody know, hey, I am not gonna do that thing. I'm definitely not, please take care of it. I can give you context if you need it, but please take it and run. One thing RailsBridge is really good about doing is retros. Retrospectives are kind of regular meetings to look at your process and figure out sort of what's working and what's not.
20:20
And we do this at the end of most workshops. And we get really great feedback from volunteers and participants. And we grow a lot just knowing how the workshop went for people. One thing that we're really bad about is ever doing them in any other context. Like I was volunteering with RailsBridge for like two and a half years before we did any retros whatsoever.
20:42
And like any project, whether it's like your job or a volunteer gig, there's gonna be challenges and there's gonna be inefficiencies. And without a regular mechanism for surfacing those, problems will fester. And things that you could have dealt with really effectively early on will become much bigger deals
21:00
if you don't find out about them early. And so you're gonna lose time and people and energy to problems if you don't surface them. So happy to report now we're doing more retros. So far, mostly as the board, but I have ambitions for many more retros in the future. And I think you should probably go schedule a retro
21:20
with your team, like now-ish, right after this maybe. And if you don't have a team, if you're working on a project by yourself, you can have your own retro. You can sit down and think about, you're just like, what's going well for this project? What do I wanna change? And maybe you could share the results of that publicly. Maybe it could help people know that you do need more help.
21:43
But we don't just want to reflect on what's busted. We also wanna be celebrating people's contributions. I love this. So saying thank you regularly and letting people know how you value them on your project can go a long way.
22:02
So even if it's just someone opening an issue to let me know that there's a typo or a dead link in a RailsBridge curriculum, I thank them either way. I am so grateful that people are helping improve this stuff. And especially as a maintainer of a project or a leader in a project, people are actually looking to you
22:21
to determine how they should behave. And so you can lead people to be more awesome if you're awesome yourself. And just a quick kind of housekeeping thing, just don't hoard the passwords. Just really, if you have an app that you deploy, get a shared email address, get a password manager, have somebody else who can publish your gem, right?
22:41
Because it's like, you're not gonna be around forever. So, sorry. Some more positive things. If you're a new contributor, you should totally do it. And also there's a talk this afternoon all about this. This afternoon, Courtney Ervin is giving a talk in the beginner track and you should totally check it out.
23:01
But here's some suggestions anyway. The docs might suck. The docs will probably suck. The maintainer of the project might not have been to this talk, maybe. But the good news is that you are uniquely qualified to help improve those docs because you do have these fresh eyes. So please help make them better, even though it might seem trivial,
23:21
like to make a text change and open up a pull request that's like, all I did was change the text in the readme to make more sense. That is incredibly useful and you are providing a gift for all future people who are using that library. Another thing about solo projects in particular is that they can be a little weird.
23:42
One person code can just like, not always, it gets quirky, right? Like if you don't have other people sort of contributing and sort of evening out things, then the style can be weird. So that's okay, totally surmountable challenge. One thing I wish that people thinking about contributing to open source knew
24:01
was that you totally don't need permission to open a pull request. If there's an open issue and you want to tackle it, just go for it. You don't have to comment, you can comment on the issue and say like, I'm gonna work on this. But if you're me, you're just not gonna believe them because no one ever does that. But you can open maybe a provisional pull request. You can be like, hey, this is what I was thinking.
24:22
This is the direction I'm going in because it's a lot easier to talk about written code than discuss sort of like a potential implementation of an idea. And if you do open a pull request on a project, the worst thing that could happen is that like, it isn't accepted because somebody else fixed it or the solution wasn't quite what the maintainer was looking for and hopefully they're gonna give you some feedback.
24:40
Or like the worst, worst thing that could happen if it would be the maintainer would be a total tool and like say something really rude and like close your pull request. But the silver lining there is that you know never to use that library again because you don't need to work with jerks because you're awesome. Another idea for contributors is to bring your own mentor
25:02
to the project. Show a coworker or someone at your local Ruby meetup the code that you're working on and get their feedback before submitting the PR. So you know, it's gonna be helpful to get a little feedback first because the maintainer might not have time to be your mentor. And if you can kind of save them the first couple cycles of feedback,
25:22
that's also a huge gift. So here are some general guidelines for life for maybe open source happiness. One thing that I would like all of us to do is take a look at ourselves and ask why we want to do this. If you're currently maintaining a project,
25:42
are you still getting something out of your work? Are you still enjoying maintaining your library? And if you're a prospective contributor, why do you wanna work on open source? If it's out of this vague feeling of obligation, let me just tell you, you don't have to do it. You are not obligated to work on open source.
26:03
Not everybody has the bandwidth. And I think that guilt is a pretty terrible motivator. But some great motivators are like, you use a project and it has a bug and you can fix it. Or you got something out of your project. And you really wanna give back. So if that's the case, please,
26:22
please contribute to open source. Side note, GitHub resumes are bullshit, right? This idea that people have to contribute to open source in order to get jobs at places, just completely, it's really irritating. Not everybody has time to do this. And this kind of practice totally favors people who have a bunch of free time
26:41
on the evenings and weekends to make contributions to open source. And it also has this annoying side effect of people showing up being like, I wanna work on open source. But they don't really wanna work on open source. They wanna get a job and they think that this is one of the prerequisites. So if employers could just stop doing that, that would be really great. Thank you.
27:01
Because this is all optional. You don't have to maintain a project forever. You don't have to contribute to a project forever. You don't have to do open source. But you totally should, because it's totally awesome if you want to. The flip side of how optional it is is that we need accountability. If we're going to make projects sustainable,
27:21
we need to know what happens when someone doesn't do the things they said they would, and this is inevitable. We need a shared vocabulary around accountability so that people know how to talk about it when they slip up and they totally fail to do something, but you don't want them to feel like they're a failure as a person just because they failed to complete a task.
27:42
I think this is one of the things that can be most hard about working on teams. Because as a leader in the RailsBridge community, I know that everyone's a volunteer, and so I feel pretty guilty when somebody misses a deadline and I'm like, hey, that thing you're not getting paid to work on, do you think you could finish it? And so it's very important to sort of be upfront,
28:02
and I think retros can totally come in handy when you have a space that everyone's just expected to be honest. Because part of not being a hero is not fixing things every time they go wrong. It's having a team that can handle failures and sort of keep going. So to recap, silos are bad.
28:23
We don't want people to be single points of failure. They can't stick on projects forever. It's not really, silos aren't good for the community or the users or the maintainers because we need succession planning. We should all assume that we're gonna stop working on a project at some point because we have no idea
28:40
when we might become indisposed, in the short or long term. Teams are awesome. They can help take the burden off of you to do all the things so you can focus on what you're most excited about, which can then take your project to like way more exciting places with less burnout and more unicorns.
29:01
Thank you.