Resurrecting the Dead ![rw-book-cover](https://img.youtube.com/vi/5spuwg-8uAQ/maxresdefault.jpg) ## Metadata - Author: [[YouTube]] - Full Title: Resurrecting the Dead - Category: #articles - Document Tags: [[video-notes]] [[youtube]] - Summary: Resurrecting the Dead - URL: https://www.youtube.com/watch?v=5spuwg-8uAQ Juliette Reinders Folmer: Happy to be here. Right. So we're gonna talk about resurrecting the dead. Tales of an accidental maintainer, and that subtitle is deliberate. There are projects which I created from scratch deliberately, for which I chose to be the the maintainer. This talk is not about those. So what does being an accidental maintainer mean? Well, let's look at some examples of projects for which I became accidental maintainers Requests, PHP Parallel Lint. In both cases, luckily, I was not the only one. These projects were basically at the verge of being abundant or in practice, abandoned just not marked as such. And they did need maintenance. They are being used by millions of people, so someone needed to pick them up, and I just happened to be one of the people who was getting annoyed with it. So how does that happen? Well, generally it starts like this. Somewhere in my ci something is failing because dependency is not working anymore or, or is not ready for the next PHP version, which is often the case. So I submit a patch to fix that, then that patch fails, and I look at the ci, the, the continuous integration, the automated checks, and I realize that the CI is wildly out of date and needs fixing. It's not my patch, which is failing. It's the CI, which is failing. So I then submit 3, 4, 5 patches to fix their ci. Then we get a passing mark, and then the time timer starts and we start waiting and waiting for a maintainer to merge. Sometimes you have a direct line to that maintainer. Requests. so you ping that maintainer and say, can you please merge this? And. Yeah, the, the effect might then be instead of them merging it, that they give you commit rights, which happened. sometimes a lot of people start putting pressure on it. more and more people are saying, can this please be merged? Can you take over? And at some point, you then do take over. Keep in mind this is not ideal. This is how happened last year. Has anyone heard of ? A few people. Remember the name. Look it up after this talk. The short version of it is, it was a state sponsored long-term, two, three year period attack on open source, which if it had succeeded, would've ended up creating a back door in every single Linux server in the world. This is how vulnerable open source is, how vulnerable your dependencies are. When they're depending on volunteer maintainers and if community pressure leads to someone being added as a maintainer when they're, they've not been fully vetted it, this is the risk you run. So the last one of the latest one of the projects I became accidental maintainer of is PHP Code Sniffer. Yes, that happened. Anyone here who's never heard of PHP Code Sniffer? No one. Oh, what a joy. I dunno if I explained what PHP Code Sniffer is. Okay. So yeah, that happened. I, I'd already been contributing for about eight years to the project. I'd earlier in the year 2023, gotten commit rights. I was going to work through some of the backlog with the maintainer. Um, who then became extremely unresponsive and six months later basically told me I'm abandoning it. And then I had a choice what to do. This project is used by millions. There's somewhere between 300,000 and 500,000 thousand dependent projects. It, it is basically too big to fill. And there was nobody else worldwide who was yeah, positioned to take over. I had other plans. I really did, but I did not feel like I had a choice. So how does this happen to look at, to really understand this, we need to look at the lifecycle of projects a little bit. So how do projects start? Well, they start with someone and two creating something. Maybe it is just to experiment with a new technology. Sometimes it is just to solve a problem they have. Um. it's fine if, if it's just, you know, a greenfields project. That's how most started. Then if users adopt it, it matures. It becomes a, a well-rounded project, well used project, and that's a great phase to be in. Then sometimes, you know. Things happen and, and someone doesn't have as much time for the project. It doesn't get, PRs doesn't get merged as often. It, there's not that much maintenance and it's perfectly okay for projects to waver between that second and the third phase, which is basically a mature project and yeah, a waning project. It's okay as long as they're waver. But then sometimes this happens and the project gets abandoned. In reality, most projects go straight from phase one to phase four, and that's okay, but by the time a project has a huge number of dependents, that becomes a lot more problematic, obviously. So what are reasons for abandoning a project? There's really only one reason. Is it coming? Yes. Life happens, and that can take lots of different forms that might be that a parent gets ill and needs caring for, or it might be that you start a family and get kids and that takes a lot of your time, or you change jobs and your job requirements are taking so much of your energy that you don't have the energy to maintain it anymore. There are lots of different reasons, including health reasons, and now I realize that I didn't turn off my alarm. I'm sorry about this. I'd set an alarm to make sure I was here on time. So yeah, those things happened as well. So health reasons can also be one. And, and those of you were, were at Word Camp Europe last year saw me at on stage. Telling you about another project for which I became an accidental maintainer, the composure plugin for code Sniffer and saw me tell you about that we started off, well, the project had two maintainers. I became the third, and that at that point where we were down to two again because the third maintainer had gotten a brain tumor, I'm sorry to say, since then, he's passed away. This July. So this happens, life happens and you don't always control it. The problem with these kind of things, however, is these are not the things you discuss in GitHub issues. So if it hadn't been for the fact that we, as a group of maintainers have of GitHub contact, I would not have known about Robert. I would not have known what was going on. I would not have known about his death. And that is what scares me most. It's not as if you open an issue. By the way, we're looking for a new maintainer. I have a brain tumor. You know, these things are invisible, but they are really important for your dependencies. Another thing I wanna call out is maintainer burnout. This is a real thing. Quite often I see when a project is, you know, a maintainer is at the edge of their abilities to juggle their work and life, and they need to balance that better, they will say, please, I need funding. I need help because I can't juggle it this way. And if I have funding, then I can tone down some of my employed work and I could spend more time on the open source project. Companies only here help. So what they then do is they put people on the project. Most of the time, inexperienced people who've never contributed to the project before will submit low quality prs. Um, the maintainer will then pointedly try to ignore those prs, but community pressure will say, can, can those be merged? Can those be mer? But maintainer note that Codeing these PRs to something mergeable will take. Much longer than doing it themselves. Yeah. But you don't wanna discourage people because you want to grow the community. So community pressure amounts up. The maintainer again says help. And again, more companies start putting people on the project. Yeah. That's the road to maintainer burnout. At some point that, the maintainer will just say it's done. I'm done. So please do not be that company. Balance contributions with funding. So, okay, so your project, your dependency and essential dependency, say WordPress has been abandoned. Now what? Well, initially you will not notice. Because it's not as if the software isn't downloadable anymore. You can still download it. You can still run it. And it will still work for the most part. But slowly over time, more and more cracks in the surface will start becoming visible. Whether it is because a new PHP version comes out, whether it is because the the test can't run anymore on a new PHP unit version, there's always things which mean maintenance is needed. So at some point, you need to take a decision and you need to research that. Can we switch to another dependency? How high would cost be? for a lot of companies, Juliette Reinders Folmer: if you switch from one dependency to another, that dependency is integral in your tech stack. It wouldn't mean bankrupting the company. If that's the case, you have a very, very large unmitigated business risk. Keep that in mind. So sometimes it might actually be cheaper to find a developer who could take over as a maintainer for a project. Even though you might not have that skillset in your company, you might need to hire someone from ex outside to do that, Juliette Reinders Folmer: but that might be cheaper than rebuilding your whole tech stack. So there, there's, there's sometimes options. Sometimes there's an easy alternative. I mean, for Code Sniffer, the alternative would be CS Fixer, but CS Fixer only has capabilities for about one third of the, the things Code Sniffer can do. So it's not a one-on-one replacement. It's an option for some companies, but other companies would have a big problem with it. So, yeah. Now what? So we can try to resurrect, so we can say, okay, we've got someone else we want to make a maintain it, and you can add a new admin to the project. That might be perfectly valuable. But if the project is in a company organization, quite often the company will not allow an outsider to become an admin of a project in their organization. So then you need to transfer the repo, but maybe that needs collaboration that needs permission from the original maintainer to do so. Not everyone is open to that. So. Third option fork the repo not ideal because you lose all the issues. You lose all the prs, you lose all the W, the Wiki, you lose page sites. A lot of URLs will change. This is not an ideal scenario, but it's often what needs to happen and it is what happened with code sniff. it is in for code sniffer, yeah, it is a blessed fork. The original maintainer basically said this is the designated successor, but it still gave a non-ideal starting point for that fork and last option led a die. Now, you may say, ah, that won't happen. You're right. It won't. What will happen is that depending on how big the project is, 20 people or maybe even 80 people will fork the project and now nobody knows where to contribute. And there will be 80 different divergent forks and, and none of them will be the canonical where people will need to contribute. And in a year's time, it's death anyway. So without a blessed fork, without a dedicated successor, without a maintainer who takes over which. Yeah, with the blessing of the previous maintainer, your project will die in the end. And if that happens, your company might have a problem. So let's let have a look at what it means to be a maintainer. I'm just gonna let you read this briefly. Nothing ever just works. There's always something which breaks, whether it is Travis, which stops supporting open source and everything has to move to GitHub actions. Whether it is Composer, which says, oh, plugins now need permission to run. Whether it is a, a new PHP unit version, there's always something, a new PHP version for those people. We use codes never. Have you seen any deprecation notice from PHP eight five? No, you haven't because I fixed them the day they came in, the day they were merged into PHP itself. But the only that is maintaining that is me doing things in the background to make sure you are not hindered by it. So what does maintaining mean? It means keeping things running. It means unblocking other people from being able to contribute to, to your repository, making sure that all the automated checks are running, that nothing in in the repo is hindering people from contributing. Maintaining also means envisioning the future, having a roadmap of where you wanna take the project. That doesn't mean the complete roadmap needs to be public. I have ideas for the next three mergers of Code Sniffer. I've not published those. I've published bits and pieces, which I think I will address in the next six months. Because I don't want to over promise and then disappoint people. If I publish something now, which I know I'm not gonna address until three years in the future, people at some point will say, yeah, but you, you said that what's gonna happen and it's not happening. So, but that doesn't mean I don't think about it. It means, so envisioning the future is something you do, but don't always publicly publicize. But do publicize a bit, give people the bits they can expect in the near future. What It doesn't mean maintaining. Maintaining does not mean bug fixes and enhancements. Those are open for everyone. The, these are the things where new contributors can put their teeth and get their teeth into the project and actually make a difference. These are your entry points for people. You want to grow the contributor base, and the only way to do that is to give people the chance to contribute. It doesn't mean I don't do any bug fixes or features, but I also very deliberately leave things open for others, especially easy pickings, give other people the chance to contribute, grow that contributor base. So, yeah, now you're a maintainer. Now you want to prevent that, that you are gonna have to abandon the project again because, yeah. So you already heard me talking about growing the contributor base, and let's have a look at what are healthy and unhealthy projects. Healthy projects, have a group of maintainers. More than one. Around that a circle of regular contributors, people who are, you know, once a month, once every two months contributing to the project. And then. A, a circle around that with what I call drive by contributors. Occasional contributors who might just contribute once, might contribute once a year. And the, the ideal situation, these circles would have enough people that if a maintainer, For whatever reason, needs to step back for a while because they, they have different work life balance for, for a while. They can move from maintainer to that first circle or even that second circle. And if a drive by contributor suddenly, you know, might be between jobs and has more time, they can move to that second circle so people can move between those circles freely. But that can only happen if you have enough contributors. An unhealthy project looks more like this one maintainer and a few occasional contributors. This is the reality for the vast majority of open source projects, including Code Sniffer. So what we need to do is succession management. We need to line up the next generation of maintainers because a lot of the original open source maintainers are, you know, we're, we're all aging and in 10, 15 years time, a lot of them will reach pension age if we don't start working on succession management and lining up the next generation of maintainers. Now, no matter how much you want projects to continue, they will be abundant in 10, 15 years time. So one of the troubles you see then is that the next generation, they're not stepping up and part of that is because, you know, the financial situation or housing crisis or, there's lots of reasons, but one of the reasons is they're not willing to do it for free, and I can't blame them. So to create succession management. We need to take action, and these are just some of the steps I've identified and please come and talk with me later if you have more ideas. Document the processes, document the expectations, document what can be done. When I started and with Code Sniffer and when I took over the contributing guide was this, now it's this, including a large section about how to contribute without writing code. Because that there's lots of ways to contribute without writing code as well. Activate people to start contributing. Identify candidates for succession. Identify candidates which could become a committer or could become a maintainer. Approach them. Ask whether they're open for coaching. Whether they're willing to consider at some point potentially becoming Juliette Reinders Folmer: a a committer or a maintainer, if they progress well enough. Validate your trust in them. And this is really important. I mean, I mentioned before, but think about Juliette Reinders Folmer: code sniffer. Code Sniffer has an fixer. We literally rewrite the code off 300,000 or more Juliette Reinders Folmer: projects. It is so easy to introduce security vulnerability in 300,000 of the top PHP projects. I have to be really careful giving someone else commit rights because I realize that risk and I want to avoid that situation ever occurring. Once you've validated your trust, promote people, and yes, to go through this whole process, you need funding because coaching people reviewing code is much more time intensive and, and costs more time, more energy than just doing it yourself. But it is necessary to open up the project for a future. I will come back to funding in a minute. One of the things there is also make sure there's someone else to have who has the keys to the castle. One of the things I did with Code Sniffer was create a dedicated organization, and luckily I kind of already have that organization and I just moved Code Sniffer in there. But having a separate organization, not a company organization, not your personal account, means you can get a second owner assigned to that organization. If on your personal account you can't add a second owner of repos, you can add commiters, but not maintainers. So having a separate organization helps with that. Other things making sure other maintainers have access to packages, making sure they have access to potential domains which have been registered. If I die, we would be able to change the DNS or get access to the, the funding in the open collective. Be assured for Code Sniffer I have made sure there is a second, and it's someone who's silent in the background, but someone who I've worked with for about, well, 13, 14 years, and who I trust implicitly. So if something would happen, I, I've made sure those key keys to the castle are there, but a lot of projects don't have this, and that is something which should worry you. So things I've learned along the way. Yeah. Read this. Yeah. Funding is not optional. It funding is not marketing budget. Funding is part of your IT budget. If you rely on open source and that open source going away would have a huge impact in costs and work on your company. You need to fund open source, and I'm not looking at any of you as individuals. I'm looking at each of you as ambassadors. To go back to the companies you work for and get this message into the skulls of the directors of the company to realize if you rely on open source, you need to fund open source and not just the most obvious primary dependence. No all of your dependents, including those you forget about because there is a maintainer paradox here. If something just works, people don't think about it and forget that those projects need funding and if something doesn't work, even if most it's tiny, tiny thing, which doesn't work, and while 95% of the project works, tiny thing that doesn't work, they don't want to fund it because it's not working. So this makes it really insidious to have conversations about funding open source. Have those conversations in the companies you work for, please. That's the, the, the thing to take away from this talk more than anything. So dos which I've learned. Set up funding channels, well enough about that. Have a dedicated organization. I think I've explained why that was necessary. Uh. Expand the contributing guide, also talked about that. Um. Use PRs and protected branches, including for maintainers because it creates transparency and again, it creates another point where people can contribute even if they're not that familiar with the project yet, they can still review PRs even though they don't fully understand them yet. Reviewing PRs will help them train themselves into the project. It will help them learn what this project needs, how it works in the project. So having that transparency is another pathway for people to contribute, aside from also showing that maintainers make themselves accountable too, which I think is important. Expand CI and QA, especially if there's not many people reviewing, especially if you're the sole maintainer. CI is what keeps you honest. So I've added the, the, the silliest things. I've got markdown, linters, I've got broken link checkers. I've got xml validated against XSD files. I as any time I realize something has gone into the code base. Which then turned out to break something, I will try to add something in CI to prevent that for the future. Of course, you can't do that with everything 'cause some of it, you really as a human need the knowledge to understand whether something is correct or not. But anything that can be avoided by automated checks automate it and do it, it'll keep you honest as a maintainer. Signal file labels, like good first issue, help want it, or one of the things I've added needs re investigation. Sometimes you don't know whether something needs addressing or not, but it needs someone to look at it for an hour or two to, and maybe read up on some of the things in the wider field to figure out whether something needs doing and if so, what doesn't mean they have to solve the, the issue. But it gives people, again, a pathway to know where to start contributing. And close quickly. And closing quickly is something which feels really, really, really hard to do. And I still find it painful whenever I do it. But on average, PRs, which are not gonna be accepted in a will generally be closed within a day in any I manage. Don't give people the hope that the PR will be accepted. If you know straight away it will not be. But do compliment a contributor. Do be kind to the contributor and criticize the code. Explain why you're not accepting it and give them possibly a path forward how, how to get to a contribution which would be accepted. So try to coach people in those responses. And that's not easy and I struggle with it every day whenever I do this. But it is something to continuously work on to try to keep the contributor even though you're you are rejecting the contribution. Now lessons learned and, and yeah, this is. Kind of personal. Say no a lot. As I said, close quickly, say no a lot. That also mean feature requests. One of the first thing tickets, which was opened straight after I took oath for Code Sniffer was, oh, we want the baseline. Yeah, I know PHP Stand has a baseline, and I know you love that baseline from PHP stand, but PHP Stand does not have an autofixer . As soon as the autofixer for from Code Sniffer would run, any baseline would be invalidated. So unless you can figure out how to solve that problem, I'm not gonna accept the baseline. Doesn't mean I don't want to accept a baseline, but I need a baseline with that problem solved. Otherwise, I will be inundated with support requests from people who expect a baseline to work one way and it's not working that way. And any time I have to spend in answering support requests for things which I could have predicted isn't working the way people expect it to is time wasted. Half of GitHub contact and, and this may sound weird, but especially with people you're coaching or sometimes just a sparring partner, half of GitHub contact have human contact, have video calls, meet up with people, just have a rant with people over dinner. But half of GitHub contacts. It will keep your perspective. It will, it will keep your perspective clear on the projects you run, and, and it makes sure that you don't have that tunnel vision which is easy to get into if you're a sole maintainer. Stick to your plan. Yes, people will want certain things and you need to make room in your plan for new ideas and, and additional features. That's perfectly fine, but you also need to safeguard that if you have a roadmap of where you want to go, that you're, you will get there and that you don't get distracted by the 20,000 things people randomly put on your plate which would end up, meaning that your plan never gets actioned. So always keep your plan in mind and pace yourself. You cannot do everything at once, so take your time and don't be afraid to say yes, but later. Things I struggle with, and this is again, very personal and, and for every maintainer this will will be different, but these are things I've noticed over the past two years. First of all, slow turnaround on feedback. If a PR comes in, I review within a day, and then I don't hear anything back for three, four weeks, and then they update PR by that time, I am 300 PRs further down the road. I have to completely reach back and re review from the scratch again to regain the context of that PR, regain the context of my earlier feedback, and then evaluate whether the, the update is correct. I can't expect other people to always be fast with their turnaround with their their, yeah, updates at the same time. It really cost me a lot of time, and the longer the period between responses, the longer you will have to wait for my response because I know it's gonna cost me exponentially more time to get back into that PR and, and give you proper feedback again. When is good, good enough. I have a code base which had a lot and lot, a lot of technical debt. I've been reducing that technical debt. Getting a PR, which is helpful, but introduces new technical debt because, for instance, it doesn't have tests, is not something I really want to accept. At the same time, I can't expect other people to have the same standard and, and the same quality of coding as me because they haven't got the same experience as me in this code base. So it, it, finding a balance there when it's good, good enough, is something I struggle with and, and I try and find the right balance and man, if I get it wrong, call me out on it. It's also lonely. There's nobody to, yeah, there's people you sometimes spar with, but in the end, the buck stops with me. And I have to take that responsibility. And the last thing, I dunno, everything. When it's a code base you've created, even though you haven't touched it for a couple of years, when you go back to that code base, it's like, like an old coat you put on. It might, you know, have some, some patches and it, it, it might smell a bit musty and, and old and, and there might be some holes in the pockets, but it's like an old coat with everything about it feels familiar when it's someone else's code base you take over. That's not the same. You might feel that way for parts, which you've worked on, but it's still not the same. So for those curious Code Sniffers, where are we now? Well, the good news is we've had 25 new releases. Since I took over in December 23. 25 in less than two years, and the previous 25 releases took over six years, so we've definitely sped up with the amount of releases and getting things fixed and done. There have been over 850 PRs merged, so there is definitely a lot of movement in the in the repository. Over 60,000 new dependents have been added to the repository. And yeah, when I took over Juliette Reinders Folmer: that we're about 200 million down notes on Composer of yeah, on packages now we're at 330 or something. So this is the kind of scale we're talking. And Composure isn't even the only distribution channel. Unfortunately, I also see funding going down and that's not a good thing. I'm not a hundred percent sure why. I think in part, people see the project is stabilizing. It's doing reasonably well again. And they now think it's no longer necessary. Maybe I, I can't fill in the answers for that, but it, it does worry me because in the end, over 50%, over 60% of the contributions this year, of all the time spent this year on the project is paid by me. And I don't think that's reasonable. Not with a project which has 300,000 to 500,000 dependents and on average in an average month, maybe 60 individuals and companies funding it. there, there's something very wrong with that balance and I dunno how to change it. If you have ideas, please come and find me with at the drinks later. Juliette Reinders Folmer: Please come and talk with me 'cause I need your help. Right, and you heard it here first. I've not done any social media or marketing or PR about it, but I have released Code Sniffer 4.0 last week it's here. The biggest standards relying on code sniffer have already been updated. so hopefully WordPress CS isn't ready Juliette Reinders Folmer: yet, but getting there is work is being done in the background. PHP CS is ready. Extra is ready. PHP compatibility is ready. T is ready. Doctrine is ready. So there's a lot of standards which are already ready or working on getting ready. yeah. It's a big thing. It's a lot of it is cleanup. We got rid of a lot of dead wood, but there are improvements as well. Things like a proper separation between standard out and standard error. So when you pipe things to from standard out, you actually get the output, the report output, and not any error messages or deprecations. There's lots of improvements. Look at the upgrading guides. Look at the change. Look, I'm not gonna talk about the details of four now. I just wanted you to know it's out. So take away from this talk. First of all, know your dependencies. Know your supply chain. Know, identify all the places where you run a risk. That also means, not just those things which are in your composer JSON or in your package JSON from NPM. No. It also means all those action runners you use in, in GitHub actions and in your ci, it also means all those tools you use just, you know, on the off chance but you are using them regularly. Keep track of everything you use, what's open open source, and Juliette Reinders Folmer: start investigating what the maintainer status is of those projects. Know your dependencies, know where your risks are, and start both funding and contributing to those projects. Thank you. Brian Richards: Wow, that's amazing. Okay, we have just maybe time for one or two questions while you think about it. I get to ask first you mentioned closing PRs early if you know that they're not necessarily going to go anywhere. or perhaps if you know that they could, but it's just like, not right now because this is not good work. For people like you who are like, I feel bad shutting people down. Do you have any additional words of encouragement to like bolster their confidence? That it's a kindness to shut those down quickly? Juliette Reinders Folmer: It is a kindness to shut things down early, otherwise you leave people with hope and if you leave people with hope and then shut it down after eight months, that's far more crushing than if you shut it down quickly. It, it still pains me to do it, but I do always try to explain why I am doing it and what the reason is why I'm shutting it down. I, as I say, I struggle Juliette Reinders Folmer: finding the right words, but I, the, one of the latest ones, I got the feedback that, uh. It, they found it rare to find an empathic open source maintainer. So somehow I must do something right in doing this. Yeah. But I closed up PR within an hour of it being pulled. Brian Richards: Yeah. It is a kindness to close PRs that, you know, aren't up to snuff, or if they're like, ah, this is almost here, but it's not quite, and I just need to like. I agree. Shut it down early. If I have submitted a pr I have also had PRs closed quickly on things that I've tried to help. And even the generic feedback like Hey, we're constantly looking for people to help maintain this project. This one doesn't meet the marks, but please keep contributing. is a really empathetic Brian Richards: thing to say to your point. I love that. Okay. We have time for I think one, maybe two questions if they're quick. Does anybody have a question that they'd like to ask? Perfect. Right over here. Question: Thank you for that. you mentioned so there's probably a lot of different dependencies that we use on a day-to-day basis that we have no idea that they need. contributors or that they're not being updated, where can we discover those? And for those that carry probably hundreds of those? Juliette Reinders Folmer: That's a very good question. There's a couple of things for the funding part, which I can help you with. On the one hand, there are projects like Thanks Dev. That's literally Thanks dot dev. but also GitHub sponsors, Juliette Reinders Folmer: which will look at your tech stack. And can tell you, hang on, these projects are all looking for funding and they are in your tech stack. Uh, they're not perfect and they're, they will miss things and sometimes they will point out to things which are dependencies of dependencies of dependencies, which are perfectly valid, but maybe not the ones you wanna fund. so yeah, it's a starting Juliette Reinders Folmer: point. Another one, which is a good one to look at, is tight lift, which also does something like that and often has a form of guaranteed support with it as well. Um, that's a starting point for, for figuring out what to fund. For contributing, i, I have a very simple advice there. Ask. I actually mentioned to get given to change that because that was one of the things I noticed people were looking for contributing guide, not always finding it as easily, but contracting guide, look for one of those does look for good first issues. Look for any help help wanted issues. just look through the issues and see if there's something you can do. When I'm asked for opensource, when I started using opensource, give back was the norm. So if I wanted to ask the question, if I had needed support for a project, I won't only post my question, but I would also look through the forum or whatever main list they used to, yeah, talk about the project and I answer 1, 2, 3 questions because there's always something I know, which someone else doesn't, but there's things I don't know which other people do. So there's always something you can do, and if you are unsure whether contributions are welcome, ask. quite often also encouraging from one of the recommendations if. It is, you know, don't just open a PR with a new feature. Open an issue first so we can discuss, you know, whether it be launched in Code Sniffer or maybe in the side project, whether it is how it should be architect. And I want to prevent people spending a lot of time on something only to be rejected. So I rather have them open an issue so we can discuss it ahead of time and then they have the right direction to create a successful pr. Does that help you? Brian Richards: Wonderful. Okay, we are outside questions on the stage. Because Julia mentioned she could continue hanging around here. She'll be in the after party, so please bring your questions to her, but for now, please give her a round applause. Thank., Resurrecting the Dead, YouTube, 01k9avmqc6skkaqbrwmj5cndd1.