WEBVTT 00:00.000 --> 00:16.120 All right, folks, so today we're talking about pull requests, maintainers will love to review. 00:16.120 --> 00:18.760 So first, maybe let me get a quick shift, Hans. 00:18.760 --> 00:21.800 Who here is a maintainer for an open source project? 00:21.800 --> 00:29.560 All right, who has ever submitted a pull request to a project they don't maintain? 00:29.560 --> 00:32.400 Yeah, almost everybody. 00:32.400 --> 00:37.240 Who is thinking about doing it someday is here to learn? 00:37.240 --> 00:38.520 Nice. 00:38.520 --> 00:42.440 And who has not yet had a chance to raise their hand? 00:42.440 --> 00:45.200 Also, all right, thank you for being here. 00:45.200 --> 00:45.800 Thank you all. 00:45.800 --> 00:50.480 This talk has meant to be interesting and hopefully informative for everybody 00:50.480 --> 00:51.760 no matter when you raise your hand. 00:51.760 --> 00:55.240 So let's get to it. 00:55.240 --> 00:57.240 And I'm going to try to make this interactive. 00:57.280 --> 00:59.800 We'll see if it works in this room. 00:59.800 --> 01:05.600 But when I, you know, we'll see basically I'll ask you folks to participate 01:05.600 --> 01:08.800 and share your ideas throughout the talk and then I will restate them, 01:08.800 --> 01:11.000 but you just need to say them out of for me to hear. 01:13.640 --> 01:16.000 So first, let's get on the same page. 01:16.000 --> 01:18.400 So what is a pull request? 01:18.400 --> 01:21.040 Is it, can anybody raise their hands and throughout a definition? 01:23.800 --> 01:25.000 All right, thank you. 01:25.000 --> 01:34.360 All right, so in a request to integrate one of your comments into a public repo. 01:34.360 --> 01:35.640 All right, let's see. 01:35.640 --> 01:41.560 So I, all right, so here is a pull request in the context of a resource development. 01:41.560 --> 01:48.080 All right, so here is my definition and that this is what it will be going for this presentation. 01:48.080 --> 01:53.680 So a pull request is a presentation of your proposed changes to a project. 01:53.680 --> 01:58.440 So it's a presentation of that request to integrate your comments. 01:58.440 --> 02:01.080 And that's going to be really important. 02:01.080 --> 02:03.440 So why put up a pull request? 02:03.440 --> 02:07.360 You guys have all that at almost. 02:07.360 --> 02:08.840 Anybody want to raise a hand? 02:08.840 --> 02:10.160 All right. 02:10.160 --> 02:14.280 Because something is a project in my view or everyone involved in it. 02:14.280 --> 02:18.640 Yeah, because something is annoying and you want to fix it. 02:18.640 --> 02:19.120 Others. 02:19.800 --> 02:22.480 Yeah. 02:22.480 --> 02:29.600 Yeah, because you want to share something you've done. 02:29.600 --> 02:30.920 Anyone else? 02:30.920 --> 02:31.920 Yeah. 02:31.920 --> 02:35.160 You just fix something. 02:35.160 --> 02:36.160 You just fix something. 02:36.160 --> 02:37.160 All right. 02:37.160 --> 02:38.160 What? 02:38.160 --> 02:39.160 Trying to change one. 02:39.160 --> 02:42.160 If you don't want to have to reach out on the page. 02:42.160 --> 02:49.080 Yeah, you don't want to maintain a forksy, you want to get your changes integrated up stream. 02:49.120 --> 02:50.080 Cool. 02:50.080 --> 02:51.240 So those are some great reasons. 02:51.240 --> 02:56.560 I'm going to give kind of a first first pass reason as you want to get your changes merged. 02:56.560 --> 02:57.560 Right? 02:57.560 --> 03:01.800 If you submit a pull request and it doesn't get merged, usually you didn't get to whatever 03:01.800 --> 03:04.920 you were trying to do. 03:04.920 --> 03:09.440 But then yes, there's a bunch of different reasons why you might be trying to get your 03:09.440 --> 03:10.440 changes merged. 03:10.440 --> 03:16.280 So maybe as folks were saying, the fix initiative that's bugging you, maybe you just 03:16.280 --> 03:22.280 think it's like really cool to be part of an open source community and you want to contribute. 03:22.280 --> 03:28.080 Some folks do it for homework, or for resumes, a really transparent way to demonstrate 03:28.080 --> 03:32.720 your capabilities to build code. 03:32.720 --> 03:38.120 And hopefully, whatever other reasons you might have, that last reason also applies, which 03:38.120 --> 03:40.360 is that you're trying to help the project, right? 03:40.360 --> 03:42.520 You're trying to make the project better. 03:42.520 --> 03:46.480 And so for the rest of this presentation, I'm going to assume that no matter what else 03:46.480 --> 03:51.760 you're trying to do, you're trying to help. 03:51.760 --> 03:54.360 So that raises the question. 03:54.360 --> 03:56.760 So you're trying to get your PR merged and you're trying to help. 03:56.760 --> 04:01.640 So does every merge PR actually help the project? 04:01.640 --> 04:03.920 Anyone? 04:03.920 --> 04:06.280 Anyone? 04:06.280 --> 04:07.280 Anyone? 04:07.280 --> 04:13.400 Any thoughts on this one? 04:13.400 --> 04:15.880 Somebody said no? 04:15.880 --> 04:22.880 Why not? 04:22.880 --> 04:29.320 Actively harmful, a passive, a harmful, yeah? 04:29.320 --> 04:32.640 Yeah, so it could be malicious, yeah? 04:32.640 --> 04:39.120 Yeah, so it could be adding a bunch of maintenance burdens. 04:39.120 --> 04:43.400 So maybe it's a good feature, but it's going to be really hard to maintain. 04:43.400 --> 04:44.400 Yeah. 04:44.400 --> 04:51.200 Yeah, maybe it doesn't match the vision of the people running the project. 04:51.200 --> 04:52.800 Yeah, one more. 04:52.800 --> 05:00.480 Company that's going to work for me to speak about leadership or whatever. 05:00.480 --> 05:06.400 Company you work for a new Zexer feature, yeah, maybe it's so I think one way to think 05:06.400 --> 05:12.840 about an open search project is we're all working together to build this drink of power. 05:12.840 --> 05:18.640 And so maybe it starts out nice and small and really stable, really easy to understand. 05:18.640 --> 05:22.920 And then we keep changing things and adding pieces and adding more features. 05:22.920 --> 05:27.240 And as we do it, it gets more complex and more fragile. 05:27.240 --> 05:32.840 And each new PR, you're adding a piece on top of this pile. 05:32.840 --> 05:37.920 And what you really don't want is to just pull off your piece down carelessly and collapse 05:37.920 --> 05:39.560 entire thing, right? 05:39.560 --> 05:45.320 So when we have a PR that we're trying to get merged, we really want to be thoughtful 05:45.320 --> 05:50.520 about that maintenance burden, the risks that introduces other parts of the project. 05:50.520 --> 05:54.640 And it really is something that containers are going to be thinking about when they're 05:54.640 --> 06:00.040 looking at your work. 06:00.040 --> 06:03.400 So how do you get your good PR merged? 06:03.400 --> 06:08.800 Well, like very simply you need maintainer approval, right? 06:08.800 --> 06:11.200 That's the definition of what containers can do. 06:11.200 --> 06:15.800 They can decide what goes into the project and what doesn't. 06:15.800 --> 06:17.960 But how do we do that? 06:17.960 --> 06:20.880 So first, okay, here's another toss-up. 06:20.880 --> 06:21.880 What's a maintainer? 06:21.880 --> 06:23.880 Anyone raise a hand? 06:23.880 --> 06:24.880 Yeah. 06:24.880 --> 06:33.880 Go ahead and then the jacket. 06:33.880 --> 06:35.680 So you have to speak up a little. 06:35.680 --> 06:43.320 Maybe some, sorry, I couldn't hear it, maybe because somebody could speak a little. 06:43.320 --> 06:50.320 A maintainer's, maintainer's, maintainer's integrating into the project. 06:50.320 --> 06:51.320 Yeah. 06:51.320 --> 06:52.320 Any, any other? 06:52.320 --> 06:53.320 Okay. 06:53.320 --> 06:54.320 There's another hand there. 06:54.320 --> 07:00.000 A person with no life outside the project, with a life outside the project? 07:00.000 --> 07:01.000 With a life outside the project. 07:01.000 --> 07:04.000 Yeah, sometimes it's definitely forget that. 07:04.000 --> 07:07.040 All right, here's my answer. 07:07.040 --> 07:13.080 Okay, first of all, sorry, it's not somebody who's fixes up autos. 07:13.080 --> 07:18.320 It's a super busy person responsible for making an open source project better and not breaking 07:18.320 --> 07:19.320 things. 07:19.320 --> 07:27.160 Hi, I'm a maintainer, so let me introduce myself a little bit, so you know where I'm coming 07:27.160 --> 07:29.160 from. 07:29.160 --> 07:35.400 So I work on Zulip, which is an organized team chat app, an open source alternative 07:35.400 --> 07:42.840 to something like Slack, Microsoft Teams, Discord, you can self-host it, or we offer cloud 07:42.840 --> 07:46.080 hosting, which is free for open source projects that chat with me afterwards if you're 07:46.080 --> 07:48.880 interested. 07:48.880 --> 07:53.160 And we've really invested a lot into building up an open source community around the 07:53.160 --> 08:02.200 project, so we've had 1,500 code contributors over the 10 years of the project with 100 08:02.200 --> 08:07.360 contributors with 100 or more commits, so lots of folks who have got really deep engagement. 08:07.360 --> 08:14.160 The support this we've written, almost 200,000 words of documentation for developers. 08:14.160 --> 08:18.200 And if that sounds daunting, that was over the course of 10 years and definitely not something 08:18.200 --> 08:26.760 we started with or you have to start with, much less could be very, very useful. 08:26.760 --> 08:31.080 So how do you collaborate with maintainers, these really busy people? 08:31.080 --> 08:36.320 Well, here are a couple of really important questions and maintainers going to have about 08:36.320 --> 08:38.720 your pull request. 08:38.720 --> 08:41.200 So one is, we talked about being useful, right? 08:41.200 --> 08:48.600 So do these changes do something useful in a good way, so good can mean in line with the projects, 08:48.600 --> 08:54.440 the standards and kind of fitting with the rest of the code, not introducing regressions 08:54.440 --> 08:58.920 elsewhere, all sorts of things. 08:58.920 --> 09:02.680 So, but let's talk about the useful part. 09:02.760 --> 09:06.640 So suppose I'm baking a pair of tart, right? 09:06.640 --> 09:11.480 And I have these nice three pairs that I'm getting ready to bake and you come to me and 09:11.480 --> 09:16.160 you're like, here's a beautiful red apple, it's delicious, it's great. 09:16.160 --> 09:22.080 And I look at it and I'm like, yeah, that's a great apple, but I am making a pair of tart. 09:22.080 --> 09:24.840 So what do I do with your apple, right? 09:24.840 --> 09:30.320 So when you're submitting a pull request somewhere, probably the maintainers of the projects 09:30.320 --> 09:35.360 have some visions, some idea of what their product is, what it needs to do, and what it 09:35.360 --> 09:36.960 doesn't need to do. 09:36.960 --> 09:40.840 And so what you don't really don't want to do is they're working on a pair of tart and 09:40.840 --> 09:42.520 you come in there with your apple, right? 09:42.520 --> 09:49.280 Maybe it could be a great feature, maybe it's a great feature for some, it might be, it 09:49.280 --> 09:54.240 might be, but the maintainers, it doesn't fit what the maintainers think their product 09:54.240 --> 09:55.880 is about. 09:55.880 --> 10:02.560 So you don't want to spend all that effort of doing the code changes, testing them, 10:02.560 --> 10:07.880 all that work until you know that it's something that maintainers are actually interested 10:07.880 --> 10:08.880 in. 10:08.880 --> 10:12.360 And so there's going to be different ways to find that out for different projects. 10:12.360 --> 10:19.080 So often one clear way is if there's a public issue tracker and maybe the project uses 10:19.080 --> 10:23.080 a label to indicate which issues are open for contribution, like here we have the help 10:23.080 --> 10:26.800 on in label, great, you know, that's something that containers would be excited to see 10:26.800 --> 10:29.000 in this project. 10:29.000 --> 10:35.440 Often there's like a development community, a chat or forum, or even just posting an issue 10:35.440 --> 10:40.960 to their repose, hey, here's the thing I'd like to work on, is this something you're 10:40.960 --> 10:41.960 interested in. 10:41.960 --> 10:45.920 But don't do all that coding work before you've done the kind of social work of understanding 10:45.920 --> 10:49.160 is this a feature that they want. 10:49.160 --> 10:53.800 Maybe you're initial, maybe you'll also find that the initial idea came with is an apple 10:53.800 --> 10:54.800 for them. 10:54.800 --> 10:58.360 But there's something that is a pair that just requires discussion and back and forth 10:58.360 --> 11:02.360 and kind of aligning what you're looking for and what they're looking for. 11:02.360 --> 11:10.200 Okay, and then another question the maintainers are going to have is how risky is this change, 11:10.200 --> 11:11.200 right? 11:11.200 --> 11:14.240 Because we talked about how containers are responsible for things not breaking. 11:14.240 --> 11:17.640 So they're going to look at your change and be like, okay, how likely is this to break 11:17.640 --> 11:18.640 things? 11:18.640 --> 11:25.840 And if everything looks good, it's useful, it seems reasonably implemented, it's low risk. 11:25.840 --> 11:29.520 That's when your PR is going to get merged. 11:29.520 --> 11:35.520 There's also a situation that's very common where initially the answer is, well, not yet, 11:35.520 --> 11:40.400 like it doesn't quite meet our standards, this thing could be done better, so on, but 11:40.400 --> 11:43.080 I can see a path towards yes. 11:43.080 --> 11:45.840 And that's when the maintainer will probably leave some feedback on your pull across 11:45.840 --> 11:52.040 and ask you to improve it to make it better before they can merge it. 11:52.040 --> 11:55.800 But what if your PR is just kind of a mess? 11:55.800 --> 11:59.200 Like you look at it and you're like, I have to do something, but I can't really tell what's 11:59.200 --> 12:01.200 happening here. 12:01.200 --> 12:05.920 I don't really understand this. 12:05.920 --> 12:11.280 That's when you're probably not going to get reviewed, yes, you're certainly not going 12:11.280 --> 12:12.520 to get that PR merged right away. 12:12.560 --> 12:16.680 It's probably not even going to get a feedback, because as we said, the maintainers are 12:16.680 --> 12:21.560 busy people, they're prioritizing things that they can see as likely to move the project 12:21.560 --> 12:22.560 forward. 12:22.560 --> 12:27.160 If they look at your PR and they have no idea if it's going to move the project forward, 12:27.160 --> 12:29.960 they're not going to be able to review it, it's just not going to be worth their time. 12:29.960 --> 12:33.280 And I think it's a really fair decision for them. 12:33.280 --> 12:37.560 And so advice, you'll get a comment saying, hey, I can't understand what's happening here, 12:37.560 --> 12:40.560 can you please fix that up and make it more clear. 12:40.640 --> 12:46.760 Maybe they'll just think they'll review it someday when they have more time, so it'll be 12:46.760 --> 12:51.040 forever and you'll never hear back or maybe they'll just ignore it, but really you're 12:51.040 --> 12:56.160 not on a good track of this is where you start. 12:56.160 --> 13:01.400 The rest of this presentation is how to put together a pull request that doesn't look like 13:01.400 --> 13:05.920 a pile of LEGO fricks. 13:05.920 --> 13:09.080 Let's see what's involved. 13:09.120 --> 13:13.120 Let's just go kind of all the pieces that put together the go together to making a pull 13:13.120 --> 13:14.120 request. 13:14.120 --> 13:19.520 So this is just a screenshot of a pull request from one of Zolves maintainers and then 13:19.520 --> 13:23.520 we're just going to go over all the pieces you can see we're using the GitHub UI so 13:23.520 --> 13:28.200 this GitHub so this UI might be familiar for you. 13:28.200 --> 13:34.680 So one piece is the comment history, so we'll talk about that. 13:34.680 --> 13:39.240 The other piece is the PR title at the top and then just some textual description of 13:39.240 --> 13:41.320 the changes. 13:41.320 --> 13:46.200 You might have screenshots for visual changes. 13:46.200 --> 13:52.000 There might be some CI running so it's going to be test that you need to pass. 13:52.000 --> 13:57.240 And for us there's also a self review checklist that you need to check off before when 13:57.240 --> 13:59.600 you're submitting your pull request. 13:59.600 --> 14:04.080 So this is going to be kind of the outline for the rest of the talk with one bonus section 14:04.080 --> 14:08.000 of the follow. 14:08.000 --> 14:17.920 And the idea here is look, when as folks trying to contribute to open search projects, 14:17.920 --> 14:21.880 we need to find our way around, maybe this is a new project we've never worked with before, 14:21.880 --> 14:25.640 we really try to figure out how it works, what do we do here? 14:25.640 --> 14:30.640 And often maintainers will create a kind of map for us like contributing guidelines, documents 14:30.640 --> 14:33.400 that walk us through what their expectations are. 14:33.400 --> 14:36.800 And if they've done so, it's super important to follow that map, it's really going to help 14:36.800 --> 14:38.800 you out. 14:38.800 --> 14:41.240 But what I'm trying to do in this talk is a couple of things. 14:41.240 --> 14:46.000 One, sometimes you don't have a map for the maintainers or maybe it's very sparse just 14:46.000 --> 14:51.760 a few checkpoints, but there's also lots of open areas that are unknown. 14:51.760 --> 14:56.240 So what I'm going to provide is kind of best practices or ideas for where you can, how 14:56.240 --> 14:58.520 you can fill in those gaps. 14:58.520 --> 15:02.360 And then, as a maintainer, I hope this gives you some ideas for if you're still working 15:02.360 --> 15:06.040 on your map or if you're improving your map, what are the kinds of areas that you might 15:06.040 --> 15:10.080 want to fill in and think about for your project, with some examples of how we do it 15:10.080 --> 15:11.080 at Zilla. 15:11.080 --> 15:14.080 So that's the plan. 15:14.080 --> 15:17.120 All right, so come in history. 15:17.120 --> 15:26.040 So if you were here for the previous talk, I just want to tell you that we use the same kind 15:26.040 --> 15:30.440 of commute approach that the speaker was advocating for, so parts of this will sound 15:30.440 --> 15:34.400 a little familiar. 15:34.400 --> 15:35.400 So, all right. 15:35.400 --> 15:36.400 So, forgive me to history. 15:36.400 --> 15:42.200 So, idea that we, for our projects that commits tell the story of your changes. 15:42.200 --> 15:43.200 So what does that mean? 15:43.200 --> 15:47.880 So, each commit is a minimal coherent idea. 15:47.880 --> 15:50.280 So, why is that useful? 15:51.240 --> 15:57.080 Well, you can quickly review each and separate commit and try and understand it and assess 15:57.080 --> 16:01.400 the risk we talk to how risk is really important. 16:01.400 --> 16:07.720 And then, if maintainers keep the commit history as you presented it, you can use things 16:07.720 --> 16:12.400 like get by-sector to track down where something broke. 16:12.400 --> 16:15.640 And as the speaker last I mentioned, even on your own branch, you could potentially use 16:15.640 --> 16:21.760 get by-sector to figure out which of your six commits is actually causing the problem. 16:21.760 --> 16:29.280 So, this means in really practical terms, you would split out things like refactoring 16:29.280 --> 16:34.560 or enaming that's preparation for the changes that you're making from the actual functional 16:34.560 --> 16:35.560 changes. 16:35.560 --> 16:40.080 Because it's easily just to check, oh, okay, I expect this to not really change the functionality 16:40.080 --> 16:42.320 and it doesn't change the functionality. 16:42.320 --> 16:43.320 Great. 16:43.320 --> 16:47.240 Each new feature improvement would be its own commit. 16:47.240 --> 16:52.560 And then, with how just review tools work and how it does tools work, it's really nice 16:52.560 --> 16:56.880 if you split moving code from changing code, because if you both move and change it becomes 16:56.880 --> 17:02.040 much harder to see which parts you changed. 17:02.040 --> 17:05.840 So the thing is you also don't want to split things too too much. 17:05.840 --> 17:11.640 So each commit, the idea is here is that each commit should be safe to deploy, so it doesn't 17:11.640 --> 17:12.880 make the product worse. 17:12.880 --> 17:18.040 It might not make it better yet, like maybe that refactoring you did, doesn't really help 17:18.040 --> 17:24.160 or hurt either way on its own, but it doesn't make things worse. 17:24.160 --> 17:30.200 It updates whatever tasks need to be updated, so commits pass at each commit and includes 17:30.200 --> 17:36.080 error handling for the code changes you're making. 17:36.080 --> 17:42.840 And so when you do things this way, you can really lay out the story of how each change 17:42.840 --> 17:44.960 that you're proposing is necessary or helpful. 17:44.960 --> 17:48.920 You can really kind of set that out piece by piece in a logical order that's going 17:48.920 --> 17:53.600 to be easy for your viewers to understand. 17:53.600 --> 17:57.880 And it's really important to remember to tell the story of the changes as they are not 17:57.880 --> 18:01.680 of how you got to these particular changes. 18:01.680 --> 18:04.000 So here's a toss up. 18:04.000 --> 18:10.840 Should you have a commit for things that you tried that didn't work out? 18:10.840 --> 18:12.840 Who says yes? 18:12.840 --> 18:14.840 Who says no? 18:14.840 --> 18:20.840 Yeah, the nose have it, so you don't want that, because then the maintainers are going 18:20.840 --> 18:24.440 to be looking at it and thinking, oh, why are they doing it this way? 18:24.440 --> 18:25.440 Right? 18:25.440 --> 18:29.000 If there may be reading your changes coming by commit, there may be like, oh, hum, I don't 18:29.000 --> 18:30.000 understand this. 18:30.000 --> 18:31.880 And I don't think this is the right way to go. 18:31.880 --> 18:33.800 Maybe they'll start commenting on it. 18:33.800 --> 18:37.640 And then you'll see that two commits later, you actually did all that and fixed it yourself. 18:37.640 --> 18:42.440 And that was a giant waste of time for them to think about it. 18:42.440 --> 18:45.360 How about things like fixed a test type book or fixed a link there? 18:45.360 --> 18:46.560 Should those be separate commits? 18:46.560 --> 18:47.720 Who says yes? 18:47.720 --> 18:51.000 Yeah, who says no? 18:51.000 --> 18:54.000 Yeah, squash them. 18:54.000 --> 18:56.720 Get rebased that shy is great for this kind of thing. 18:56.720 --> 18:57.720 Super easy. 18:57.720 --> 19:02.760 And really, again, lots of your reviewers actually read your changes committed by commit 19:02.760 --> 19:06.880 and understand the steps of your thinking and not get confused when they see something 19:06.880 --> 19:12.840 as wrong and then they're like, oh, but you actually fix this down the line. 19:12.840 --> 19:17.360 So commit, in addition to your coaches, you're also writing a commit message to explain 19:17.360 --> 19:18.640 the changes. 19:18.640 --> 19:21.080 So what goes into that message? 19:21.080 --> 19:27.080 Well, explaining your changes means providing some context and motivation for what you're 19:27.120 --> 19:28.080 doing. 19:28.080 --> 19:32.840 So it might be like investigation or reasoning, like, okay, I'm removed, you know, this function 19:32.840 --> 19:37.720 was removed because we haven't been using it since this other commit, I might have 19:37.720 --> 19:46.880 some background on the contrasting and the situation was before your changes versus after. 19:46.880 --> 19:51.320 And it can also make promises or gritty so like, this commit makes no functional changes 19:51.320 --> 19:59.280 because something and that way the reviewer understands what you were trying to do and 19:59.280 --> 20:02.360 they can much more easily to check, did you succeed in doing that? 20:02.360 --> 20:07.080 So if they know that the goal is to make no functional changes, they can check for that 20:07.080 --> 20:12.960 and see if that's correct. 20:12.960 --> 20:17.840 But the commit message shouldn't just say everything under the sky, it shouldn't 20:17.840 --> 20:18.840 explain the obvious. 20:18.840 --> 20:23.520 So if you're updating some file, you don't need to say that in the commit message because 20:23.520 --> 20:26.000 that's clear from the deaf, right? 20:26.000 --> 20:30.400 If you're renaming a function, again, that is what their viewer is going to see in the 20:30.400 --> 20:35.760 deaf and it doesn't provide any of the thinking that you have behind it. 20:35.760 --> 20:40.960 So just kind of these facts that are easily visible from other parts, from the code changes 20:40.960 --> 20:46.200 themselves or from the say of the good hub UI, like those things don't never need to be 20:46.200 --> 20:47.200 in there. 20:47.200 --> 20:52.560 And you also don't want to put information there that will help future readers understand 20:52.560 --> 20:53.560 the code. 20:53.560 --> 20:58.040 So not understand the change in the code, but understand the code itself because that information 20:58.040 --> 21:01.880 is going to be really helpful to have a, as a common direct thing in the code and therefore 21:01.880 --> 21:08.080 you don't need to be putting it into the commit as well. 21:08.080 --> 21:16.960 So maintainers can guide contributors towards the commit structure, commit messages that 21:16.960 --> 21:18.960 they want to see in their projects. 21:18.960 --> 21:26.520 So here's an example for Zulu, this is just the sections of the commit discipline part 21:26.520 --> 21:28.520 of our contributing guide. 21:28.520 --> 21:35.600 So you can see we go into a lot of detail actually with a bunch of details, rules, examples 21:35.600 --> 21:40.000 because we really want to get specific and really want to help folks do things in the 21:40.000 --> 21:44.160 way that will kind of best fit for a project. 21:44.160 --> 21:49.320 And so if a project has commit guidelines, I'm absolutely not going to tell you to throw 21:49.320 --> 21:50.720 those out and do what I'm saying. 21:50.720 --> 21:53.080 You should follow those guidelines. 21:53.080 --> 21:57.720 But I think the approach that I'm presented here is going to be really helpful even 21:57.720 --> 22:01.560 of them and maintainers, as long as the maintainers are fine with it. 22:01.560 --> 22:05.800 Even if the action of squash or your commits later, it's still going to be a really useful 22:05.800 --> 22:11.960 tool for them to review your work, even if it does get squashed as part of how they manage 22:11.960 --> 22:15.320 their get work flow. 22:15.320 --> 22:22.360 So when you have detailed guidelines like this, the amazing thing is you never have to 22:22.360 --> 22:26.240 rewrite and re-explain what you're looking for. 22:26.240 --> 22:31.480 So next time you get this is a screenshot of a real pull request for Zulu, so there's 22:31.480 --> 22:36.560 a bunch of commits here fixing, lending, fixing tasks. 22:36.560 --> 22:40.920 And when we see this, we don't need to explain to them everything that the previous 22:40.920 --> 22:48.400 talk went over, we just say, okay, these are just a couple of the saved replies I have 22:48.400 --> 22:49.400 in GitHub. 22:49.400 --> 22:52.920 Okay, please clean up for your commit history and post again to request review, see here 22:52.920 --> 22:59.280 for guidelines, or thanks for the fix, could you please, did your commit message to match 22:59.280 --> 23:00.920 the commits style guidelines? 23:00.920 --> 23:01.920 That's all I've got to say. 23:01.920 --> 23:07.040 I don't have to tell them what we're looking for beyond that. 23:07.040 --> 23:08.040 So this is the end of this section. 23:08.040 --> 23:10.440 I actually want to do questions kind of as we're going along. 23:10.440 --> 23:13.560 So does anybody have a question of this stage? 23:13.560 --> 23:15.560 Yeah. 23:15.560 --> 23:16.560 Yeah. 23:16.560 --> 23:17.560 Yeah. 23:17.560 --> 23:23.240 There's been no way that you can change your history like you, do you need to like 23:23.240 --> 23:24.240 your. 23:24.240 --> 23:25.240 Uh-huh. 23:25.240 --> 23:29.140 And then you have a situation in that, go back and find the change of the 23:29.140 --> 23:30.140 way. 23:30.140 --> 23:31.140 Yes, please do. 23:31.140 --> 23:32.140 Absolutely. 23:32.140 --> 23:33.140 Uh, sorry. 23:33.140 --> 23:35.340 Why does one work here? 23:35.340 --> 23:36.340 Okay, please. 23:36.340 --> 23:37.340 Yes. 23:37.340 --> 23:38.340 I'm not sure. 23:38.940 --> 23:40.440 OK, please, yes. 23:40.440 --> 24:10.040 Well, so this is going in the commit history. 24:11.040 --> 24:17.040 I don't think we've thought very hard about the migration pass. 24:17.040 --> 24:22.040 I don't think that's a priority, but also I would expect that any move we make would 24:22.040 --> 24:25.040 have to carry over the commit history otherwise it's just not going to be like a reason 24:25.040 --> 24:30.040 we'll move first to make. 24:30.040 --> 24:36.040 Right. Well, we're going to talk about several, but I was talking about commit 24:37.040 --> 24:43.040 messages right now. Yes. 24:58.040 --> 25:03.040 So, I'm personally not a developer. I'm a, the product lead, but our developers 25:03.040 --> 25:08.040 I think do very much change their commit history as they work out in PR and redo it. 25:08.040 --> 25:12.040 And often reviewers will actually say, OK, this part needs to be split up more. 25:12.040 --> 25:15.040 Please break this up and just separate commit. 25:15.040 --> 25:20.040 That is changing over the course of their approach this for sure. 25:20.040 --> 25:22.040 Yes. 25:22.040 --> 25:32.040 Because then, sorry, the question was why one change per commit when one change per 25:32.040 --> 25:38.040 pull request? 25:38.040 --> 25:43.040 Because that just makes it easier to review bit by bit and raise easier to understand the story. 25:43.040 --> 25:47.040 So, if you expect each commit to be a coherent change, you can think about just 25:47.040 --> 25:51.040 that one commit, not the like 300 lines of changes in the pull request, but just those 25:51.040 --> 26:00.040 30 lines of this commit and take it one piece at a time as a reviewer. 26:00.040 --> 26:04.040 Well, a pull request, sorry, what the question is, when would you put commits into 26:04.040 --> 26:09.040 multiple commits into a pull request? I mean, usually a pull request will have like 26:09.040 --> 26:14.040 some feature or something, you know, some related piece of work that it is. 26:14.040 --> 26:18.040 But it could still be broken down further into coherent changes. 26:18.040 --> 26:22.040 So, like, for example, you know, depending, but you might make back-hand changes and then 26:22.040 --> 26:27.040 separately add a front-done for the feature. 26:27.040 --> 26:30.040 Yes. 26:31.040 --> 26:48.040 So, I see, so there's a question about a pull request that just had a commit, 26:48.040 --> 26:53.040 must it just rename something? So, I would suggest saying something like, like, 26:53.040 --> 26:57.040 if I knew why you're renaming it, right? Like, there's some reason you're doing that. 26:57.040 --> 27:00.040 Making that change. 27:00.040 --> 27:03.040 All right. So, I think I'll move to the next section, but thank you. 27:03.040 --> 27:05.040 This was great. 27:05.040 --> 27:08.040 All right. So, now we're going to talk about the PR title in the description. 27:08.040 --> 27:11.040 So, this is the, I think, maybe a previous question was asked about. 27:11.040 --> 27:16.040 This is the piece that wouldn't move if you're, like, changed from 27:16.040 --> 27:20.040 GitHub to GitHub or something. So, this is where you're going to be explaining your 27:20.040 --> 27:27.040 changes to reviewers. So, all right. Suppose your changes on the surface look like a 27:27.040 --> 27:33.040 beautiful, tropical island. But underneath, there's a dinosaur skull. 27:33.040 --> 27:39.040 There's really something fraught there. You have to mention the dinosaur skull. 27:39.040 --> 27:43.040 Okay. You cannot just present this beautiful island. So, why do I say that? 27:43.040 --> 27:47.040 Any thoughts on why I'm saying this is really important? 27:48.040 --> 27:52.040 Like, what happens if you don't do it? Yeah. 27:52.040 --> 27:56.040 Accurate estimation of risk. Yeah. For the maintainers to accurately estimate risk, 27:56.040 --> 27:59.040 they need to understand what risks you're aware of. 27:59.040 --> 28:02.040 They're really going to be helping them out. 28:02.040 --> 28:07.040 Anyone else? 28:07.040 --> 28:10.040 Yeah. 28:18.040 --> 28:24.040 Yeah. So, I couldn't quite quite hear, but I think you said, 28:24.040 --> 28:27.040 maintainers to be able to trust the needs to be honest with the maintainer. 28:27.040 --> 28:32.040 Yeah. So, I think that's really, it's super important. Like, if you do this, 28:32.040 --> 28:36.040 if you don't mention that what's hiding underneath, there's two things that can happen. 28:36.040 --> 28:40.040 One is the maintainer might not notice and they might merge the changes and they could 28:40.040 --> 28:44.040 cause problems for the project down the line. And we just said, we're all trying to 28:44.040 --> 28:51.040 help these projects, right? So, we don't want that. They might also notice the problem. 28:51.040 --> 28:58.040 And then they'll wonder why you didn't tell them. And there might be like two plausible explanations. 28:58.040 --> 29:03.040 One is you didn't know, which brings into question your competence as an engineer. 29:03.040 --> 29:08.040 Or two, you didn't know, and you didn't tell them, in which case, how can they trust you, right? 29:08.040 --> 29:11.040 How can they trust you in the future? And so, 29:12.040 --> 29:16.040 contributed to business projects was in part establishing a relationships with 29:16.040 --> 29:21.040 the maintainers for those projects. And if they decide that they can't trust you as a 29:21.040 --> 29:25.040 contributor, it's going to be really hard for you to get any of your work integrated 29:25.040 --> 29:29.040 into the project down the line. So, it's not just hurting your chances with this 29:29.040 --> 29:34.040 full request. It's really, it can be really damaging to your relationship with the project. 29:34.040 --> 29:39.040 So, please. So, okay. So, how do you explain your changes? 29:39.040 --> 29:44.040 So, here, I have an example of a pull request from one of Zulv's maintainers. 29:44.040 --> 29:50.040 Just a simple API docs change to updates on documentation. And I'm just going to go, 29:50.040 --> 29:53.040 it's not important. You know, you need to start reading this right now, but I'm just going to go 29:53.040 --> 29:59.040 through the different pieces of it. So, the first part is just an overview. So, this is kind of like, 29:59.040 --> 30:05.040 what was the state before this pull request? And so, why is this pull request needed, right? 30:05.040 --> 30:10.040 There are some changes made to the API. Now, we need to update the documentation. 30:10.040 --> 30:17.040 Then, there's a note section, which notes a decision that the author of the pull request 30:17.040 --> 30:22.040 made. So, they decided to use the edit a message and point main description as a template for 30:22.040 --> 30:27.040 these updates. And that is super helpful to review, because now they can say, 30:27.040 --> 30:34.040 okay, do I agree with that decision? If yes, then actually it could be much less careful 30:34.040 --> 30:38.040 in some ways when reviewing this work, because I now understand what they're trying to do. 30:38.040 --> 30:44.040 And so, I have, I don't need to put myself go and compare this versus the edit a message 30:44.040 --> 30:49.040 and point description necessarily. If I trust that they might have, they probably did this carefully. 30:49.040 --> 30:55.040 Where they can decide that they don't like this decision, but then instead of going through 30:55.040 --> 31:02.040 and giving detailed feedback, a line by line, trying to get this aligned with the edit a message 31:02.040 --> 31:07.040 or with something else, they can just say, no, no, no, I think we should be matching this other template. 31:07.040 --> 31:11.040 Can you please read it that way? That's all they need to do. 31:11.040 --> 31:17.040 This also raises an open question or concern, so I'm not sure if I should include this, 31:17.040 --> 31:22.040 I decided to do it this way, but I'm not sure. So, again, now the maintainer, 31:22.040 --> 31:26.040 the reviewer can really think about this question and answer the question, 31:26.040 --> 31:33.040 yes, great, I like it, how you did this or please do it some other way. 31:33.040 --> 31:39.040 And then it also indicates a difference from prior plans, where maybe initially when this project was planned, 31:39.040 --> 31:43.040 you didn't think about doing something, but when they're working on it, 31:43.040 --> 31:49.040 the person who put up this full request realized that an additional change was needed. 31:49.040 --> 31:54.040 And that also really helps the reviewer not get surprised by it, not be like, 31:54.040 --> 31:59.040 this is coming from this wasn't discussed, so now they understand what that's all about. 31:59.040 --> 32:05.040 So, this is the kind of points that your pull request description can make to really help 32:05.040 --> 32:12.040 folks review your work quickly and really address the points of concern that you have. 32:12.040 --> 32:18.040 So, any questions on this? 32:18.040 --> 32:25.040 Yeah. 32:25.040 --> 32:31.040 So, I would say that this kind of thing, like many of these don't really need to be like, 32:31.040 --> 32:34.040 you know, because some of this is things like, oh, we consider, 32:34.040 --> 32:37.040 basically like, should we do it this way or some other way? 32:37.040 --> 32:41.040 And I don't, you probably most of the time don't need to describe that other way too. 32:41.040 --> 32:46.040 This is more like important while you're thinking about whether to do it, 32:46.040 --> 32:51.040 whether to merge this, but it won't be so important if you're later trying to figure out what happened. 32:51.040 --> 32:56.040 And you can, I mean, as long as you don't, you're still on good hover whatever you're on, 32:56.040 --> 33:01.040 you will also be able to trace down commits to the pull request they came from, 33:01.040 --> 33:09.040 so this is not entirely lost, so it is like one step further away from the code. 33:09.040 --> 33:14.040 Anything else? 33:15.040 --> 33:21.040 What about tests? We're going to talk about them separately. 33:21.040 --> 33:27.040 Oh, yeah. So, right. No, so I think that's actually, that's actually something that we have added to our peer 33:27.040 --> 33:34.040 template recently, but yeah, I think explaining how you tested sort of manually is a great thing to add there for sure. 33:34.040 --> 33:35.040 Yeah. 33:35.040 --> 33:36.040 Yeah. 33:37.040 --> 33:42.040 Yeah. I think people don't like reviewing those, but, you know, you do what you can. 33:42.040 --> 33:46.040 Sorry, the question was of what about massive changes that you can't split up. 33:46.040 --> 33:51.040 I think you, you know, I think, at least for us, we would try to split up things up as much as we can, 33:51.040 --> 33:59.040 and then when we can't, I guess it's just, there's just a, there's going to be a lot of things that we can. 33:59.040 --> 34:09.040 Yeah. 34:09.040 --> 34:17.040 Yeah. 34:17.040 --> 34:22.040 Yeah. So the point that was made in the audience is that it's not, that's not the kind of change that you would be making us back. 34:22.040 --> 34:25.040 Like, you wouldn't just show up to project and contribute to change like that. 34:25.040 --> 34:36.040 You know, it's something that maintainers are doing and working together on to make it as, you know, you've figured out a good way to do it for sure. 34:36.040 --> 34:37.040 Cool. 34:37.040 --> 34:40.040 All right. So the next section is screenshots. 34:40.040 --> 34:45.040 So this is how to show any of changes that are visual changes. 34:45.040 --> 34:50.040 So there's a few different things that screenshots are super helpful for. 34:50.040 --> 34:54.040 In addition to kind of anything you're right about how you tested your PR. 34:54.040 --> 34:58.040 They can also demonstrate visually how you tested your PR. 34:58.040 --> 35:04.040 They can help clarify requirements, so maybe you worked on submission to add a button. 35:04.040 --> 35:10.040 And the spec didn't say exactly where to place it or didn't, maybe it didn't say what color the button should be. 35:10.040 --> 35:15.040 So now if you look at it and be like, oh, actually, I meant for the button to be over there, and can you make it blue? 35:15.040 --> 35:17.040 Great. They didn't even have to look at your code. 35:17.040 --> 35:21.040 They didn't have to pull down the PR into their dev environment. 35:21.040 --> 35:25.040 They just looked at your screenshot and they could provide you the next set of feedback. 35:25.040 --> 35:30.040 It can be a way to raise questions and get consensus on some decisions. 35:30.040 --> 35:37.040 So maybe you're like, oh, should this be, should this part of be this big or twice as big? 35:37.040 --> 35:43.040 Let me put up some screenshots of different variants and then people can discuss with concrete visuals in mind. 35:43.040 --> 35:53.040 And it's just less QA for viewers. So maybe you actually did follow this spec and you did exactly what it said. 35:53.040 --> 35:58.040 But looking at it now or viewers says, oh, actually, let's change this string to something else. 35:58.040 --> 36:03.040 Again, they could just kind of get that official context for where your work is appearing. 36:03.040 --> 36:06.040 So they're super helpful. 36:06.040 --> 36:12.040 So we had a pull request and I'm going to try to speed up a little bit because we're going to pull requests to change it to a little bit. 36:12.040 --> 36:20.040 So you might expect like screenshots for that. So what would you expect? 36:20.040 --> 36:25.040 Like maybe the, okay, I'm going to actually sort of keep moving. 36:25.040 --> 36:29.040 So let me show you what we got assuming this video plays. 36:29.040 --> 36:32.040 This is what we got to demonstrate that change. 36:32.040 --> 36:37.040 Now, how do you feel about reviewing this? 36:38.040 --> 36:44.040 I don't know about you, but I think that's, that's kind of terrible. 36:44.040 --> 36:48.040 That makes me cry. Like I can't really see what the tool tip was. 36:48.040 --> 36:54.040 Did it, you know, was it what I was, what we wanted to be or not, I'm not sure. 36:54.040 --> 36:58.040 So I think it's really important to be judicious with screenshots. 36:58.040 --> 37:03.040 Like they can be tempting because you can show all your changes all at once to just in one fall swoop. 37:03.040 --> 37:06.040 But it actually makes it really hard to review them. 37:06.040 --> 37:09.040 And so they should only be reserved for interaction. 37:09.040 --> 37:13.040 So maybe if you really wanted to show like how quickly the tool tip shows up or something, 37:13.040 --> 37:15.040 they should be as short as possible. 37:15.040 --> 37:19.040 So I never want to see like pulling open the app. 37:19.040 --> 37:24.040 And even if you're showing everything there is to show on a screencast, 37:24.040 --> 37:29.040 you should also include a still screen shot because it's so much easier to look at. 37:30.040 --> 37:35.040 So here's after we get after I gave feedback to this contributor here's what they produced, 37:35.040 --> 37:37.040 which works fine for this pull request. 37:37.040 --> 37:43.040 I can see that they actually change the strings as expected. 37:43.040 --> 37:50.040 But for some kinds of changes that are more visual like here changing an icon and the hover colors, 37:50.040 --> 37:55.040 what you really want is actually matched screenshots of before and after. 37:55.040 --> 38:00.040 The only thing that is changing is the thing that your PR changes. 38:00.040 --> 38:05.040 So the the colors are the the mentions are the same everything in the UI is the same. 38:05.040 --> 38:09.040 And only your changes are what what is what is different. 38:09.040 --> 38:13.040 Because that way of your connection open these screenshots in different tabs. 38:13.040 --> 38:18.040 For example, if flip back and forth and watch the changes animate that's super helpful. 38:18.040 --> 38:23.040 And it's really great for kind of see us as changes visual changes in general. 38:24.040 --> 38:31.040 So again, maintainers can really help contributors do this by providing guidance. 38:31.040 --> 38:38.040 So this is actually brand new for us having these detailed instructions for how to generate the kinds of screenshots we're looking for. 38:38.040 --> 38:44.040 And when you need really precise pairs screenshots and when you can get away with less and so on, 38:44.040 --> 38:47.040 including like pointers to specific software. 38:48.040 --> 38:58.040 When maybe think that out of everybody is explored, but like the dovetools and your browser of Chrome or Firefox are amazing for producing these pet and really nice pairs screenshots. 38:58.040 --> 39:05.040 They really completely let you control the dimensions and get exactly the screenshots you want. 39:05.040 --> 39:13.040 All right, good to move faster tests, which are good for moving quickly without breaking things. 39:13.040 --> 39:23.040 So what are tests for so they they help you validate your changes right I probably don't need to sell y'all on to us, but I'm going to do it for a little bit anyway. 39:23.040 --> 39:30.040 They help you communicate your PR is expected behavior including corner cases and then help you make future changes safely. 39:30.040 --> 39:36.040 So the question is like, what how do we write tests to do these these great things that we want from them. 39:36.040 --> 39:39.040 Okay, here's how not to write tests. 39:40.040 --> 39:48.040 So suppose you have a recipe that requires some hazelnuts so your recipe might say how many hazelnuts you need. 39:48.040 --> 40:01.040 It might say I don't know the the weight of the hazelnuts you need how to prepare them, but it will never tell you the size of the opening and the jar that you're getting the hazelnuts from right. 40:01.040 --> 40:10.040 Because it doesn't matter it's not going to affect how your recipe comes out and you might have a different jar tomorrow and the recipe will still be fine. 40:10.040 --> 40:16.040 And that kind of thinking applies to testing as well. 40:16.040 --> 40:29.040 So you want to be testing the things that matter and not things that are just implementation details that happen to be this way, but it could just be as well be some other way and that would be totally fine. 40:29.040 --> 40:37.040 Because when you test the size of the jar you're just going to have to be fixing those tests and rewriting those tests when you make changes. 40:37.040 --> 40:45.040 But they're not going to be like they're not protecting against the things that actually are important to protect against they're just busy work. 40:45.040 --> 40:56.040 So if you want to hear more about this Greg Price who's our mobile tech lead, give an excellent talk at Fluracon rating better test with less work. 40:56.040 --> 40:58.040 So I highly recommend that. 40:59.040 --> 41:04.040 All right, self review. 41:04.040 --> 41:09.040 The other thing you need to do before you submit your focus please. 41:09.040 --> 41:13.040 So what happens if you don't really review your own work. 41:13.040 --> 41:19.040 So you're thinking your PR is now nice and this beautiful little house and nice feature you're adding. 41:19.040 --> 41:24.040 But actually it looks more like this like it is there's a yellow wall. 41:24.040 --> 41:31.040 It looks like maybe it's going to go somewhere, but you don't really know what's happening here yet. 41:31.040 --> 41:37.040 And you know we talked about what happens when a maintainer doesn't really know the PR is going to be helpful or not right. 41:37.040 --> 41:40.040 They might not even review it. 41:40.040 --> 41:47.040 So you want to be before you ask for anybody else to take a look you really want to be putting your best foot forward. 41:48.040 --> 41:51.040 So here like here are a few things you should be thinking about. 41:51.040 --> 41:55.040 So it's great to look back at the issue if you were fixing an issue right. 41:55.040 --> 41:57.040 Did you actually cover everything that was there? 41:57.040 --> 41:58.040 Did you do it? 41:58.040 --> 42:03.040 Did you follow any all the, all the, everything that was specified? 42:03.040 --> 42:08.040 And if you didn't did you explain why in the description for your pull request. 42:08.040 --> 42:12.040 Your code is, does it match the style of the code around it? 42:12.040 --> 42:14.040 Lots of questions there. 42:14.040 --> 42:17.040 Did you structure commits in a way that makes sense? 42:17.040 --> 42:19.040 Do they tell a clear story of your changes? 42:19.040 --> 42:24.040 Is there anything that needs to be squashed together or split out? 42:24.040 --> 42:28.040 Do you have a clear title in the description for your pull request? 42:28.040 --> 42:32.040 Do you have screenshots like we just talked about? 42:32.040 --> 42:37.040 Do you have, did you update the tests for your changes? 42:38.040 --> 42:47.040 And, um, for us we hope folks make sure to remember to do all the, look at all these things by putting a checklist directly in the pull request template. 42:47.040 --> 42:57.040 So that it's right there for them to go through and that's so that we can see that they would at least check off the points that make sense for their, for this pull request. 42:57.040 --> 43:00.040 But there's one major part that's missing. 43:00.040 --> 43:06.040 I guess really quickly does anybody know what we have it covered yet in terms of re-re-ringing your own work. 43:06.040 --> 43:14.040 Super important. 43:14.040 --> 43:16.040 All right, you have to test it. 43:16.040 --> 43:23.040 You have to actually test it as closely as possible to how it's going to be end up being used in actual product. 43:23.040 --> 43:29.040 So, you know, if it's, I think it's an app and you can go and click, you added a button, go and click that button. 43:29.040 --> 43:34.040 And all the different ways you can think of and all the different configurations and make sure it does, it does what you did. 43:34.040 --> 43:39.040 Or if it's more back in, you still try to, like, really run and exercise the code. 43:39.040 --> 43:41.040 In the ways that it's going to be used in reality. 43:41.040 --> 43:44.040 Because if you don't click on it, it might just not work. 43:44.040 --> 43:53.040 Like, you don't know how many times I've tested PRs and the first, the moment I open it, again, an error and they're like, oh, the contributors like, oh, sorry. 43:53.040 --> 43:56.040 I must have tested, fixed, messed it up when I rebased it. 43:56.040 --> 44:00.040 You have to test your work and you have to test the latest version of your work. 44:01.040 --> 44:09.040 So, again, we have a checklist and really also really detailed guidelines on all the things you can think about testing. 44:09.040 --> 44:19.040 And that means that if somebody doesn't fill out this checklist, we can really point them to it and say, okay, please, please go through this without having to sort of hand hold every contributor. 44:19.040 --> 44:28.040 Okay, one last one, I think this is really important to talk about in 2026 is the use of AI. 44:28.040 --> 44:34.040 And our philosophy and that on humans is humans own the work and so I'm going to get into that. 44:34.040 --> 44:41.040 So, I think a lot of us who maintain open search projects these days really feel like we're drowning. 44:41.040 --> 44:46.040 Sorry, yes, I'm going to use our help. 44:46.040 --> 44:48.040 No, right now. 44:48.040 --> 44:55.040 So, we really feel like we're drowning in a sea of slop. 44:56.040 --> 45:06.040 And here is this an example of a polar quest we got recently and this is just a description for this moderately small change. 45:06.040 --> 45:11.040 You don't need to read it because it says all the things it doesn't need to say. 45:11.040 --> 45:18.040 Clearly written by an LLM, the check-self review checklist is not the one that we provided, it's the one that LLM made up. 45:18.040 --> 45:25.040 If you want curious what happens in the spare we close it without review, but there's a lot of this. 45:25.040 --> 45:32.040 And, you know, we're all trying to do for texture cells and really figure out how to move forward in this context. 45:32.040 --> 45:37.040 And a lot of projects have been adding AI use policies which, you know, they help a little. 45:37.040 --> 45:42.040 They definitely don't solve the whole problem, but I do think they help. 45:42.040 --> 45:48.040 And for anybody who's thinking like, oh, maybe it's just really good, which is just all work with the eyes, not with contributors. 45:48.040 --> 45:52.040 Do observe that third hand that they I created on this image for me. 45:52.040 --> 45:58.040 It really doesn't know how to make an umbrella without a hand holding it. 45:58.040 --> 45:59.040 All right. 45:59.040 --> 46:04.040 So, one way to think about the AI use policies, you can use it as a filter. 46:04.040 --> 46:11.040 So, when a PR submitted, we look at whether it follow the AI policy and other guidelines. 46:11.040 --> 46:14.040 And if it did, we really review the work. 46:14.040 --> 46:20.040 If it didn't, we don't try to review the work because it's not in the state that's ready for you. 46:20.040 --> 46:24.040 We just asked the contributor to read that. 46:24.040 --> 46:29.040 And if they fix it and now it follows the guidelines, great, we can review the work. 46:29.040 --> 46:35.040 If it doesn't, we close the pull request and warn the contributor that we won't be able to review their work. 46:35.040 --> 46:38.040 If they do it in this way. 46:38.040 --> 46:47.040 And we're really trying to minimize the time we spend on work that is just kind of LLM garbage. 46:47.040 --> 46:54.040 And I think philosophical, like a part of what's going on here is, you know, the way that open source succeeds is it's really a collaboration between people, 46:54.040 --> 46:57.040 the maintainers, the contributing community. 46:57.040 --> 46:59.040 We're all trying to work together. 46:59.040 --> 47:00.040 We're learning from each other. 47:00.040 --> 47:02.040 We're creating something better. 47:02.040 --> 47:04.040 And it's a given take, right? 47:04.040 --> 47:08.040 The contributors are contributing code to the contributing of their work. 47:08.040 --> 47:10.040 They're learning from the maintainers. 47:10.040 --> 47:12.040 My retainers might be learning from them. 47:12.040 --> 47:15.040 It's a human endeavor. 47:15.040 --> 47:21.040 And so, when somebody just takes my feedback and posts pasted into NLLM, 47:21.040 --> 47:27.040 and then paste with the LLM said back into the pull request, nobody's learning, nobody's going. 47:27.040 --> 47:33.040 And that's just not where it's worth spending our time. 47:33.040 --> 47:41.040 So, our A policy is much more detail than this, but the key highlights are that you as the human contributor have to understand, 47:41.040 --> 47:43.040 test and explain the work. 47:43.040 --> 47:47.040 You have to know what you're doing because if you're not providing this, 47:47.040 --> 47:50.040 I might as well work with NLLM myself, right? 47:50.040 --> 47:54.040 What is the value that you are bringing as a human to this? 47:54.040 --> 47:58.040 And you have to communicate clearly, concisely and accurately. 47:58.040 --> 48:02.040 And, you know, when we first saw the policy, we were missing the accurate piece, 48:02.040 --> 48:06.040 because I thought, of course, everybody's going to try to communicate accurately. 48:06.040 --> 48:11.040 But now you get pull requests where the description says one thing and the code does something else. 48:11.040 --> 48:16.040 And that's, again, as you saw, like with the island and the skull, 48:16.040 --> 48:18.040 like, that's even worse, right? 48:18.040 --> 48:26.040 Now, the contributors intentionally are not misleading the reviewers about what the changes do. 48:26.040 --> 48:31.040 And so, how can they be a trust in that situation? 48:31.040 --> 48:35.040 And you also have to communicate about points that actually need communicating. 48:35.040 --> 48:43.040 So, saying how many lines of changes you made in the PR description is not a thing that needs to be communicated. 48:43.040 --> 48:47.040 And it makes writing this, you know, this really long alum. 48:47.040 --> 48:53.040 PR descriptions make it very hard to actually get to the nuts of, like, what is important. 48:53.040 --> 48:59.040 And that might actually get missed with all the garbage around it. 48:59.040 --> 49:05.040 So, wrapping up, so what I've hope I've done here is for the maintainers. 49:05.040 --> 49:10.040 I laid out kind of with the kinds of things that you might want to put in the map for your project. 49:10.040 --> 49:14.040 Given some examples that you could use as a reference, if you're thinking about it. 49:14.040 --> 49:17.040 And then if you're contributing to somebody else's project, 49:17.040 --> 49:20.040 hopefully think about, you know, first of all, trust the map. 49:20.040 --> 49:22.040 If there is a map, please follow it. 49:22.040 --> 49:27.040 But then, for any kind of uncharted territory, these might be good starting points for you to think about 49:27.040 --> 49:33.040 to really clearly explain what you're doing and why and make you work easy and fun to review. 49:33.040 --> 49:38.040 So, hopefully the next time you submit a PR, it'll be a this beautiful little thing. 49:38.040 --> 49:40.040 And maintainer will be delighted to receive it. 49:40.040 --> 49:41.040 Thank you. 49:41.040 --> 49:51.040 Thank you.