Lessons learned from maintaining open-source Python projects
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 |
| |
| Title of Series | ||
| Number of Parts | 131 | |
| Author | ||
| License | CC Attribution - NonCommercial - 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/69470 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Open sourceOrdinary differential equationSoftware maintenanceSlide ruleOpen sourceSpacetimeInteractive televisionProjective planeRight angleComputer animationLecture/Conference
00:33
Computing platformData storage deviceSoftwarePeer-to-peerInheritance (object-oriented programming)Open sourceSoftware maintenanceData managementLink (knot theory)YouTubeVideoconferencingSpacetimeProcess (computing)Generic programmingVirtual realitySoftware testingMachine visionIntegrated development environmentContinuous integrationBoilerplate (text)Revision controlInformationTelecommunicationContext awarenessElectronic program guideStapeldateiSoftware bugSoftware maintenanceComputer fileSpeech synthesisProcess (computing)Different (Kate Ryan album)Projective planeCASE <Informatik>CodeHome pageComputer iconPhysical lawDependent and independent variablesTelecommunicationElectronic mailing listContext awarenessToken ringEmailSource codeSoftware bugCondition numberVideo gameTask (computing)Multiplication signTraffic reportingOpen sourceIntegrated development environmentMereologyRule of inferenceVirtualizationPoint (geometry)Thermal conductivityAuthorizationTemplate (C++)Repository (publishing)Sheaf (mathematics)BuildingInformation1 (number)Inheritance (object-oriented programming)BitExpected valueWordOperator (mathematics)Disk read-and-write headMedical imagingPlastikkarteOnline chatNear-ringSoftware testingComputer animation
08:07
Computer-generated imageryComputer fileRepository (publishing)Integrated development environmentRevision controlError messageTemplate (C++)InformationSoftware bugCore dumpSoftware maintenanceVirtual realityCache (computing)Fast Fourier transformSoftware testingCategory of beingFeedbackTerm (mathematics)Identity managementOrdinary differential equationElectronic program guideMathematicsInterface (computing)Extension (kinesiology)Function (mathematics)Condition numberWritingData typeCodeWeb pageSoftware repositoryCloningGroup actionState of matterGreen's functionCurve fittingHecke operatorMobile appSoftware maintenanceInformationCodeTraffic reportingProjective planeRule of inferenceComputer architectureGreen computingThumbnailCore dumpCodecProgramming paradigmLine (geometry)Right angleFlow separationWeb pagePhysical systemRoundness (object)Uniform resource locatorIntegrated development environmentDependent and independent variablesCoefficient of determinationSoftware testingBitError messageComputer configurationEmailMathematicsControl flowMultiplication sign2 (number)Suite (music)Video gameRevision controlContext awarenessOpen sourceMaxima and minimaPlug-in (computing)Template (C++)State of matterSystem callSheaf (mathematics)Logic gateTask (computing)Large eddy simulationComputer animation
15:40
Group actionData managementCache (computing)Hecke operatorRevision controlDecision tree learningPressureFeedbackLoop (music)Receiver operating characteristicStatisticsReading (process)MereologySystem callWeb pageElectronic program guideConfiguration spaceFAQInformationInterface (computing)Module (mathematics)Plug-in (computing)TopostheorieStandard deviationCoding theoryExecution unitCodeSynchronizationHacker (term)Stack (abstract data type)Buffer overflowServer (computing)Software maintenanceVideoconferencingArchitectureDecision theoryHorizonFile formatMultiplication signSoftware maintenanceProjective planeSynchronizationFeedbackMathematicsWebsiteTerm (mathematics)CASE <Informatik>Decision theoryEmailDifferent (Kate Ryan album)Differenz <Mathematik>MereologyRepository (publishing)Analytic continuationHorizonIntegrated development environmentBitProcess (computing)Software testingCodeTelecommunicationComputer architectureRevision controlSoftware developerOpen sourceGoodness of fitRule of inferenceProduct (business)Expected valueForceVideo gameServer (computing)CodeVideoconferencingStandard deviationSystem callLibrary (computing)Stress (mechanics)Arithmetic meanComputer animation
23:14
FreewareHorizonRevision controlOpen sourceSoftware maintenanceProjective planeOpen sourceSoftware developerWebsiteMultiplication signComputer animation
23:59
Basis <Mathematik>Reading (process)CodeSoftware maintenanceElectric currentFlagWebsiteSide channel attackBit rateCASE <Informatik>Software maintenanceProjective planeJava appletCodeSoftware testingMultiplication signCuboidPosition operatorLibrary (computing)Term (mathematics)Coefficient of determinationFormal languageProcess (computing)Web pageIntegrated development environmentRing (mathematics)MereologyCurveBasis <Mathematik>Open sourceEvent horizonOrder (biology)Online helpMathematicsSoftware bugPhysicalismComputer animation
Transcript: English(auto-generated)
00:04
Thank you. Thank you everyone for coming So my goal here today is to teach you some tips and tricks more or less of stuff I learned when I was both maintaining and contributing to open source project So hopefully what you learn here today will be helpful for making your Interaction with the open source a much happier space and maybe one day even become a maintainer
00:25
Okay, so let's start with who am I so I'm Bernad Gabor I work at Bloomberg as the slide my giveaway in the bottom right corner. I currently live in Los Angeles But I'm originally from Transylvania for those who you don't know. It's that little part of Romania there in the corner and
00:44
More importantly for this package or this talk I'm an open source contributor under that github handle And I primarily am a member of the Python packaging authority I author slash maintain these virtual MP packs build packages, but I mean in a lot more
01:02
Packages as you can see there Probably you heard about like talks or people that three to main some of them bigger ones Okay, oh, I don't want to jump over that one So I'm also more importantly parents to to your check terrier still can junior and I will call them on occasionally in the top
01:20
Just to lighten up a bit the mood Okay, so Let's start with the definition. So what is a maintainer? Well, if you look it up on dictionary.com you kind of like see this long-winded explanation But I think what's more relevant for our talk is probably the second one namely this part of it keep an appropriate condition operation
01:41
Job of the maintainer is poorly this one More importantly what is not a maintainer at least in my opinion It is not the guy who adds features for you to the project It is definitely not the guy who fixed it issues for you for the project However, most maintainers occasionally do take on this mental and had Kind of like heads to but that's near no, that's not their primary job
02:03
So to say that's more like they do that because they enjoy it rather than because they should do it Okay so Imagine you wrote your greatest package of the world and you want to like make it Open-source now and you want to publish it the first thing your job as a maintainer of that package is to actually make sure that it is discoverable and
02:24
The information is available for the users on how and when to use it What this means if you publish it, for example the pipe AI you definitely should use this kind of like lovely information inside the your piper check the tunnel file namely Documentation home page release notes where the source code is and where they should submit the issue trackers
02:44
If you use this lovely tokens for pipe AI you can see on this example You're gonna get lovely icons on the pipe AI project showing exactly for the user where they should direct their Probably tanks, but also their anger towards, okay
03:01
so Another job of you is actually make sure that the project is easy to consume What this means that's mostly and that's kind of like kind of be maybe a recurring Thought throughout this talk is follow the law of least surprises Everything should basically be there and work as the user would expect it So in case of the publishing your package means it should be installable through peep
03:25
Even for Conda if you want to make bonus points for the data science folks and also do a make sure that the code is Available usually via github you can also do gitlab But that's kind of like violate this principle because let's face it 90% of the project leaves on github That's where probably people will search for your code anyways
03:44
Okay now another important task for you as a maintainer would be to actually send the ground rules How people should interact with your project this means that you should definitely define a code of conduct This can be a smart markdown down markdown file inside your github project as you can see here
04:00
We kind of like just roughly outline. What should be the expectation this can come handy If someone comes angrily with pitchforks at your issue tracker you have at least something to point of them Why and how you dealt with them, okay? so Now this is another very important test for a maintainer You are the one that actually has to triage incoming bug reports
04:22
Your job is to make sure that when the user reports a problem you are the deciding authority Is that actually a bug or maybe it's a feature just they don't know about it Or maybe they're just using the package incorrectly or all three at the same time, so You will spend a lot of your time actually doing this now to make your life easier and the life of the
04:44
People coming to your project easier you should definitely use templates for the issues like you can see for example here for github You can create some template reports And then when the user wants to open issue they are kindly guided which and how they should submit their Issue or feature request for example you can see here for an issue
05:03
They kind of like have a we section where you have to complete the information that you ask for them So you can actually troubleshoot and answer their questions Okay, now I See feel at this point. I should probably mention about Communication is deceptively hard and if you want to watch a longer session of this you can see net bachelor's a great keynote from last
05:25
year's pikons Mainly The key takeaway is that we all have different communication styles we all communicate differently for example if I respond to you with four Short words that doesn't necessarily mean that I'm angry at you it easily could be just that and maybe just short word or succeed to the point rather than
05:44
Say a longer in the response to that. Okay, so keep that in mind when you're communicating and We think communication is even harder because when you write something down in issue tracker or on Chat or wherever you lose a lot of context also It also means that you don't have the exclusive attention of the person that you're speaking with which basically just translate that
06:05
Maybe the person is answering you like this fellow here richly dealing with 20 other things And maybe they have 15 seconds in between them like okay. Let me quickly look at this issue and answer. What's about it, okay? So yeah, just keep that in mind But in general kind of like the key takeaway is that be polite and patient
06:25
okay, when you're communicating on a for open-source project with someone both as a maintainer or as the one reporting the issue Remember, this is an open-source project. Nobody gets paid so you should treat the communication accordingly
06:42
Whenever in doubt always give a benefit of doubt You remember just because something comes across as rude might be just a difference in communication styles and Kind of like a bonus tip always refrain from tagging people. Yes, you should not take the maintainer most maintainers have their Subscribed to their own project so they're gonna get an email about it
07:02
If you just tag them you're just gonna come so process. Hey, I'm entitled respond me now I don't have time for you to get back to me However, if I actually don't respond within a week it is fine to tag me because then maybe a life just went by and I missed It and I didn't notice it but don't open an issue and then in the five minutes later tag me that hey
07:22
Tell me what's happening Okay so now If you are a user and you're creating a bug reports some tips for you to have less frictionless Communication and more success in it always start first searching if there's already an issue for it
07:40
You don't have to open three different issues for the same problem bonus points if you can create a docker image reproducing the issue because this makes that I can very easily produce it and if I Make a fix for it. I can easily test it actually fixed it or me It doesn't work for your use case However, if it that's not possible at least do create some short reproducible Ideally in a github repository that I can easily clone to actually test it that what you're reporting is actually happening
08:07
That being said always fill out those kind of like template You definitely should always provide what environment you're running on how you install the package You should would be surprised how many times people report issues that are related to downstream repackages
08:22
For example, if you are you're on Ubuntu and you start the package by using app get probably the issue could be that The packaging downstream is broken rather than the project is broken And always post full-stake test error nothing angers me more than when I someone post the last two lines of a stack trace and I'm like
08:41
I don't know. I mean I want the entire picture so I can actually Understand what's happening? Okay But generally speaking when in doubt It's never it's always better to provide more information than less because the more information you provide the better context I have the more likely I'll be able to answer your question and will not have to have two three rounds of like hey
09:02
Can you provide me this information and that information just so that we kind of like and get to a solution? Okay, so back for maintainer the kind of like responsibilities Your responsibility also to grow incoming feature request what this means you definitely needs to look at when someone asks for a feature and
09:22
Option a you say them. Yeah, great idea We should do this do this before you open a pull request because you're gonna feel a lot less Engrieved when I close it that we will not do this Okay, so first started an issue if I say that hey you can go for it Great, then we can open the pull request for the actual feature request
09:41
But it's also a maintainer's responsibility to actually say no Remember kind of like the puppy paradigm here When you come to me with a great feature that will be great for everyone I don't just look at the great feature and its initial cuteness that whoo great for everyone I also have to consider all the problems I will have that remember that puppy will need to be maintained for the next 20 years
10:03
So it's my responsibility to then take it to the vet give it food clean up after it when it Has inevitably a big P in the middle of the room. So I need to consider all that So if I say no, I'm not saying no because I don't like you I'm saying no because I looked at the plus and the minus and I decided I don't want to deal with the entire package as a
10:22
Whole but maybe it's a really cute dog and I'm gonna be like, yeah, of course, let's do it. Okay so When you're feeling for future request as a user first read the documentation, maybe it's already there It's gonna save us everyone a bit of time second If in doubt open a discussion first github has this great feature now this when you can actually open
10:44
Discussions rather than like questions rather than the Issues directly there we can kind of like more formally this or informally discuss about hey, it's a good idea Maybe how we should fix it. Maybe there's already a solution of work around rather than have to create that Also, finally always indicate if you're willing to actually do the work if you come along and I want this great feature
11:05
But I'm not willing to do it That's gonna be probably More likely I'm gonna say no to that because if I have to spend a week to do it or no one else is willing To do it. It's like yeah a great idea, but it's not really so If you're doing willing to do work, it's always gonna make things go a lot further
11:22
Okay Now another feature that you want to see the maintainers always have to do is actually review the pull request You're the kind of like the gatekeeper who has to say like whenever a pull request is done. Hey great. Let's do this Once you merge that the maintainer is the one that actually has to cut the release for it For example here you can see it's on the github release. It's nice information about what has been done
11:44
All is a maintainer is great to always thank your contributor once you merged it You can go back occasionally and say hey this has been released many people appreciate that one Assuming you have the time for all that but generally if you accept the pull request always thank them So they feel appreciated for doing the hard work
12:01
Okay Now also as your desk as a maintainer to ensure that the project doesn't kind of like devolve in mayhem It should have like a nice architecture This is more of an art than exact science But some general rule of thumb I discovered through the years is that make sure the project has the right separation of concerns And when someone opens the pull request they put the right code in the right location kind of
12:25
when adding new code it gives us to say in the appropriate section and For example, if the project has a plug-in system, okay I generally tend to recommend use the plug-in system and Register the plug-in rather than add it as directly to the core This will make sure that kind of like the plug-in system is good enough
12:44
So other people can add this code and it's also great test ground to validate your plug-in system if your project has one of those Okay now If you are maintaining a project always has a release changelog I really don't care if it's just a github release page where people can see what happened or you go more fancy and you add
13:04
It actually in your documentation as here You can see but somewhere show what was happening in those releases So that as the user goes to it can actually see what the change between versions and what actually happened Do they care enough to upgrade or maybe they happy at the older versions? Okay now
13:21
As you can see there's from all this. It's quite a lot of work can keep you busy So it's a great idea to let other people help you out now the downside of Doing this is actually you have to do a lot of work to let other people help you But this is kind of like an investment. It's gonna pay off eventually, but not initially so it's a bit an investment, but
13:43
You always should aim to make easy to contribute to the project this way if one day you had enough and you move on Other people can keep up the mantle more easily and it also means that you're gonna burn out a lot later Which means in essence you're gonna be around a lot longer to actually maintain that project
14:01
So this is not a kind of like wasted effort But you do have to do some things like one of the things you always should write as soon as you open source project Write a short documentation on how to actually contribute to your project So that's people wanting to contribute can kind of like easily pick it up Okay You can get fancier. You can have like if you see or like even a dedicated page in your documentation
14:22
Which a lot more information like architectural consideration and stuff like that But the very least you should provide like for example you see here How to actually set up a dev environment how to run the test suite. That's like kind of like a minimum I would expect from a project. Okay Now it's also your responsibility as the maintainer to make sure the CI is green
14:44
It's nothing more frustrating than wanting to contribute to a project you open a pull request and the entire CI is broken And you're like, well, it wasn't I who broken it Then they never can release it until the CI is green because 99% of the maintainers will not actually merge Breaking CI just because it's not you who broke it. Okay
15:04
another thing that you should also ensure that Making sure that the CI runs daily this way you can actually ensure and set up kind of like an email reminder for failures So this way whenever the CI break you as a maintainer can get notified that hey now something's broken You should check it out so that the users wanting to contribute can actually do that easily
15:24
Another thing that's also very important Make sure the CI is fast the faster a CI get or whenever the CI gets slow It's quite basically discourages contribution if I have to open a PR to your project and it takes half an hour to actually Run the CI
15:40
I'm not gonna wait around for half an hour and I move on me with my life and maybe I forget about it Entirely, so then it's just kind of like we kind of come back a month later that hey actually that's never emerged Why so if the CI fast it's more likely I'm gonna stick around check it out. What's happening cool if there's some failure I'm gonna fix it and in 20 minutes later Everything's good and I can move on with my life. Okay?
16:04
so This is obviously not always possible But at least having a quick feedback loop means that people will more likely follow through and you have a better experience to it Remember your documentation is just as important as your project so please add your documentation to the CI don't make it out of bound and
16:25
Ideally, you can also enable for read the doc's pull request Documentation builds so this way you can actually see if someone updates the documentation how it would look Maybe the formatting is bad and you can provide quicker feedback for them and they can see it quicker, too Okay
16:41
and yeah, and the previous kind of like update about making sure that your CI continues being green Yeah That applies for documentation too for example here on the read the doc's website if you sign in you can actually see if your builds are failing or not and You can set up an email reminder if they do break for that. Okay?
17:01
Generally speaking also, it's a great idea as a maintainer to release often one this encourages smaller leaves So if you break someone you break it in less often to it also encourages contributions to contribute more often because if you I see I can try I make a Contribution and I can try it out in five minutes I'm gonna be much more likely to make another contribution because hey if I want anything changed
17:21
It's gonna be I know it's gonna be a quick feedback loop rather than I need to wait a month later or two months Later, I'm like, okay, so I'm stuck for two months now I know Armin yesterday in the keynote spoke about having like lovely dev builds or whatnot that you can Rust you can link directly to the github issues. That's not for the github repository
17:40
That's not always as easy especially in corporate environments So it's much easier just to let them use that code as quickly as possible. So continuous development or deployment It's a great idea generally So try to do more of that Always define the versioning policy. This is also very important as a maintainer So the users are actually familiar what they should expect when it comes to breaking changes
18:02
What is the deprecation policy for the project stuff like that Also as a maintainer, you should be the one defining the coding standards basically, what is required for a PR to be good for example, you should Require every change to have a test attached to it This is something that your future maintainer self will thank you because
18:23
it means it's less likely that you're gonna break those features going ahead even though it's some work at the time of the PR in the long term it does pay off and Finally every change should have a changelog attached to it Unless it's just like a small change only impacting like the CI or something like that The user should know about it in some way or fashion
18:42
Okay Also your job as a maintainer will be to define what is good enough code quality This is kind of like subjective So it's great to take the emotion out Tools such as originally black now rough or pre commit does a great job at this where basically hey I'm not the one saying your code is bad. The CI say is bad because it's red. Okay, so don't look at me
19:07
So Generally speaking a consistent architecture is better than a perfect slash great one and Generally, remember if you and the maintainer have a disagreement how something should be the maintainer is always right
19:20
That's purely because they are the one that have to look after that for the next three years and not you so again Kind of like ground rules Okay Another thing that I kind of like running to like good naming things is very hard Similarly creating good PR title and body are also very rare. Usually generally don't tend to do a great job at it. So
19:43
You as a maintainer whenever you're merged It's kind of like your job to kind of revert it and make it nice looking and generally I don't think it's a reasonable expectation to enforce users to do that really well And if you do squash merge for example in github It really doesn't matter because you can always correct it before you merge it to look decent enough. Okay
20:03
so Now, how do you actually attract people to contribute to your project? Your issue tracker is a great asking channel. You can also create sync channels to it such as discord servers This is also probably more interesting when your project has a let's say at least a few
20:22
10,000 users because before that probably not gonna have a great traction on it. You should always advertise your project Conference talk like these are great for that just two people know about it and they can maybe try it out and see hey This is great. I want to use it more and also occasionally do check in on the stack overflow and answer some questions and maybe kind of like
20:44
Kindly guide your users to our your issue tracker for the future such questions, but generally remember Just because you have an issue tracker not all the questions will be there and if you want your project to be successful You should also follow these additional channels too and follow up on them and answer them so that the people don't walk away frustrated
21:01
Okay now How to attract maintainers to project this is kind of like the million-dollar question, I don't have a great answer Do I have some things that work better than other things? So if generally if people contribute a few times and their work is high quality invite them to be a co-maintainer They don't have to stick around for six months if they seem good enough. They seem to be good enough standing
21:24
Meaning they are not paid by the Chinese government to hack your project It means generally you should have a great time. You can look at their past contributions and like yeah, they look fine You can invite them to be around. They don't have to be the sole maintainers they can be it's much easier if they are five maintainers on the project because everyone do a bit of it rather than
21:42
Having just you and maybe being very strict about things Okay, so be slightly liberal when handing out these maintainership invites it encourages people to Contribute more because now they are maintainers and I like oh actually care more than if I was just a drive-by contributor And always mentor them if that's possible
22:02
So for example have video calls with them initially can I just explain what it means to be a Maintainer of it give feedback for at least the first few weeks and whatever they do Involve them in the decision-making and them to do a few releases You don't have to be the only one doing the releases and basically make sure you're not in hotbed So they have all the knowledge they need to step in in case you are on a holiday or you decide to move on
22:24
From the project. Okay. Now why do you should become a maintainer? So this is the carrot part of the things So it looks good on your CV It does broaden your horizon because you meet new people and you learn different communication styles that you have to communicate differently with different people
22:41
Also provides you potentially some mentoring experience when you're kind of like mentoring new means Maintainers or contributors you can get some thanks from the people also, it gives you an opportunity to use new technologies Python versions and libraries that maybe you might not have readily available at your workplace and
23:01
Finally, it's also handy source of topic for conference talk such as this one so no longer need to think about what do you what you should you submit about and Finally you can also potentially get paid for it in some way, especially if your project becomes quite successful In this one We do have a few websites and a few sites later where I can say so, yeah
23:22
You can get paid indirectly by your employment if they allow you to do some of the open source development during your work hours Such as my company allows me to do you can have github sponsors You can also use tied lift to get some monthly income for the more popular projects or thanks dev Which is like one-time donations for the similar benefit
23:42
So if you have a mildly successful open source project remember to kind of like try to Get all this you might not necessarily get paid well to make a living out of you on but it's always good to have Like once a month you can take your wife out for a lunch out of what you get from it Okay, and as Samuel said yesterday you can that's the great time to say sorry for it that you spent all that time
24:07
Maintaining that project rather than with her. Okay, so Generally though as a maintainer, you should accept it that this job will never be done There's no such thing that the project is done always Be patient users are really bad at documentation me included whenever I read other documentations
24:25
I miss a lot of things and then I'm like, why do I ask questions? It's obviously on pastry on the documentation. Okay So but generally eat your own dog food. Don't try to take advantage of your position as a maintainer For example, I work off forks. I make PRs like everyone else. I kind of like try to
24:42
Walk the same path. I preach when I say how people should contribute That's an easy way to actually kind of like see if that's working well or not So, how do you become a maintainer? Pick something you actually use On semi-regular basis. This is important because it means you're already kind of familiar with the project and to your kind of like
25:03
Actually get some benefit in making that project better. Okay, so generally I don't Pick a project that you never saw never Maybe you went to the sprint and you first saw at the time and you never use it for any other projects It doesn't work out in the long term. Okay now read the documentation in the detail is step one
25:20
So at least you get familiar what the project wants to do what its many capabilities Then read a few issues and see if you can understand them. What is the problem where the fix could be in the code and then Reach out to the current maintainer and see if your approach is correct to solve that problem or not. And finally This is just really just rings and repeat parts do a few contributions if you stick around for a few weeks
25:44
Ninety-five percent of the project will ask you to be a maintainer Because maintainers are that high in demand kind of not a lot of us walking around So but my recommendation is always always start with an issue and I think an issue is kind of like in this Order that I enumerated here first is improving the documentation
26:03
We maintainers are really bad at writing documentation. Not because we don't know what we're talking about, but the opposite We know too much about the project and we don't know what a new users don't know about it So making changes to documentation is great for a new people add missing tests is also great because no maintainer will say hey
26:21
I have too many tests go away. It's like not happening and Finally adding the features is great bugs are something that I generally tend to Tell people not to do because some bugs can be deceptively hard like you're like, oh this small feature I just need to fix this small bug and you know, five minutes later you rewrote half of the project to actually fix that bug
26:41
So it's not always a great experience to do that one And finally, it's okay. If you decide it's not for you a few weeks of doing this and you're like, hey, actually I don't want to do this anymore. I just want to walk off. That's perfectly fine You shouldn't be say like once you start that you have to finish it Okay. Now one thing to keep in mind is that contributing to an open source project is like starting a new job
27:01
You're gonna be horrible initially. You're like, I have no idea what I'm doing. I have huge imposter syndrome. Nothing makes sense Here but as you persist treat you're gonna get better it's okay if you feel lost It's okay to ask help and kind of like expect the bumpy learning curve what it means You're gonna initially be know nothing what's happening then, you know enough that you're like
27:22
Oh, I actually kind of everything that's happening and then you're gonna realize that you know nothing and Then eventually if you stick around and in my experience, this is usually around five to six months sticking around You're gonna be reached that Happy Nirvana endpoint you're like, yeah, I know everything about this project and I can three in the morning tell what's happening. Okay, so
27:44
You as a maintainer there's nothing more important ensure you can keep doing it and In order to keep doing it. You need to make sure that you prioritize both your mental and physical health No, it's not worth you spending Five hours a day on it if you're gonna burn out in three weeks or in three months or three weeks
28:02
It's much better to maybe just do it one hour Every day or one hour every week if you can then means if you can keep doing it for two or three or five years Okay so And also fine to sometimes just walk away for a few months and say I just need time to up from this and I can Get back out later
28:20
Okay Now, how long should you keep expecting doing this maintaining projects? Well, as long as you enjoy it mostly and Or also as long as you mostly use the tool or library or questions, for example, I had a project I was maintaining back in like 2016 which was written in Java after I no longer use Java for a few years
28:43
I was like probably shouldn't be the guy maintaining it because I have nothing I don't really keep up to date with what's happening In this language, it's totally fine. Just give it someone else and walk off in the sunset. Okay So that was more or less my fast-forwarded
29:00
Encourage you to start contributing to more to projects in a more successful way. Yeah, and thank you for your time