WEBVTT 00:00.000 --> 00:17.600 So, thank you very much for your patience. 00:17.600 --> 00:23.200 We are going to start with the next talk with Lorna, and she's going to talk about what 00:23.200 --> 00:30.480 was called craft, better and a bit of experience for pensar projects, so with yours, Lorna. 00:30.480 --> 00:34.360 Thanks very much. 00:34.360 --> 00:40.440 If you are hoping to see a different talk in this slot, I'm sorry, your original speaker 00:40.440 --> 00:45.240 couldn't make it, and I was asked to fill in this slot. 00:45.240 --> 00:49.400 That means I didn't have a lot of warning, but I hope I have some content that's going 00:49.400 --> 00:54.480 to be useful to you, and we'll all get something from this experience. 00:54.480 --> 01:04.200 So hi, I'm Lorna, I am a very long-standing open source user, contributor, and maintainer, 01:04.200 --> 01:12.000 I've maintained projects that are just me, some that are much bigger, higher profile, 01:12.000 --> 01:18.040 everything in between, and also maintained projects as part of my employment in a couple 01:18.040 --> 01:20.040 of different roles. 01:20.040 --> 01:28.840 I want to talk to you today about developer experience, and how we can improve the developer 01:28.840 --> 01:39.080 experience throughout the different life cycle stages of open source. 01:39.080 --> 01:49.480 And when I talk about the open source life cycle, I mean that journey that we take, our 01:49.480 --> 01:59.760 own growth from first contributing to a project, and then perhaps becoming a maintainer, 01:59.760 --> 02:03.400 but that journey begins as a user. 02:03.400 --> 02:11.560 There's no project that we can ever become a contributor to, that we can't become a user 02:11.560 --> 02:18.680 in the first place, by understanding what the project is and what it does. 02:18.680 --> 02:26.280 The goal is to take people from using, to adopting, to championing the project, from getting 02:26.280 --> 02:33.160 involved, maybe opening issues, to starting to patch things, or triaging issues, and contributing 02:33.160 --> 02:40.760 in other ways, and perhaps one day, including them as part of your maintainer team. 02:40.760 --> 02:44.560 So how does the story begin? 02:44.560 --> 02:46.560 I love this to work. 02:46.560 --> 02:47.960 Beautiful. 02:47.960 --> 02:58.880 Let's talk about developer experience for users of your open source project, especially on 02:58.880 --> 03:06.280 a single person project, we sometimes get very focused on just our own needs, but if 03:06.280 --> 03:11.720 we want our projects to grow and to thrive, we need to welcome new people in and make that 03:11.720 --> 03:12.720 easy. 03:12.720 --> 03:18.960 The first thing you need to do is make sure that people can find your project when they 03:18.960 --> 03:21.720 need it. 03:21.720 --> 03:26.520 This is the Wireshark repo on GitHub. 03:26.520 --> 03:36.880 The way that you use the tags on the source hosting platforms really helps people to find 03:36.880 --> 03:41.160 your tool, even if they've never heard of it before. 03:41.160 --> 03:45.680 So this is a really good place to start for your project. 03:45.680 --> 03:50.320 The story project needs that little blurb, again, it comes up in search results when 03:50.320 --> 03:56.000 people are scanning the list, and you need to introduce what your project is, what it does, 03:56.000 --> 04:00.640 who it's for, if it's only for a particular text act, that would be useful for me to know 04:00.640 --> 04:03.280 as well. 04:03.280 --> 04:13.960 So work on those first impressions, the short window of your project, to help people to 04:13.960 --> 04:20.680 discover the project that they will then grow into. 04:20.680 --> 04:27.680 A read me is an art form, and there are lots of templates to help you do it well. 04:27.680 --> 04:32.400 I think one of the hard things about a read me is when your project begins, it needs 04:32.400 --> 04:38.800 like two paragraphs or something small, and by the time it is very popular in well-known, 04:38.840 --> 04:45.600 it needs something completely different, and it can be hard to return to focus on the 04:45.600 --> 04:54.240 read me throughout your project maturity journey. 04:54.240 --> 05:02.400 Sometimes if you are more code specialist, writing a read me can seem like a really, really 05:02.400 --> 05:04.760 hard problem. 05:04.760 --> 05:11.800 You may tell me, I'm not a writer, I don't know English well, I can't do it, it will 05:11.800 --> 05:21.680 be bad, it will be hard, I don't want to, and understand, right? 05:21.680 --> 05:28.200 But I can't support you in not doing a great job here. 05:28.200 --> 05:36.960 First of all, there are lots of resources, and your best effort is good enough. 05:36.960 --> 05:44.200 So when it comes to writing the read me and maybe some other documentation, find a template, 05:44.200 --> 05:51.240 set aside some time, show up, and try, and that is everything that I need, your projects 05:51.320 --> 05:55.000 will be better for that. 05:55.000 --> 06:00.400 The structure of the information that you share is important, a very, very long read 06:00.400 --> 06:05.960 me is almost as much of a problem as a very, very short one. 06:05.960 --> 06:12.320 In both cases the information I need, either isn't there, I can't find it. 06:12.320 --> 06:17.360 This is about technical communication, thinking about who you are writing for, who will 06:17.360 --> 06:27.760 be reading this, tell me what your project is, what it does, it is incredible how many open 06:27.760 --> 06:34.280 source projects I visit, but I can read the whole read me and still not know what this 06:34.280 --> 06:36.280 is. 06:36.280 --> 06:42.080 I'm looking for something in particular, but I don't know if I found it. 06:42.080 --> 06:44.240 Do some installation instructions. 06:44.240 --> 06:49.720 If they're massive, either it's very complicated or you support a lot of platforms and 06:49.720 --> 06:54.480 it's different for each one, consider moving those to a separate file. 06:54.480 --> 07:00.520 You can give the one line of dependency manager install, but if it's more complicated than 07:00.520 --> 07:06.680 that install thing, you might want to put that in a separate document. 07:06.680 --> 07:17.120 Please show me how to use it as well, because that's a very early hurdle to fall at. 07:17.120 --> 07:21.800 When you install something, if you can't use it, you are probably you are trying to 07:21.800 --> 07:26.360 a three project, it's likely that I'll use a different one if I can't understand how 07:26.360 --> 07:28.440 to succeed with yours. 07:28.440 --> 07:33.880 This is the beginning of our developer experience story, developer experience is about 07:33.880 --> 07:40.320 making developers confident and successful and efficient in what they do, and a good 07:40.320 --> 07:43.720 read me can really help. 07:43.720 --> 07:48.480 If you look at my GitHub history, you'll see that I have committed to a bunch of different 07:48.480 --> 07:53.400 projects or contributed to a bunch of different projects, but if you look more closely, nearly 07:53.400 --> 07:57.760 all of them are read me or docs fixes. 07:57.760 --> 08:03.800 This is important if you think that somebody else's project instructions could be improved 08:04.280 --> 08:11.600 You're bringing that new user perspective, I consider it your responsibility to open a 08:11.600 --> 08:19.720 pull request that improves those install instructions or that getting started usage instructions. 08:19.720 --> 08:27.160 With the further resources, you can link through to whatever you have, maybe other people 08:27.160 --> 08:32.160 have written about your project, maybe there's a documentation site published somewhere, 08:32.160 --> 08:39.440 please include some contact information, or at least the direction do you love people to open 08:39.440 --> 08:45.720 discussions on GitHub or GitHub to ask questions, or is there a better community for them 08:45.720 --> 08:47.680 to join for that? 08:47.680 --> 08:54.240 Just help your new users to connect with your project. 08:54.240 --> 09:01.560 Things that are too big for the read me, and sometimes that will mean you kept on expanding 09:01.560 --> 09:07.160 the read me on one day you realize this should not all be in one file, we're going to 09:07.160 --> 09:08.160 do refactoring. 09:08.160 --> 09:12.560 Now, if you're a developer, you already know how to do refactoring when you do it with 09:12.560 --> 09:15.240 words, it's exactly the same. 09:15.240 --> 09:20.120 You break it out into a separate function or a document, and you refer to it from the original 09:20.120 --> 09:24.280 context. 09:24.280 --> 09:30.080 In our code projects, documentation doesn't really really doesn't need to be complicated. 09:30.080 --> 09:39.360 Use a docs' code approach, so choose a text-based market format, mark down is very common, 09:39.360 --> 09:43.840 I'm a big fan of Restructured Text, which you'll commonly find in the Python community, 09:43.840 --> 09:44.840 getting a little round of applause. 09:44.840 --> 09:45.840 Thank you. 09:45.840 --> 09:50.280 It is the best format, and you will not change my mind. 09:50.280 --> 09:58.720 I've used them all, and just put files in a folder called Docs that are valid market, 09:58.720 --> 10:04.360 all of the software, the source control hosting sites will render it. 10:04.360 --> 10:07.120 This is all that users need. 10:07.120 --> 10:10.960 Put it in the repository, update it when your code updates. 10:10.960 --> 10:12.120 We're good. 10:12.120 --> 10:14.000 This doesn't need to be over-engineered. 10:14.000 --> 10:16.520 You don't need a website. 10:16.520 --> 10:21.560 This screenshot is a rendering of Restructured Text from Codeberg. 10:21.560 --> 10:25.840 It just doesn't need to be overly full. 10:25.880 --> 10:33.400 You can build your documentation by taking answers to issues or to emails and pasting them 10:33.400 --> 10:36.720 into mark down files in your Docs folder. 10:36.720 --> 10:41.840 Seriously, this will get you started. 10:41.840 --> 10:44.600 Publishing is optional. 10:44.600 --> 10:51.720 You might want to create a website from your Docs folder, and for that it's especially 10:51.720 --> 10:55.080 you have complex usage. 10:55.080 --> 10:57.280 You need to write some stuff down. 10:57.280 --> 11:00.520 That can be quite nice to give it the navigation as well. 11:00.520 --> 11:08.440 But typically, if it's a technical project, people will find their way. 11:08.440 --> 11:11.680 I know I already said this about writing. 11:11.680 --> 11:14.520 You maybe don't feel like an expert. 11:14.520 --> 11:21.680 But all open source projects are globally distributed, remote, asynchronous, 11:21.720 --> 11:22.240 right? 11:22.240 --> 11:25.240 We have to be writing things down. 11:25.240 --> 11:30.920 And even though this is a skill that you might use less than some of your other skills 11:30.920 --> 11:33.560 or a language that you don't use every day, 11:33.560 --> 11:37.920 still need you to write things down and trying, 11:37.920 --> 11:42.200 even though it's hard or even though you don't feel successful, 11:42.200 --> 11:44.160 is still the right thing to do for your project. 11:44.160 --> 11:48.320 And it massively multiplies developer experience. 11:48.360 --> 11:57.240 The other secret is that if you have documentation, people will update it. 11:57.240 --> 11:57.840 Right? 11:57.840 --> 12:01.880 If there's nothing there, you look like a project that doesn't care. 12:01.880 --> 12:05.840 But if there's something there, somebody allowed another file in the directory, 12:05.840 --> 12:09.080 or another section to the Markdown file, 12:09.080 --> 12:11.200 and we start to grow this thing together. 12:11.200 --> 12:17.120 So even small patchy documentation that you are not proud of, 12:17.160 --> 12:21.200 improves the developer experience on your open source project. 12:25.080 --> 12:28.040 I feel like I talked a lot about a lot of things that are not code. 12:32.400 --> 12:37.360 But I think the code and the user experience, 12:37.360 --> 12:38.800 the developer experience, 12:38.800 --> 12:44.560 isn't really important part of onboarding new users 12:44.560 --> 12:46.520 as part of our project. 12:47.840 --> 12:53.840 Follow conventions from your text stack, 12:53.840 --> 12:55.880 but don't depend on them. 12:55.880 --> 12:57.080 It's open source. 12:57.080 --> 12:58.960 But if I think in pilot on my machine, 12:58.960 --> 13:04.240 then I can use it, except I might not be super up to speed 13:04.240 --> 13:08.160 with the latest dependency management in Vala or whatever it is you're using. 13:08.160 --> 13:11.200 So like try and make it so, 13:11.200 --> 13:14.000 you don't need to tell me how to install node, 13:14.000 --> 13:16.560 but if you could try and use words that I could then Google 13:16.560 --> 13:21.560 or link to a, if you don't have NPM click here, that's enough. 13:21.960 --> 13:24.880 Remember that some of your users might be coming 13:24.880 --> 13:26.960 from another text stack and in open source, 13:26.960 --> 13:28.920 that's cool, actually. 13:28.920 --> 13:30.800 That's right, I don't want you to have 13:30.800 --> 13:33.200 the thing about rebuilding every tool in JavaScript 13:33.200 --> 13:35.920 because you don't know how to use another text stack. 13:35.920 --> 13:39.840 We change the world when we make our projects more accessible 13:39.840 --> 13:44.520 to people from different technical stacks or different levels of knowledge. 13:44.520 --> 13:48.280 But that you want to package your tool 13:48.280 --> 13:52.080 in as many ways as you can that makes sense for you 13:52.080 --> 13:55.840 and that is sustainable to maintain. 13:55.840 --> 13:58.480 And those two things can be a bit of a struggle. 13:59.680 --> 14:04.320 Find your sweet spot and graciously allow the community 14:04.320 --> 14:05.720 to help you. 14:05.720 --> 14:08.840 Like if somebody's asking for a package format, 14:08.840 --> 14:11.240 ask them if they would like to contribute that 14:11.240 --> 14:13.240 or help to maintain that. 14:13.280 --> 14:17.040 Because if they care about it, you can join forces. 14:17.040 --> 14:22.280 And especially when you are currently a soul maintainer, 14:22.280 --> 14:24.520 it can be difficult to let that next person in. 14:28.120 --> 14:33.120 If your project has or could have extensions or plugins, 14:35.840 --> 14:38.880 those kinds of things, just make a space on the read me 14:38.880 --> 14:42.120 to link to where other people are publishing their things. 14:42.200 --> 14:45.520 Link to where someone gave a talk about your tool 14:45.520 --> 14:48.720 or you showed some examples about it. 14:48.720 --> 14:51.400 Link to some blog posts if you know about them. 14:51.400 --> 14:55.640 Again, once there's a section for this stuff, 14:55.640 --> 14:57.760 people will show up and add things 14:57.760 --> 15:00.760 because you show that you want it. 15:00.760 --> 15:04.760 When we rolled the first release of the new Open API overlays, 15:04.760 --> 15:09.520 specification, I was a bit frustrated that I didn't. 15:09.520 --> 15:12.880 I only knew a couple of tools that were using it. 15:12.880 --> 15:16.000 So I put a section in the read me, listing both tools 15:16.000 --> 15:20.480 and sure enough, three others showed up almost immediately. 15:20.480 --> 15:22.920 So asking people, hey, tell me about a thing. 15:22.920 --> 15:24.640 Didn't go very well. 15:24.640 --> 15:27.640 But you know, the list is over there. 15:27.640 --> 15:29.360 People came and put themselves on the list. 15:29.360 --> 15:30.120 So that was cool. 15:33.080 --> 15:34.320 Try to make this approachable, 15:34.320 --> 15:38.080 especially at the user stage. 15:38.080 --> 15:41.800 People might not already be insiders 15:41.800 --> 15:44.600 to the project that text, or whatever. 15:44.600 --> 15:49.680 But we want people to join our Open Source family 15:49.680 --> 15:52.720 to choose Open Source solutions over proprietary solutions 15:52.720 --> 15:55.480 and to be able to succeed. 15:55.480 --> 15:58.680 I recently tried to patch the help file for it. 15:58.680 --> 16:00.960 I'm not going to name the tool because it isn't there. 16:00.960 --> 16:03.280 For a CLI project. 16:03.280 --> 16:05.600 So there, dash dash help output. 16:05.600 --> 16:07.160 I didn't find it very helpful. 16:07.160 --> 16:08.960 And I sent them a patch. 16:08.960 --> 16:11.680 And they linked me to the last time someone 16:11.680 --> 16:13.280 tried to patch their help output. 16:13.280 --> 16:15.000 And the response was basically, 16:15.000 --> 16:17.240 anyone who doesn't know how to use a man page 16:17.240 --> 16:18.560 shouldn't be using the CLI. 16:22.560 --> 16:25.240 A lot of modern CLI tools don't have a man page. 16:25.240 --> 16:27.560 I guess that's why I didn't look for it. 16:27.560 --> 16:31.400 So that's a terrible developer experience. 16:31.400 --> 16:33.640 I'm not aware of any competing tools sadly. 16:33.640 --> 16:36.280 So I am stuck with it. 16:36.280 --> 16:39.400 But that's the opposite of what I want from you. 16:39.400 --> 16:42.640 It would be so easy to add a little extra explanation 16:42.640 --> 16:44.080 into the help output. 16:44.080 --> 16:46.600 And allow anyone who has installed this either 16:46.600 --> 16:48.200 from the Open Source project, or it's actually 16:48.200 --> 16:51.000 packaged by a bunch of the distros. 16:51.000 --> 16:53.360 So they haven't come through the GitHub repository 16:53.360 --> 16:57.160 with the rape me to know how to succeed with the project. 17:01.160 --> 17:02.960 All right, that was users. 17:02.960 --> 17:06.160 Let's talk about contributors. 17:06.160 --> 17:11.880 Contributors are a people who come and help our project. 17:11.880 --> 17:16.760 And they stay until the wind changes. 17:16.760 --> 17:18.680 That says it should be. 17:18.680 --> 17:21.280 No, it's not a commitment for life. 17:21.280 --> 17:23.600 They're not making us any promises. 17:23.600 --> 17:26.480 But anyone who comes and makes your project 17:26.480 --> 17:30.360 a little bit better is like some kind of gift. 17:31.320 --> 17:35.080 The first thing you really need is a code of conduct. 17:38.120 --> 17:40.840 I know this has been controversial in the past. 17:40.840 --> 17:43.080 And maybe you don't care about the code of conduct. 17:43.080 --> 17:43.880 That's all right. 17:43.880 --> 17:45.640 Not telling you you should care. 17:45.640 --> 17:48.440 But if you would like contributors, 17:48.440 --> 17:51.000 some of those contributors will care. 17:53.640 --> 17:56.200 And if you are the kind of person who runs your project 17:56.200 --> 17:59.480 along lines where other people can safely get involved, 17:59.640 --> 18:00.880 then let's write that down. 18:00.880 --> 18:04.320 And let's help those people feel confident 18:04.320 --> 18:06.360 that they can safely get involved. 18:09.440 --> 18:14.440 The code of conduct is also there as a what if. 18:17.000 --> 18:21.240 We've all heard horror stories of things that happen. 18:21.240 --> 18:25.760 What if you have a bad actor in your project? 18:25.800 --> 18:30.480 What if someone's behavior is so bad 18:30.480 --> 18:33.240 that you need a procedure to remove them from the project? 18:34.600 --> 18:37.160 The code of conduct sets the tone. 18:38.120 --> 18:40.680 It is the, we don't do that here. 18:42.000 --> 18:44.200 In written format. 18:44.200 --> 18:48.320 And I think it can back you up as a maintainer, 18:48.320 --> 18:51.400 as much as make you welcome as a contributor. 18:52.240 --> 18:56.400 If you are a company maintaining open source, 18:58.800 --> 19:01.200 this becomes even more important 19:01.200 --> 19:03.680 because not all publicity is good publicity. 19:06.680 --> 19:11.040 You, and this can be a bit weird for companies 19:11.040 --> 19:12.920 who are new to open source. 19:12.920 --> 19:15.480 They made a thing, they published it once. 19:15.480 --> 19:16.240 They think it's nice. 19:16.240 --> 19:17.320 They're going to get a big community 19:17.320 --> 19:20.480 that are then going to buy the commercial product, whatever. 19:20.480 --> 19:25.480 So, explaining this like hacker meritocracy 19:25.840 --> 19:29.680 and the code of conduct to organizations. 19:29.680 --> 19:31.320 I've done it multiple times in my career. 19:31.320 --> 19:33.000 It's always an adventure. 19:34.480 --> 19:36.240 But it's very important. 19:36.240 --> 19:39.840 And for that, I always have an internal 19:39.840 --> 19:42.800 to the company document that says, 19:42.800 --> 19:46.720 who is responsible for noticing this problem? 19:46.720 --> 19:49.240 And what is the procedure? 19:50.240 --> 19:54.240 And it can be as simple as, you know, 19:55.240 --> 19:57.400 all three members of this sub team 19:57.400 --> 20:00.360 will be subscribed to all notifications 20:00.360 --> 20:02.680 on the repository at all times. 20:02.680 --> 20:04.800 And if there's a problem, 20:04.800 --> 20:09.160 you will, from the wider Ospo DevRel team, 20:09.160 --> 20:13.080 who ever you trust to know this community 20:13.080 --> 20:16.400 and work on it, three of you will sit down in a meeting 20:16.400 --> 20:18.280 and take minutes and agree what to do 20:18.280 --> 20:20.640 and someone will do it. 20:20.640 --> 20:22.160 So, it's time zone safe. 20:22.160 --> 20:26.080 You don't need to wake me to wake up and bless your activities. 20:26.080 --> 20:28.120 If there's a problem going off, 20:28.120 --> 20:31.400 bit you follow this, you write it down and you do it. 20:31.400 --> 20:33.480 It's such a short document. 20:34.720 --> 20:36.720 I have never needed it yet. 20:36.720 --> 20:37.720 I'm going to touch the wood. 20:37.720 --> 20:40.040 I don't want to jinx myself, 20:40.040 --> 20:41.840 but it has to be there 20:41.840 --> 20:43.720 and especially if you're an organization. 20:43.720 --> 20:48.480 I think a code of conduct is not hard. 20:48.480 --> 20:50.920 You probably already run your project 20:50.920 --> 20:54.400 in a perfectly code of conduct acceptable way. 20:54.400 --> 20:56.320 Pick one, write it down. 20:56.320 --> 20:58.720 There's a bunch of really good resources. 20:58.720 --> 21:01.160 GitHub will prompt you. 21:01.160 --> 21:03.480 The to-do group who are, 21:03.480 --> 21:05.240 they do a bunch of Ospo type things. 21:05.240 --> 21:09.920 The Open Source Program offices also have a lot of resources. 21:09.920 --> 21:11.800 Every project is different. 21:11.800 --> 21:14.320 The right code of conduct might be different for you, 21:14.320 --> 21:16.320 but go there and that will help you. 21:18.880 --> 21:19.720 Okay. 21:23.720 --> 21:25.440 Let's talk about the contributing file. 21:26.880 --> 21:28.840 The contributing file isn't interesting one. 21:28.840 --> 21:31.560 It's where we write down how we run our project. 21:33.120 --> 21:35.000 This is really important. 21:35.000 --> 21:37.440 Even if you are a soul maintainer, 21:38.600 --> 21:40.600 unless you never think about anything else 21:40.600 --> 21:42.080 and you never forget anything. 21:43.400 --> 21:45.680 Neither of those things is true. 21:45.680 --> 21:47.240 So you need a contributing file. 21:49.280 --> 21:54.280 And this should be everything a new user needs to contribute. 21:57.400 --> 22:01.840 A new user is also anyone who has slept 22:01.840 --> 22:03.680 since they lasted this. 22:05.200 --> 22:09.400 Especially if you work on a lot of different projects 22:09.400 --> 22:11.240 and different things. 22:11.240 --> 22:13.920 So the way that I typically think about the contributing file 22:13.920 --> 22:17.840 is a bunch of high-level categories 22:17.840 --> 22:20.600 of the kinds of things you need to cover. 22:22.840 --> 22:26.280 The philosophy, do you actually want contributions? 22:26.280 --> 22:28.240 People should read the contributing file 22:28.240 --> 22:29.640 before they contribute. 22:29.640 --> 22:34.120 Everybody knows that the web interfaces prompt you to read it. 22:34.120 --> 22:37.760 If you don't want contributions, just say so. 22:40.360 --> 22:42.400 The mechanics of how does that work 22:42.400 --> 22:45.080 at a branch's issues requirements or what? 22:46.360 --> 22:48.280 A bit of a code base overview 22:48.280 --> 22:50.080 where to find things in the project, 22:50.080 --> 22:54.760 how it interconnects if your project is made of multiple repose. 22:54.760 --> 22:58.800 That kind of thing architecture diagrams go a massively long way. 22:58.800 --> 23:01.440 I would like to see more of those in public projects. 23:01.440 --> 23:03.720 We do it for our company. 23:03.720 --> 23:07.200 Stuff, I don't so often see it in the external ones. 23:08.160 --> 23:11.000 Any information about the quality checks 23:11.000 --> 23:15.040 and then how to actually deliver a finished pull request. 23:15.040 --> 23:19.440 So if we look at some of those a little bit more closely. 23:21.000 --> 23:23.040 You know, we say patch is welcome, 23:23.040 --> 23:24.960 meaning stop complaining to me, 23:24.960 --> 23:26.960 not meaning patches welcome at all. 23:28.000 --> 23:30.720 Your contributing file should make it clear 23:30.720 --> 23:34.600 if patches are actually welcome. 23:34.760 --> 23:37.880 There are loads of reasons why patches aren't welcome. 23:37.880 --> 23:41.040 It's completely fine that patches are not welcome. 23:41.040 --> 23:45.280 And maybe it's, you're just publishing something, 23:45.280 --> 23:47.680 but this isn't the place that it gets changed. 23:47.680 --> 23:49.840 You can't accept patches. 23:49.840 --> 23:52.840 I used to work for a company that had its product 23:52.840 --> 23:54.760 was a bunch of APIs, 23:54.760 --> 23:57.640 and we published all of the open API descriptions 23:57.640 --> 23:59.160 in a public repository. 24:00.440 --> 24:04.440 You can't add end points to our API document 24:04.440 --> 24:06.880 documentation in this setting. 24:06.880 --> 24:10.360 There's an API change process of which these are the output. 24:10.360 --> 24:12.840 So we're closed to patches 24:12.840 --> 24:15.480 because that's not how the change process works. 24:16.680 --> 24:19.400 I'm publishing this as a resource for users. 24:20.760 --> 24:23.800 Corporate projects that really actually 24:23.800 --> 24:26.160 don't want changes from anyone else. 24:27.880 --> 24:30.560 However you feel about this, 24:30.600 --> 24:34.400 it would be better if they were upfront about it. 24:35.400 --> 24:40.400 It wasn't until elastic changed their license 24:41.360 --> 24:44.240 and I became part of the open search fork 24:44.240 --> 24:45.520 that I realized 24:46.680 --> 24:51.320 elastic has an accepted patches from anyone else in years. 24:51.320 --> 24:54.320 They're actually not open to contribution. 24:54.320 --> 24:57.760 And that's fine, as your project, you say what you want, 24:57.760 --> 25:02.240 but let's make that clearer in the contributing files. 25:03.720 --> 25:07.480 Sometimes it's a community driven project, 25:07.480 --> 25:10.760 and you're very open to patches, right? 25:10.760 --> 25:14.120 Patches, please, your contributing files 25:14.120 --> 25:15.520 should make that clearer as well. 25:17.240 --> 25:22.240 Remember also that people might fork your project 25:23.600 --> 25:27.000 they still need to be able to run it, build it, 25:27.000 --> 25:29.520 understand how the moving parts work. 25:29.520 --> 25:32.480 You might not want their changes contributed upstream, 25:33.640 --> 25:35.680 or they might not want to. 25:35.680 --> 25:37.320 They use case might be so specific 25:37.320 --> 25:40.480 that it makes no sense to be in the main project. 25:40.480 --> 25:42.080 And that's okay. 25:42.080 --> 25:44.320 So they still need the instructions 25:44.320 --> 25:47.200 of how to operate and maintain and build 25:47.200 --> 25:48.520 and contribute to the project, 25:48.520 --> 25:52.920 even if that code never lands in the original project. 25:52.920 --> 25:56.760 I used to run a fork of the reduckly serialized, 25:56.760 --> 25:58.480 a linting tool. 25:58.480 --> 26:01.960 It's a linter, it has lots of different output formats. 26:01.960 --> 26:05.920 All of them look terrible with a huge font size, 26:05.920 --> 26:07.960 and I do a lot of talks and demos. 26:07.960 --> 26:09.800 So I had my own fork of the project, 26:09.800 --> 26:12.000 which had a different output formatter. 26:12.000 --> 26:13.800 We don't want this in the main project, 26:13.800 --> 26:16.280 makes no sense, but I need it 26:16.280 --> 26:18.600 when I'm taking screenshots and showing things to people, 26:18.600 --> 26:20.920 just because of the way the white space works. 26:23.360 --> 26:26.240 Being upfront about the mechanics, 26:26.240 --> 26:29.440 moving parts of contribution, 26:29.440 --> 26:32.600 helps insiders on the project, 26:32.600 --> 26:35.240 as much as it helps outside us. 26:35.240 --> 26:38.000 I'm a maintainer on OpenAPI. 26:38.000 --> 26:41.000 We have eight official committers, 26:41.000 --> 26:43.160 three or four other people who have some level 26:43.160 --> 26:46.160 of access to other parts of the project, 26:46.160 --> 26:49.000 and a very big audience of contributors. 26:50.880 --> 26:53.840 Getting everybody to precisely do the correct thing 26:53.840 --> 26:56.080 with the branching and releasing and everything, 26:56.080 --> 26:59.080 would be impossible if we didn't write this down. 26:59.080 --> 27:01.000 I work on this project all the time. 27:01.000 --> 27:03.520 I refer to the contributing died all the time. 27:04.520 --> 27:06.640 So it helps you as much as anybody. 27:08.880 --> 27:12.040 So write down the branching strategy. 27:12.040 --> 27:16.040 Do you require an issue to be created for a pull request 27:16.040 --> 27:18.080 before a pull request? 27:18.080 --> 27:20.400 One of the requirements for a pull request, 27:20.400 --> 27:24.000 I will normally reject anything that doesn't have a description 27:24.000 --> 27:25.960 on the basis that if you can't write a description, 27:25.960 --> 27:27.560 what else did you not bother to do? 27:28.920 --> 27:31.040 It always says that in the contributing guide. 27:33.000 --> 27:36.000 I'm not sure it's popular, but it works really well. 27:38.640 --> 27:43.120 Are there naming conventions that would cause branch naming, 27:43.120 --> 27:45.520 folder naming, I don't know, plug in naming, 27:45.520 --> 27:50.200 that would cause your pull request to be rejected? 27:50.200 --> 27:52.040 Write them down. 27:52.040 --> 27:53.600 Let me know before I build it. 27:53.600 --> 27:57.280 I'll open the pull request, it needs to be in the contributing file. 27:57.280 --> 28:01.080 If there are tests to run quality checks, that kind of thing, 28:01.080 --> 28:03.280 there's need to be there as well. 28:03.280 --> 28:06.520 I think the biggest thing with the mechanics 28:06.520 --> 28:11.960 on an open source project is having a well-maintained issue 28:11.960 --> 28:13.520 backlog. 28:13.520 --> 28:15.240 If someone opens an issue and you don't want that 28:15.240 --> 28:17.720 in your project, close it. 28:17.720 --> 28:20.040 Don't let me spend the whole weekend building it 28:20.040 --> 28:23.560 and then tell me you don't want it, close the issue. 28:23.560 --> 28:27.360 If there's something you'd really like help with, 28:27.360 --> 28:31.880 tag it, the help wanted tag is very common across GitHub. 28:31.880 --> 28:36.320 If people are asking questions, or suggesting things 28:36.320 --> 28:39.800 and you have an opinion, you need to respond 28:39.800 --> 28:43.120 because without your input, those things can't move forward. 28:45.240 --> 28:49.600 Obviously, you should do, as I say, and not as I do, 28:49.600 --> 28:52.120 please don't go and stalk all of my GitHub projects. 28:52.120 --> 28:54.400 They're not all beautiful. 28:54.400 --> 28:56.360 And I'm really good at closing issues. 28:56.360 --> 28:57.960 That's my super power. 29:00.280 --> 29:01.840 OK. 29:01.840 --> 29:05.840 When we work on software projects inside an organization, 29:05.840 --> 29:08.160 we talk about a definition of done. 29:08.160 --> 29:13.000 Done isn't it works on my computer in my branch. 29:13.000 --> 29:16.040 Done is it's actually shipped to a production 29:16.040 --> 29:19.400 or it's in a release or whatever. 29:19.400 --> 29:24.120 What does that look like for your open-source project? 29:27.320 --> 29:30.440 Let's write that down in the contributing file. 29:30.440 --> 29:34.680 Do you require a documentation patch? 29:34.680 --> 29:39.280 And if you're going to reject a poll request that doesn't have one, 29:39.280 --> 29:41.760 then you require it and it needs to be in the contributing guide. 29:41.760 --> 29:45.000 So people know that that's expected of them. 29:45.000 --> 29:48.440 Do you require additional tests? 29:48.440 --> 29:52.360 Or the tests to pass, I guess, probably? 29:52.360 --> 29:55.240 I'm going to write that down. 29:55.240 --> 30:01.520 Is it expected that every change will come with a change-log entry? 30:01.520 --> 30:02.840 What's the format of that? 30:02.840 --> 30:04.400 Do you use a specific tool? 30:04.400 --> 30:07.440 Does it need to go in a specific location? 30:07.440 --> 30:09.120 Right, it's in the contributing file. 30:09.120 --> 30:11.960 It's not good enough to allow new contributors 30:11.960 --> 30:15.600 to open poll requests, and then ask them to do eight more things 30:15.600 --> 30:16.760 in one at a time. 30:16.760 --> 30:19.320 That is not a good developer experience. 30:19.320 --> 30:22.240 If that happened to you at work, you would quit. 30:22.240 --> 30:25.720 So let's not do it in our open-source projects. 30:29.440 --> 30:30.480 Every project is different. 30:30.480 --> 30:33.960 There's probably something else that is needed in your project. 30:33.960 --> 30:36.640 Could you please think what that is and write that down to? 30:36.640 --> 30:38.680 Because I didn't get it to put it on my slide. 30:42.000 --> 30:45.120 Speaking of things that would make you quit your job, 30:45.120 --> 30:49.000 if they happened at work, let's not do them in open-source, 30:49.000 --> 30:51.440 local development setups. 30:51.440 --> 30:57.000 There must be a way for a new person to run this stuff, 30:57.000 --> 31:02.200 themselves, so they can work on contributions. 31:02.200 --> 31:06.000 You know how to run your code locally. 31:06.000 --> 31:08.720 Help someone else to do the same. 31:08.720 --> 31:12.400 Because without this, they can't make changes. 31:12.400 --> 31:15.720 You should never be in the situation 31:15.720 --> 31:19.120 where you have to push code to somewhere 31:19.120 --> 31:21.360 to see if it was any good or not. 31:21.360 --> 31:23.240 This is not a good feedback loop. 31:23.240 --> 31:29.040 This is not an efficient and respectful use of your time. 31:29.040 --> 31:33.360 Let's not do that. 31:33.360 --> 31:34.600 Let's make it easy. 31:37.320 --> 31:41.680 Make sure you have documentation on how to set things up locally. 31:41.680 --> 31:43.640 And if you don't know how to set it up for Windows, 31:43.640 --> 31:45.560 the documentation can say that, 31:45.560 --> 31:50.240 probably someone will explain to you how to do it. 31:50.240 --> 31:52.400 I can't believe you didn't know that. 31:52.400 --> 31:53.640 It doesn't matter what your attitude is, 31:53.640 --> 31:55.280 I've got the instructions in my project now. 31:55.280 --> 31:56.280 Thanks. 31:59.560 --> 32:01.760 Encourage people to contribute. 32:01.760 --> 32:04.640 Remember that the gaps in the documentation are as useful 32:04.640 --> 32:07.520 or much better than there being no documentation, 32:07.520 --> 32:11.360 because people will come and fill us in a little bit, usually. 32:12.320 --> 32:17.800 Reviewing podcasts in open source is a transferable skill 32:17.800 --> 32:20.320 from other projects, and I work on code, 32:20.320 --> 32:24.080 but also on pros, different types of assets. 32:24.080 --> 32:28.000 It's a very, very, very transferable skill. 32:28.000 --> 32:32.560 It's one that I don't feel that we necessarily teach 32:32.560 --> 32:38.720 or study deeply through the course of our careers. 32:38.800 --> 32:42.000 And this might be controversial. 32:42.000 --> 32:43.280 Maybe controversial. 32:43.280 --> 32:47.520 This might be controversial, but I think GitHub 32:47.520 --> 32:50.960 and all the equivalent platforms encourage 32:50.960 --> 32:53.520 very poor reviewing practice. 32:55.000 --> 32:59.520 Because I'm not just throwing mud, 32:59.520 --> 33:05.000 because the hard part of really good pull request reviewing 33:05.080 --> 33:08.080 is thinking about the big picture, 33:09.200 --> 33:12.480 thinking about how things fit together, 33:12.480 --> 33:15.480 and thinking about what isn't here. 33:16.840 --> 33:18.280 What do we forget? 33:18.280 --> 33:20.920 Because that's what will really hurt you 33:20.920 --> 33:23.800 is pull requests that change one thing, but not another. 33:26.200 --> 33:31.200 Opening the diff is 100% the wrong way 33:31.760 --> 33:33.760 to review a pull request. 33:33.920 --> 33:38.640 Just eyeballing a diff and deciding is not how you review 33:38.640 --> 33:39.800 a pull request. 33:42.080 --> 33:45.720 Big picture, do we want this feature? 33:45.720 --> 33:49.200 Does this pull request make things better? 33:49.200 --> 33:51.600 For the project, for some audience of the project, 33:51.600 --> 33:54.440 for some part of it, is this a win? 33:57.240 --> 34:00.160 Do you want this feature in your project? 34:00.160 --> 34:01.920 Because if you accept it, 34:01.960 --> 34:04.640 you will support it until the end of time. 34:08.400 --> 34:10.120 You have to really want it. 34:11.600 --> 34:13.840 Don't let people scope create this thing out, 34:13.840 --> 34:14.880 because what they're actually doing 34:14.880 --> 34:17.440 is scoping your maintenance burden. 34:17.440 --> 34:18.800 If it's good, it's good. 34:18.800 --> 34:20.920 But you don't need to have a yes to everything. 34:23.640 --> 34:28.640 If you are a company who owns an open source repository, 34:28.640 --> 34:31.360 you need to make absolutely sure that somebody 34:31.360 --> 34:35.400 or ideally multiple people are getting those notifications 34:35.400 --> 34:37.200 and that they have some time assigned 34:37.200 --> 34:39.680 or they can get some time to work on them. 34:39.680 --> 34:42.520 Otherwise, that is not open source. 34:42.520 --> 34:44.160 You've just thrown the code over the hedge. 34:44.160 --> 34:46.120 That's source available. 34:46.120 --> 34:48.240 Here's the code that's nobody here, 34:48.240 --> 34:49.640 not a healthy project. 34:52.160 --> 34:55.840 Just like reviewing pull requests in every other context, 34:55.840 --> 34:59.240 be clear, be constructive. 34:59.240 --> 35:04.000 I always tell people, you need to say, 35:04.000 --> 35:07.280 if there are about all of the showstopper things, 35:07.280 --> 35:08.680 the things that are so serious 35:08.680 --> 35:11.040 that this pull request cannot be merged, 35:11.040 --> 35:12.640 all of those need to be mentioned 35:12.640 --> 35:15.560 in your first response to the pull request. 35:15.560 --> 35:25.360 However, you, if there are other things that you would've done 35:25.360 --> 35:28.920 differently, you're going to maximum of three, 35:30.080 --> 35:32.760 and after that, you're just nitpicking. 35:32.760 --> 35:36.280 If you would not stop the pull request from being merged 35:36.280 --> 35:38.320 and you do not need to mention it, 35:38.320 --> 35:39.920 we just need to move on forward 35:39.920 --> 35:43.960 or you need better automation, better contributing guides 35:43.960 --> 35:45.360 and so on. 35:45.360 --> 35:49.600 Try to apply the same feedback to everybody, 35:49.600 --> 35:54.600 insiders, familiars, outsiders, newbies, unknowns, 35:54.600 --> 35:59.600 people with identifiably female handles and avatars 36:00.680 --> 36:06.040 try to be consistent because I think you are working 36:06.040 --> 36:08.280 in the open and it's very visible 36:08.280 --> 36:09.600 if that's not what's happening. 36:12.320 --> 36:15.480 The automation is really important for contributors. 36:15.480 --> 36:18.480 It's so frustrating to open a pull request 36:18.480 --> 36:20.160 and then find out there are eight other things 36:20.160 --> 36:21.640 that no one told you about. 36:21.640 --> 36:26.640 So try to set up your project to give immediate feedback 36:28.480 --> 36:30.880 on the things that you care about 36:30.880 --> 36:34.720 and this could be quality standards coding formatting, 36:34.720 --> 36:37.440 spell checks, all that stuff. 36:37.440 --> 36:41.000 Anything you can automate, automate. 36:41.000 --> 36:43.400 This reduces the work for you. 36:43.400 --> 36:46.360 It reduces the number of round trips for a contributor. 36:46.360 --> 36:49.400 It just makes the situation much, much clearer. 36:50.400 --> 36:52.960 And I really think that this improves. 36:52.960 --> 36:55.320 I've got it in the section about developer experience 36:55.320 --> 36:59.160 for contributors, but sometimes you are that contributor. 36:59.160 --> 37:01.040 You probably patch your own project 37:01.040 --> 37:02.800 and all this stuff makes it easier. 37:04.800 --> 37:09.040 I also said the thing about being prepared 37:09.040 --> 37:14.040 and one more commit, especially for open source, 37:14.840 --> 37:19.040 where a bunch of the contributions are drive by. 37:20.240 --> 37:22.560 This person came in, saw a thing, fix a thing. 37:22.560 --> 37:24.160 You're never gonna see them again. 37:26.760 --> 37:29.920 You probably, you won't always get a response. 37:29.920 --> 37:31.800 If you respond and say, 37:31.800 --> 37:34.840 ah, you also need to update this other thing. 37:36.040 --> 37:37.320 You may not get a response. 37:37.320 --> 37:40.560 So be prepared to just say thank you. 37:40.560 --> 37:42.080 Add the extra commit yourself. 37:42.080 --> 37:44.040 Maybe they forgot to add a new docs page, 37:44.040 --> 37:45.600 link into the Nav bar. 37:45.600 --> 37:48.200 One of them, add one more commit. 37:48.200 --> 37:51.920 And as you review and merge it at the same time. 37:51.920 --> 37:54.120 Be prepared to do that last piece, 37:54.120 --> 37:55.920 rather than constantly pushing it back, 37:55.920 --> 37:59.240 which you might do in an internal project. 37:59.240 --> 38:00.400 Although if you're my co-maintener, 38:00.400 --> 38:01.920 then I'm gonna push it back to you. 38:06.320 --> 38:08.680 Developer experience for maintainers. 38:08.680 --> 38:11.920 My goal is not to make work for maintainers. 38:11.920 --> 38:14.920 It's not to raise expectations for maintainers. 38:14.920 --> 38:17.200 I am a maintainer and I became passionate 38:17.200 --> 38:22.200 about all of this stuff because I see how important it is 38:22.200 --> 38:26.200 that we make excellent use of not just the time, 38:27.400 --> 38:30.800 but also the expertise of the people 38:30.800 --> 38:35.200 who are maintaining voluntarily or as part of their job, 38:35.200 --> 38:37.480 either way, there's pressure on them, 38:37.480 --> 38:40.560 maintaining the projects upon which we depend. 38:42.080 --> 38:44.280 Developer experience means 38:45.480 --> 38:48.640 helping developers to be competent and efficient 38:48.640 --> 38:50.440 and successful. 38:50.440 --> 38:53.040 And I want that for maintainers as well. 38:54.160 --> 38:57.000 One of the big things that I do is I have, 38:57.000 --> 39:01.200 whether I have a checklist for poor request reviews. 39:02.200 --> 39:06.080 Now, this is really important 39:06.080 --> 39:08.160 because it means that you can just look at the list. 39:08.160 --> 39:09.800 You don't need to think about 39:09.880 --> 39:13.600 what are the things I check for poor requests on this project? 39:13.600 --> 39:16.680 Especially if you don't work on it every day, 39:16.680 --> 39:18.520 but here's a quick checklist of things, 39:18.520 --> 39:21.880 you know, do you need a change alarm put it in the list? 39:21.880 --> 39:23.760 It is also a brilliant way. 39:23.760 --> 39:25.760 It reduces your mental load. 39:26.720 --> 39:30.360 It lets contributors know what they need to do 39:30.360 --> 39:32.360 because they can look at the list 39:32.360 --> 39:33.800 because it's gonna be Dox's code. 39:33.800 --> 39:35.640 It's gonna be public in your repository. 39:36.560 --> 39:39.840 It helps to onboard new maintainers. 39:39.840 --> 39:44.840 And sometimes projects get abandoned or assigned. 39:46.120 --> 39:49.080 Bad things happen, you might not be here to hand it over. 39:49.080 --> 39:51.080 You might just, somebody might offer to help 39:51.080 --> 39:52.920 at a time when you're in the sandwich pressure, 39:52.920 --> 39:54.520 you can't onboard them. 39:54.520 --> 39:56.520 To this helps. 39:59.360 --> 40:02.800 It also helps with the thing about making consistent reviews. 40:02.920 --> 40:04.600 Everyone knows what's expected. 40:06.000 --> 40:08.000 I am a person who, 40:09.160 --> 40:11.320 I'm considered myself a bystander 40:11.320 --> 40:13.160 on all open source projects. 40:13.160 --> 40:15.720 I go, will happily comment on a poll request 40:15.720 --> 40:18.280 on a project like, don't have commit access to. 40:18.280 --> 40:21.640 If it's clear to me that I've got feedback that can be helpful. 40:21.640 --> 40:25.720 Like it's not, we don't gatekeep contributions. 40:25.720 --> 40:27.760 They're in the open for a reason. 40:27.760 --> 40:31.640 And having the review checklist can allow you to enable 40:31.640 --> 40:34.520 your sort of triage level project members 40:34.520 --> 40:36.200 to be part of the review process. 40:36.200 --> 40:38.040 And that's something that we do at OpenAPI 40:38.040 --> 40:39.560 and I found it very helpful. 40:41.880 --> 40:45.320 Simon Wilson, who you might know from the sort of Python space 40:45.320 --> 40:47.680 he's been writing about AI a lot this year, 40:48.640 --> 40:53.800 he has an absolutely unimaginable number of projects 40:53.800 --> 40:56.840 on his GitHub and I have always wondered how that works. 40:56.840 --> 40:59.720 He wrote a really great blog post earlier in the year 40:59.720 --> 41:03.480 about how he does that with the constant context switch 41:03.480 --> 41:05.920 for all these little projects. 41:05.920 --> 41:07.760 They all have automated tests 41:07.760 --> 41:09.800 and they all have some documentation. 41:09.800 --> 41:12.680 And it means that he can always switch in, pick it up, 41:12.680 --> 41:15.760 read his own instructions to himself and move forward. 41:15.760 --> 41:17.760 And we can also use those resources 41:17.760 --> 41:19.800 if we get involved in those projects. 41:21.600 --> 41:24.120 Again, do as I say, not as I do. 41:24.120 --> 41:26.080 But I found that very inspiring 41:26.080 --> 41:28.520 and it's changed my perspective a bit 41:28.520 --> 41:30.720 on how I do this stuff as a maintainer. 41:33.520 --> 41:36.080 We talked about the contributing file. 41:36.080 --> 41:39.080 I'd like to introduce you to the maintaining file. 41:39.080 --> 41:41.920 This is where we write down all the things we do 41:41.920 --> 41:43.200 as maintainers. 41:43.200 --> 41:44.480 This is the process. 41:45.400 --> 41:47.920 But the contributors, we often think of them 41:47.920 --> 41:51.040 as being outsiders, right? 41:51.040 --> 41:54.960 So we're onboarding them to contribute for the first time. 41:54.960 --> 41:57.240 As maintainers in theory, 41:57.240 --> 42:00.400 we have been hanging around in the project a lot. 42:00.400 --> 42:01.760 I don't know about your projects, 42:01.760 --> 42:06.440 but mine, we don't roll a formal release that often. 42:06.440 --> 42:08.280 There are some other one-off things 42:08.280 --> 42:10.240 that we don't do every day 42:10.240 --> 42:12.680 and I can't always remember how that works. 42:13.840 --> 42:17.280 So the release process, the docs build process. 42:18.640 --> 42:21.920 The other things that you do as a maintainer 42:21.920 --> 42:24.840 when you get this notification from the distros, 42:24.840 --> 42:29.200 do this number, you need to change it in this file 42:29.200 --> 42:30.080 and then in that file. 42:30.080 --> 42:31.560 I'll just write it down. 42:32.680 --> 42:37.680 Again, it enables the next generation of maintainers. 42:38.760 --> 42:42.680 But it also enables you to stop holding that information 42:42.680 --> 42:44.440 in your head. 42:44.440 --> 42:49.440 It puts it somewhere, like it stores it alongside the project, 42:49.440 --> 42:53.160 rather than in your obsidian vault 42:53.160 --> 42:55.360 or however you store your notes. 42:55.360 --> 42:56.520 Those are secrets. 42:56.520 --> 42:57.720 Please take them out of there 42:57.720 --> 43:00.080 and put them with the repository they belong to. 43:01.560 --> 43:04.840 We can just put market files in our repository 43:04.840 --> 43:06.480 to be part of the repository. 43:06.480 --> 43:07.800 It's a good thing. 43:09.920 --> 43:14.760 This wild, globally distributed, time-distributed, 43:14.760 --> 43:18.000 language-distributed, asynchronous work 43:18.000 --> 43:22.360 that we do together in open-source, massively benefits 43:22.360 --> 43:24.520 from all the things that you write down. 43:28.240 --> 43:29.760 Let's talk about automation. 43:30.800 --> 43:35.640 I'm very wary of putting more things on a maintainer to do list, 43:35.640 --> 43:39.040 but these are time-investments and 43:40.040 --> 43:43.720 they're the easiest thing to get help with. 43:43.720 --> 43:47.160 Because even someone who doesn't know your project well 43:47.160 --> 43:49.480 can look at a thing that you're doing manually 43:49.480 --> 43:53.160 and maybe they already have knowledge of the CI system 43:53.160 --> 43:56.360 that you're using or a particular tool for checking. 43:56.360 --> 44:00.560 And they can help fit that to the specific scenario 44:00.560 --> 44:02.400 that is your project. 44:03.680 --> 44:06.440 As a maintainer, your time matters, 44:06.440 --> 44:10.960 your expertise needs to be used to good advantage. 44:10.960 --> 44:15.240 And so these things help you be more efficient 44:15.240 --> 44:17.680 because we're offloading the boring things. 44:18.640 --> 44:20.880 So if you have coding standards, 44:22.720 --> 44:25.480 any of those kind of, if you do builds, 44:25.480 --> 44:28.000 if you can build tests, if you run end-to-end tests 44:28.000 --> 44:32.200 or integration tests, have that all automatic. 44:32.200 --> 44:34.760 We talked a bit about the local development. 44:34.760 --> 44:39.040 These should be runable locally as much as is realistic. 44:39.040 --> 44:40.520 This isn't going to work for a front-body. 44:42.640 --> 44:46.360 But you should be able to run as many of those locally 44:46.360 --> 44:51.880 as it makes any sense, as well as automatically on a pull request. 44:51.880 --> 44:55.440 There will be no for-getting to update something, 44:55.440 --> 44:57.240 for-getting to run the tests. 44:57.240 --> 44:58.240 Just do it. 45:00.040 --> 45:04.160 Adding spell checking and proslinting and coding standards 45:04.160 --> 45:08.120 and checking for file names or directory names. 45:08.120 --> 45:10.680 If you have, in the contributing file, 45:10.680 --> 45:14.040 if you documented requirements for your pull request, 45:14.120 --> 45:18.600 must link to an issue, must use a certain format. 45:18.600 --> 45:20.240 Any of those things? 45:22.160 --> 45:23.400 Automate them. 45:23.400 --> 45:25.120 A lot of those things you can automate, 45:25.120 --> 45:27.640 some of it you can't, so if you can. 45:29.520 --> 45:31.560 It's one of the easiest things to get help with. 45:32.560 --> 45:37.240 We talked about the well-organized, well-acolic garden, 45:37.240 --> 45:40.200 well-looked after issues list. 45:40.200 --> 45:41.600 What do you want? 45:41.600 --> 45:43.440 Open an issue. 45:43.480 --> 45:45.560 Be specific. 45:45.560 --> 45:46.400 Tag it. 45:46.400 --> 45:47.880 Help wanted. 45:49.520 --> 45:51.000 Be what comes. 45:51.000 --> 45:52.480 Mentoring it to people. 45:52.480 --> 45:54.800 Tell your local user group, right? 45:54.800 --> 45:57.520 There's a lot of things here that we can do 45:57.520 --> 45:59.600 to make better use of your time. 46:01.440 --> 46:03.200 Where's your hand if you get too many notifications 46:03.200 --> 46:04.520 from source control systems? 46:05.520 --> 46:06.400 Yeah, I mean to. 46:08.400 --> 46:10.400 And the temptation is to be like, 46:10.400 --> 46:12.360 ah, no, this is terrible. 46:12.360 --> 46:13.760 And you put them all in a folder, 46:13.760 --> 46:15.360 and you never look at them again? 46:17.400 --> 46:19.040 Please don't do that. 46:19.040 --> 46:20.040 Please don't do that. 46:21.320 --> 46:23.720 Use the settings available on the platform 46:23.720 --> 46:24.960 that you're using. 46:24.960 --> 46:27.720 Route the notifications to your personal email address. 46:27.720 --> 46:29.480 You're a working email address. 46:29.480 --> 46:31.520 I have some other project email address. 46:31.520 --> 46:33.280 Whatever makes sense for you, 46:33.280 --> 46:35.800 take the time to configure the routing. 46:37.080 --> 46:40.080 Let the watch levels appropriately. 46:40.080 --> 46:42.080 I have different projects I have. 46:42.120 --> 46:43.480 I get every notification 46:43.480 --> 46:44.520 because I don't want to miss anything 46:44.520 --> 46:45.560 on this tiny project. 46:45.560 --> 46:47.040 I won't be visiting. 46:47.040 --> 46:49.320 And I have others where you have to save a name 46:49.320 --> 46:51.640 three times before I do anything. 46:52.880 --> 46:55.720 Use the code owners features, right? 46:55.720 --> 46:58.880 This means that you can, in a bigger project, 46:58.880 --> 47:02.040 if there's a change to a docs, a docs directory, 47:02.040 --> 47:05.720 and you have writers as part of your maintaining team, 47:05.720 --> 47:07.600 they can get the review request 47:07.600 --> 47:09.840 and get a notification for it that way. 47:10.800 --> 47:12.800 Use some email rules. 47:12.800 --> 47:17.080 So I have a set of labels which show me, 47:17.080 --> 47:19.600 I'm even getting the notification. 47:19.600 --> 47:21.880 It adds extra, I use in Gmail. 47:21.880 --> 47:24.280 Gmail labels for, 47:24.280 --> 47:28.560 this is a review request or you were mentioned. 47:28.560 --> 47:30.560 And if it's neither of those, 47:30.560 --> 47:34.280 I can immediately tell that from the list in the inbox. 47:34.280 --> 47:37.360 And that's helped me to prioritize on busy days. 47:37.520 --> 47:39.200 And then I can kind of triage the rest 47:39.200 --> 47:40.920 when I can when I have time. 47:43.440 --> 47:45.560 Running out of time, but that I want to just wrap up 47:45.560 --> 47:47.080 with one more thing. 47:48.160 --> 47:50.320 And that's about outreach. 47:51.600 --> 47:55.160 Your project is more than the code. 47:55.160 --> 47:58.600 It's not quite enough to build it 47:58.600 --> 48:00.400 and hope that they will come. 48:01.440 --> 48:04.240 You also need to enable the ecosystem, 48:04.240 --> 48:06.920 your community, your users, 48:07.360 --> 48:09.880 or encourage other people to do that. 48:09.880 --> 48:13.840 Actually, supporting a project with these activities 48:13.840 --> 48:17.600 is a great way to participate in something 48:17.600 --> 48:20.760 if you aren't going to be coding for it, 48:20.760 --> 48:23.760 if you want to support and champion it. 48:23.760 --> 48:27.320 So maintainers, please support these activities, 48:27.320 --> 48:29.120 but for everyone else, 48:29.120 --> 48:32.280 you don't even commit rights to do this stuff. 48:32.280 --> 48:34.560 You write about the project, right about how you use it, 48:34.560 --> 48:36.760 why you like it, share your tool setup, 48:36.760 --> 48:38.320 your configuration. 48:38.320 --> 48:40.520 That massively helps every project 48:40.520 --> 48:42.440 to have a more healthy ecosystem. 48:44.600 --> 48:46.840 Have a list of projects that use the tool. 48:46.840 --> 48:49.120 Again, start the section on the read me. 48:49.120 --> 48:50.680 People will add themselves. 48:51.800 --> 48:53.320 I don't know if we still use suck overflow. 48:53.320 --> 48:54.960 I think we do. 48:54.960 --> 48:56.640 Check for questions there. 48:56.640 --> 48:59.720 If there's a tag or if you can follow what's going on there, 48:59.720 --> 49:02.040 look what people are asking. 49:02.040 --> 49:04.760 Answer if you can, but also it will inform you 49:04.760 --> 49:07.840 what people are struggling with and what they need help. 49:07.840 --> 49:11.160 Tell your local groups about your project. 49:11.160 --> 49:13.720 I think we all want to support each other, 49:13.720 --> 49:16.520 and it's a great way to learn about a project. 49:16.520 --> 49:18.880 You'd be really interested if someone from your user group 49:18.880 --> 49:21.480 told you about their own resource project, right? 49:21.480 --> 49:23.160 So return the favor. 49:26.440 --> 49:29.720 Improving developer experience in open source, 49:29.720 --> 49:33.000 we are back to this being confident, 49:33.000 --> 49:36.360 being successful. 49:36.360 --> 49:38.760 Encourage your collaborators, 49:38.760 --> 49:41.320 especially with people who have a different skill set 49:41.320 --> 49:43.080 from you. 49:43.080 --> 49:47.960 You've space for people to come in to just improvements. 49:47.960 --> 49:50.760 You can suggest improvements to the projects 49:50.760 --> 49:53.080 that you use and like. 49:53.080 --> 49:58.600 Now that you've seen this talk, keep your issues list, 49:58.600 --> 50:01.200 well maintained, close the stuff you don't want before anyone 50:01.200 --> 50:02.800 builds it. 50:02.800 --> 50:07.520 So be kind, write something, but close it. 50:07.520 --> 50:11.160 This is kind, close it. 50:11.160 --> 50:13.720 There's a good first issue label, which 50:13.720 --> 50:18.200 is a great place to have people contribute for the first time. 50:18.200 --> 50:20.160 Your project should always have two or three 50:20.160 --> 50:21.840 in its issue backlog. 50:21.840 --> 50:23.680 And I mentioned some of the automation stuff 50:23.680 --> 50:25.680 as a great place to start, because you don't need 50:25.680 --> 50:27.320 a lot of project-specific knowledge. 50:27.320 --> 50:35.000 My final thought on this is the magic multiplier 50:35.000 --> 50:39.720 that opensource, something that helps users, 50:39.720 --> 50:44.400 participants, contributors, and maintainers. 50:44.400 --> 50:46.560 They thank you. 50:46.560 --> 50:48.520 When people engage with your project, 50:48.520 --> 50:50.160 even if they're reporting an issue in a field's 50:50.160 --> 50:52.240 point negative, they're offering a change, 50:52.240 --> 50:56.440 and you don't want it, still say thank you. 50:56.440 --> 51:01.080 We're building this incredible open source world 51:01.080 --> 51:04.200 that gives people freedom and choice, 51:04.200 --> 51:05.840 and it doesn't cost anything to be 51:05.840 --> 51:08.760 for light about it along the way. 51:08.760 --> 51:09.840 That's it from me. 51:09.840 --> 51:10.760 I am out of time. 51:10.760 --> 51:11.840 I know I am. 51:11.840 --> 51:13.120 If you want to get in touch, I would 51:13.120 --> 51:14.320 be delighted to hear from you. 51:14.320 --> 51:15.640 There are all of the social networks 51:15.640 --> 51:16.840 looking the footer. 51:16.840 --> 51:18.120 I'm also looking for work. 51:18.120 --> 51:20.240 So if you need any help with any of your projects, 51:20.240 --> 51:23.040 or anything like that, please let me know. 51:23.040 --> 51:24.440 Thanks for your time. 51:24.560 --> 51:26.040 Thank you. 51:38.040 --> 51:39.920 Thank you.