Transcript:

So today I want to talk about pull requests pull requests. Yeah. So on GitHub, there's issues. Every repository has issues. It's a little tab. You can submit bugs and stuff feature requests, whatever and then there's the pull request Tab and there's a little notification next to each little Tab and GitHub that tells you the amount.

In there so issues is always way higher than pull requests. There are more issues than there are pull requests something that's as a maintainer now for a decent sized project. Like I've maintained products before I still do but live where is definitely the biggest one and there are overwhelmingly more issues than there are pull request.

And as a maintainer pull request help a lot a lot more than issues do issues health and I try to be grateful for every contribution no matter what it is and I consider an issue submission a contribution. So I'm thankful for all of it, but pull requests are exponentially more helpful because well you're pitching in I don't have to do the work or you know, all of it.

So pull requests are really nice. What do I want to talk about pull request? Well, I think I want to talk to my past self. And my past self never really submit pull requests occasionally, I would I got into pull requesting to the laravel core. I think it started with a document may be a comment fix or a doc fix or something and I pull requested it and to my surprise Taylor accepted it now as maintainer.

I know how helpful little typo put PR is R. I love them. They're great. I love it. I see a little PR I can grok exactly what it is. It improves the framework. I hit merge done good to go. Um, if any part of you thinks that that's somehow below anything or anyone don't think that submit them no matter how small.

But anyway, so started submitting a laravel course small things and had decent success getting them merged I guess and that was kind of my foray into open source contributions outside of little ones here and there but I never really did a decent. Well, I take that back. I did I did submit a decent-sized feature one time but that's not the point of this the point of this is that I for a long time thought that submitting a PR well one it's a lot of work.

So it takes, you know, there's some tech overhead. You have to know how to like Fork something pull it down locally use it in a project, you know, make sure it works and all that but there's a lot of emotional things like, you know, just maybe you have imposter syndrome. You feel like you're not worthy.

You feel like you're not going to be able to do an implementation. That looks good. You don't want you don't want to look bad. Who knows what? So I'm here to tell you to submit pull requests if you can and if you're willing pull requests are super helpful, and as a maintainer, this is the message I want to tell people is contribute no matter what your level of skill no matter what your level of know how anything just contribute.

I love it when people contribute you can submit a with PR that's just maybe a handful of code changes its incomplete but it's a whip and you can say hey I got this started. Can you help out? You know, can you help me get to the finish line? I will absolutely do that. Another thing that's worth mentioning kind of a caveat is that you should make sure that it's something that needs to be that that's like is wanted that's warranted by the the grand poobah whoever that is in the repository and for live where it's me making sure that it's something I would want in the core or would that we all want whatever.

Before you do all the work, that's the only reason it's not even like annoying to close a pull request or anything. It just hurts me when I get a pull request that somebody really poured a lot of time and effort into and it's something that isn't part of the vision for the framework and I have to deny it or something like that doesn't feel good.

And I try not to do that. I try to work with the person change it, you know, whatever make it rescue some value out of it, but unfortunately, I also try not to let my own like emotions of trying to be a. Generous person in change the framework, you know, I want to make sure that the framework is good on its you know, like, you know what I'm saying?

So pull requests submit them early and often as maintainer. Like I said, I appreciate when a poor request is submitted even when it's half finished and I try to pitch in so when I get a pull request. If it's something that's warranted something that I want or that you know has been talked about in an issue beforehand.

I glanced through it. I look through and I might submit some comments. But really I don't think of it like a code review like it's not like a code review for a co-worker or something that I'm doing. I'm I'm going to do work. You know, I'm not gonna I'm not going to write a ton of if it's something that that you're really pushing hard for and I don't really want.

Then maybe I'll do that. Like I think I've done that once where I'm like, okay, you really want I think it was for better phpunit. Somebody's really want some feature in there and it's just going to add work for me. I don't even think it's necessary but it won't harm the package and they really wanted in there.

So I'm like, all right, you can do it. You got to do all the work though, like and you and this pull request has to be good before I merge it. So I'll comment on little lines like well, what about this? You should do this formatting. Why is this space in here? You know? Why? Why did you choose this instead of this stuff like that?

But like for Livewire in general I get a pull request and I'm not nitpicking like that. I might so I can actually sometimes it doesn't work. But a lot of times I'll check out that branch. Locally and I'll contribute to the pull request myself. So it'll be kind of a teamwork thing like you submit stuff and then I'll make a bunch of edits and and you know submit them back comment on the pull request.

We'll talk about it. We'll work together on it. Sometimes I just merge a pull request and then I take it over from their Taylor. Does that that's something I saw Taylor do he does that a lot? Like if it's he rarely Just Hits merge and then leaves it into core he messes with it. He cleans it up. He makes it his own.

And so I do that if you submit something I try to I also try to make sure you get credit. So like sometimes it's easier for me to just like wipe a pull request and do it myself. It's funny, but that's actually a somewhat common occurrence, but I try not to do that ever. I don't think I think maybe once I did in the beginning and it because of some weird issues and and that person didn't get credit.

We talked it over and it was okay, but I try to give the person who started the pull request. Credit give credit where credit is due type thing and I will work hard to make sure that you show up as the contributor for this thing and that you could contribution credit and all that stuff. So anyway submit pull requests, please please early and often submit them if there's something in the framework you want.

You know that mean talk about it. Make sure we want it to be, you know, first submit an issue proposed it I'll try to get back to you and then submit a pull request. I think that's all I have to say on that. Yeah, so go forth submit things contribute. I'm happy to help out and pitch in we're working together on this also.

No, shame. No shame in Bad Code. No shame in whatever. I totally understand code is written in a context and I have lots of. Less than ideal code written in less-than-ideal contexts, and I understand that. So there you go. Thanks. See ya.