 This thing on wonderful. So first of all, thank you everybody for coming. I know that this slot is very stiff Competition I Considered to not show up myself Yeah, so thanks for being here, I'm Hennig if you've ever encountered Hennig in a Python community It was probably me If not, it was a cop. Don't talk to them. I'm still lawyer. So Other than that I Also maintain way too many open source projects Most famously errors which is the direct answers of the much below the data classes Which at this point has more than 14 million downloads per month Which by the way is 2 million up since Python US which is getting really scary and it's roughly 4x of Django Just give you an idea. I also have still a few of stickers left, which I made last year So if you want some of them come to me, I have very few left. I Yesterday you may have learned about struck lock from Google If I break it in the best case scenario pipey I CC I breaks in the worst case you cannot download any packages anymore And all all the rest of it also Keeps a lot of systems running to more or less degree But despite this anxiety and use it inducing body of work I'm not saying that I'm good at maintaining open-source software. I'm also not saying that I'm happy at maintaining open-source software actually I tried To thank all my projects and bring them to Goodwill because they don't spark any joy anymore But for some reason they prefer my who go boss winners so Yeah, the problem with that every open-source maintainer at some point arrives is that is a lack of time Because maybe you have crunch at work. Maybe you want to travel which is one of my main problems Conference preparations you should see my github inbox leading up to your Python. It's a nightmare And Sometimes you do have the time, but you just don't have the energy which is also normal Eventually you don't have this first rushes of starting an open-source project and it's just work. It's a drudge But I'm not here to talk about how shitty it is maintained open-source software. I think that's well established and if you If not, you can Google it. There's a lot of thought pieces on medium I'm here to tell to teach you how to feel less shitty about it and how to be a less stressed While shipping and this is important high quality Python package and to achieve that We need to talk about removing friction from the contribution process I'm gonna talk mainly about your contributors because as a maintainer once your project is running your main job is to be a leader So you're kind of the product manager and this is your only specific task as a maintainer, right? You decide what goes into your project. You decide on the scope of your project you are responsible to uphold the quality of what we are shipping and The best way to burn out through buck tracker is to ship a bunch of broken releases I've seen some really bad hostilities on buck triggers happen cost by the constant negativity that came in and Speaking of that you also get to set the tone of your project And I think this is the biggest upside you can out kick out toxic people before they become a problem In practice, you will still write code But your goal is that you set up your project in a way that anybody can write code for your project Even you after three months of reddit redemption to So also Once your project majors your development velocity goes down. This is natural Like you don't want to move major projects fastly at some point And you are not gonna hack on it every day again. It's just fine But once you come back, it's the same like with I don't know if ever played some video game I'm came back after three months and you had no idea how to come to the controls work It's the same with projects So you'll be grateful for everything that you put into place to hit the road running when you need to fix a buck Or some compatibility problems So you're basically contributing to your own project that are two separate roles here and Any friction for your contributors also falls back on you more or less directly So the most obvious thing is work just doesn't get done. So how many of you ever Wanted to fix something in a project you're using you knew how to fix it But you didn't do it because the process was unclear or overwhelming Right every arm just went up And it was a lot of arms and I think some just just to shy you always have to like multiply by three Stands for work this has not been done or it has been done by the maintainer although they could have used the time for something better Also if every new contributor Needs hand-holding to get even started contributing. This is a menial task We don't talk about it like this, but it is emotional labor is labor support labor's labor And this kind of labor will burn you out much faster at least in my experience them Writing code, which is usually much kind of fun So we're not willing contributors arrives. You want them to Have it very easy to get started and give them an early first feeling of success Because motivation tends to evaporate really fast if you do not have buy-in with a project So give them the dopamine really fast You also want to give them a clear path from start to finish Because in my experience people do not mind putting work and time into quality They have an interest interest in your package staying high quality because if it breaks they get page at 3 a.m. In the morning So this is not a problem, but they want to know what to do and ideally want to know before they start the journey and In my experience and this is not just about open source or anything a long concrete to-do list with actionable items Beats a vague short one every day and it feels better You also want to give them a short feedback loop Which in this context means the time between you try something out And you know the result of that like running tests or something like that This is to me the number one factor in development ergonomics and it encourages Experimentation which is good and the lack of a good feedback loop is usually the number one reason for me to abandon work on some bugfix for some other project So in the following I'm gonna show you how I try to remove friction from contributing to my projects To do that I'm gonna talk you through the life cycle of a contribution It's gonna be a plain three act Featuring you who wants to contribute to a project of mine and me who wants to get into Wants to get your work into the project and out to the people where there's little work as possible for myself And ideally this is like the bonus round. I want to bind you to the project to do even more free work for me So Unfortunately the small-minded organizers of this conference Denied me my request for an all-day Hineck track. So All we have is 45 minutes there also will be no questions, but I'm around just come and talk to me Even if I play with my phone, I usually do that because I'm to try to talk to people I'm gonna present concepts and the concrete implementations I will I have collected on a page Which I will present at the end and you can look up anything I will talk about there and There are concrete implementations or anything. I'm just making stuff up here everything I'll talk about has a real counterpart So we start with your part This is entirely about you if I have to intervene at this stage I have failed you because you've encountered friction and myself because I want to be skateboarding somewhere I'm not a dirt on GitHub. So this would be a lose-lose So where do we start? If you want to contribute you need the source code obviously Now sometimes I find it surprisingly hard to find it and I googled for projects before to find it on github So what I do is that all my projects have a block like this in their github read me on Pi PI and in the documentation and all those three places are Cross-reference, which is other so once you find my project in one place you find all other places, too Now this is the important part or one of the important parts first encouragement and A link to our contribution guide, which at this point is also a well-known file on github called contributing RST MD whatever you float to your boat and it gets linked prominently whenever try someone tries to open a pull requests and This file should encourage to follow through Because many still think that contributing to open source is some kind elite thing only the enlightened can do but turns out Anybody can do it with some free time on their hands, which is a big privilege Which I will concede that still there's like nothing you have to pass so just take a sentence to Dispel a notion and tell people they are always welcome to contribute Describe the development process the road I talked about people know what's ahead so they know what they are getting into Explain your expectations about your code standard about your coverage expectation the expectation of behavior So we can reference another well-known file called code of conduct I've said before I think it's a huge privilege to be able to Maintain a good tone in a project and finally I Help people to set up a local development environment for that Quick feedback loop I've been harping around and you will be surprised to learn that I have opinions on how to do that So firstly I Use setup tools. I know there are alternatives. I know people have very strong opinions about alternatives and about setup tools But none of those alternatives covers all my needs and at this point set up to kind of works So it's not that bad So far it's false. I'm still on it So first you need to create a virtual environment however you prefer there are great tools nowadays to manage them for you You don't really don't want to screw up your global Installation to just run tests and then you install my package as editable which means that Whenever source code changes the installed package automatically changes along with it and we use an extra dependency called death So who is familiar with the syntax? Okay, who has learned about the syntax yesterday in Mark Smith's talk Okay, I Will still explain it shortly So again, these are optional dependencies This is a really cool feature many people do not know about or don't use and you can have Multiple of them. You just separate it by commas For example, you're up three you can use this exact syntax in your requirements TXT And it's quite possible that your favorite project actually has features. You didn't know about that are dated by optional dependencies On the development side, it's quite easy You just pass a dictionary into the setup tools setup call and this dictionary Maps those optional optional names to a list of dependencies. That's all now set up the pies Python code This is a dictionary so it means you can also build your dictionary iterative It is exactly what I do. I first set it to tests which is something like this dogs Which is things and then I have my deaf Environment and just talk about which is just this plus dogs. It's nice when you can write code now Now we can write run tests. Bless you We can also build documentation So and I really think unless you have C extension or some really weird stuff That's not your fault. This is all it should take to run tests on your project Now we have two problems here though So first you have to remember how to run your tests although I really think it should always be pie test because tests are code Ideally you have more test code and package code because they have dynamic language. So we have to be careful Code needs to be maintained Maintenance is not easier for tests. So I personally do not buy into this purity notion of tests I think you should use the best tools available, but I still don't expect you to remember that because why should you so Some people solve this using make files, especially people working in corporate environments that have a more homogenous environment I don't think this is great Especially because it's problematic on Windows and as you may or may not know with the vast majority of Python Programmers is on Windows. So if you make things hard for them, you are cutting off a significant portion of possible contributors Also, you're testing only one Python version I mean, it's almost 2020. So maybe you're lucky enough to do you don't have to test against Python too But still we have a bunch of Python that are in active use So what you could do is that you could start creating more virtual environment and manage them or You just use the tool that is made for this specifically that marks miss also talked about and it's talks Completely oversimplified. It allows you to declare virtual environments optionally build your package and install it into that Virtual environment and then run any command out of this virtual environment As easy as explain we're an example You need a talks.ini in your project directory first you define the list of environments in this case is Python 2.7 3.7, PyPy and PyPy 3 so we have four environments in this case Then you set global settings in this case we install our local package with the extra tests that I've just showed you and We run PyTest and a PyTest Now if you add this squiggly post-arch thing at the end you can even pass arguments to PyTest So if you now run something like this talks-e Py27---x it will run PyTest-x in the Py27 environment so technically you don't even need local test development environment you can get away with talks completely Now I consider it a valid Expectation for most Python projects that I just can run tests talks and it tests everything against all versions And I really think you should have good reasons for that to not be the case or you should use NOx Which is also quite nice, and it doesn't it use Python instead of this kind of hacky.ini File and as we will see later talks is a lot more versatile that you might think it's not just for running tests now There's more to code quality than just tests There are issues of style like consistency makes code much easier to read Have 8 comes to mind Some things are not wrong, but are fortunate for example unused imports or unused variables Which by them itself are harmless, but they may actually be problematic because maybe you are using the wrong wrong variable and And a process of checking code without running it is of course called lint ink The name is based on the stuff that you find in your pockets like pocket lint or in your belly buttons They are nothing it's nothing terrible, but Your life is usually better without some shit in your belly button. So it's better to get rid of it so The most famous linter for a Python of course flake it and it actually just combines multiple tools like pep8 for style Pie flakes for correctness, and I'm gonna go out on a limb and claim that code it passes like eight It's more correct and more readable now What is the single commit every Python project has that uses setup tools? Yes, I hear the laughter of pain So this loser obviously just forgot to run his linters because there is a linter and it's called check manifest if you to remember And finally have you ever seen a pipe I page like this? So this means that pipe I was not able to render your long description and That means that you probably have some some type with somewhere in the in a markup or something So I'm using this with permission and also if you look closely This is the test pipe I instance which some people are not quite aware of I think and this is really cool when you are starting out and a Good place to upload your empty source directories and broken wheels before you go On the real thing it gets erased every every now and then so it's completely harmless and you it has Separate credentials. You have to create another account and it's pretty cool So There's a linter for this it's called twine Which is also the tool you will use to upload your package, but it also is able to catch this for you Now linting and checking is great like robots yelling at you is always better in people yelling at you But what's even better? Making a stupid computer. You paid so much money for Fixed these things actually for you and this is about automatic formatters and they got more popular in the past years And in my opinion there are an immense game changer because want to embrace them It means that you and your contributors can't stop Thinking and most notably bickering about minutia in your project and you can focus on Solving the problem you're trying to solve and not when to hit enter or what kind of quotes to use or whatever And there's been a bunch of formaters for Python for quite a while, but none of them was really quite there He's not for me until black appeared and Like has many great properties. So first of all it uses a format I like because I yelled at Lukash a lot on Twitter But also it formats it into a canonical format it is deterministic So if you throw the semantically it the identity Identical code into it you will always get the same output out of it. This is really nice This is for example much better than go format Which is not deterministic and drives me crazy every single time I use it So then there's I sort it will sort your imports which I personally find more important It should into beautiful sorted blocks separated by type. So you've got your standard library third party your imports It's wonderful and together with black. It's like the most code formatting That you will ever have to think about and it's fully automated. You just don't have to think about it You don't have to talk about it. It's great. It cannot come up in code review It's no friction whatsoever, but how do you make the user run it now? Because we've got this linters this checkers those tests formators. So for the lending part some of them you have to Some of them imply packaging most notably Check manifests. So you have to run it in a proper talks environment So it it can test the packaging part, but for everything else there's something better. It's called pre-commit pre-commit allows you to Define hooks that run before each get commit so it will prevent you for to even commit broken code But it also allows you to run it over the whole file. So it's kind of like a Linter central if you want and to use it you just need a config file in your repository called dot pre-commit config YAML The a is not optional and it's drives me bonkers because it's the only YAML file in on My hard drive So anyhow, like it has direct support because the author of Preq and a maintainer of pre-commit is also now one of the maintenance of like eight. So your first-class support As a very straightforward just pointed at a repo you you pick a version tag Which also ensures that a flake eight updates does not break your build I think this is a good compromise because some projects like to pin all the development Dependencies I personally I'm not a fan of that because Once the velocity goes down those projects tend to have like a weekly update all our dependencies commit and the actual work gets kind of lost in the noise So I think this is this is kind of nice So you put in a version you choose the hook and the Python version you want this hook to run That's all now Python the pre-commit is Python aware. So it will Store and manage your the virtual environments that are required to run this tool Completely transparently it did not break for me yet, which is high praise for our For a project that deals with Python packaging So black and I sort are also super simple and there is a whole ecosystem around it So who's ever checked in a PDB dot set trace? Yeah, I Think in this case, I don't have to multiply by three by more like by five Liars, anyhow There is a hook for us. We don't have to do that anymore And it's also not Python specific. So The the most far out thing to do if you can run Docker containers as hooks So like there's a gig you can go all out now with all this in place I could ask you to install pre-commit but pre-commit is a Python package and It's asking you to install Python packages globally is It's just asking to turn my buck tracker into a Python packaging support forum and this is not a good thing Let me tell you that I had this problem before so let's wrap it into a dev extra So this is basically what I do Yeah, my development environment is basically that tests extra plus the docs docs extra plus pre-commit So once you can run Pi tests and build docs you can also run pre-commit and your your global system is left alone So to ensure that you run it Again, you should run pre-commit install so gets installed as a good hook You should run it by yourself again. I don't want you to remember that so What we're gonna do is that we will rely on talks again. We add one environment called lint we Have only one dependency Pre-commit itself. We will skip installation and this is means that it's much much faster So whenever you run any commands from talks that do not need your package to be installed always said skip install because it's it's much faster And then we just run it against all files And if one of the pre-commit hooks fails this talks environment will fail to you know, something's broken So which means your code is perfect? What is missing? documentation How we make do we make sure that it builds and you guessed it if it's things you should which you should use It's great It's another talks environment So this time we install our extras docs, which I talked before to it's usually just things and whatever I need to build my documentation First we will make sure that our HTML documentation builds and Then we run the doc test for all documentation I'm gonna use this lectern to preach that all your examples in your documentation should be doc tests Because then you can be sure your examples are correct Because nothing is worse than broken examples like even no examples is better than broken I've spent hours of my programmer life I'm just trying to figure out what I'm doing wrong and in the end This was just some comma missing in an example or a wrong keyword argument or whatever So make sure examples are correct Consequently if your read me has doc tests check it too So now whenever you're on talks So basically typing three characters you ensure that your tests are passing that your lenders are passing that you code and imports are beautiful Your documentation is building and you have working examples. So this is the only thing I expect you to remember T. O. X And everything we've done so far happens on your local machine I may not even know that you exist and you may have the perfect pull request for me Which is kind of cool You can work anywhere and I travel a lot and sometimes I Long for conference Wi-Fi, which is a bit unfair. The Wi-Fi here is really good. So But you know what I mean anybody who has been in Florence Yeah, a few of you were So Especially like everybody who has ever used github would say in rural Africa will understand what I mean like the current internet Like the modern internet is completely broken for the largest part of the world and nobody of those who are responsible care because they have cozy Google fiber at home and at work But this is not just about my laziness or The consequences of colonialism. It's also about my insecurity and empathy Because I don't like to publish unfinished work. I'm self-conscious like that So I don't want to force you to publish half finished work and then yell at you what you've done wrong So I want to give you the tools to ensure a high quality initial pull request and then we can just talk about a little stuff So now you're done you open up for requests and if you look at your watch, we spend most time in act one And I told you I want to get involved as as late as possible. Ideally at this point. I'm still not there so You want to Automate as much as possible, but some things cannot be automated. So enter another well-known file. This one is called pull request template It's always MD because it gets inserted whenever you open a pull request and you can use it to add like checklists To new pull requests and I love checklists because they are the sole reason Why airplanes do not crash every day and why doctors wash their hands before cutting you open? So they are like programs for humans. So it's just like the next best thing like them programs for computers and Renders they look something like this And you can use it to remind people to add documentation for the new features Adversion tags as at change look entries. It's great And now me or ideally a co-maintainer has to verify that you the contributor have done all these things So this checklist is also for me because I don't carry this list in my head I can barely remember what I had for dinner yesterday. Oh wait. I do. I had nothing because I cannot afford the food in the city I'm I'm living of chocolate and coffee and I brought my own coffee Anyhow, what are we doing? I'm gonna I refer to this list But I don't want to clone every of your pull requests to my computer to run the test and check everything I'm lazy. So I also want to encourage contributions through the web interface and it's something I came to appreciate myself a lot too because it's even less friction It's perfect for typos. I love typo pull requests and I hate typos in my documentation. They are embarrassing But nobody fixes them or few because they have to fork my project. You have to check it out You have to do the change you have to push it Open a pull request. That's a lot to ask for people to just swap to characters or fix some grammar so what we want is the ability to run the tests on the internet and That's of course called continuous integration or CI and I don't know how many of you remember the dark ages of open source when only the most prestigious projects had their own Cis because in the best case scenario someone donated you a server usually rec space and You had to run it yourself. I don't know if anyone is an open source to be a system operator But I'm not and this is very very unglamorous So then came Travis Travis has this ups and downs over years, but it arguably democratized the continuous integration scene and open source and Adding it to a project was really really simple. You just copy a paste a bunch of yaml it's like set up the pie and You can just reuse your talks environments So you made sure that same command lines are run locally and in Travis. It was great for the good old times of 2018 However, then came Idera and I'm not gonna Comment on them specifically because I don't want to get sued by them I'm gonna encourage you to do your own research to talk to people working at Travis We used to look at Travis, but here's the fact They laid off the big part of the workforce shortly after taking over Travis That made what was supposed to be one slide telling you to use Travis and maybe at there if you need Windows binaries and unexpected a research project and soon as a research project that did not go great to be honest Because every other option is way more complex than Travis or is lacking in some other way But I consider Travis or at least it's free offerings a time bomb at this point and we need to make plans what to do afterwards which is sad because the Importance of Travis to the community cannot be understated and they raised the bar open source significantly But we don't know how this will shake out and it's scary so The good part is probably it's an end of an immuno culture We Used to have just Travis and maybe something else now people have to go a bit further Microsoft smelling blood the Azure pipelines has been Has been advertised a lot especially at Picon US they offered help with moving your project from Travis to Azure pipelines but then they managed to break the pre-installed pythons for 24 days and I don't know like Travis never had an audience like this like this. This was very embarrassing Especially because I published a blog post on how to move to Travis like a day before so people started emailing me Anyhow it's working now They wrote a very long post mortem and promised to do better But here we are it's like nothing great is there like everything has problems. So let's hope that Next year everything's gonna be great One thing is almost forgotten nowadays is that github was was or is actually working on a CI to called get up actions But it has been in private beta forever now. I've been waiting for months to get access I have no idea when it's gonna be ready and who knows if it ever goes public now They've been taken over by Microsoft. There's not much interest. I guess. I don't know but github already provides a bunch of automation So first most obvious one is github checks Which allows third-party services to put a green checkmark or a red X next to your pull requests If you've done something wrong most common usages are of course CI integration also common thing is to use service like coveralls or codecuff to Failure pull requests if you don't have enough code coverage But there's a more sophisticated approach or more artisanal of your wallet which are github bots And Marietta the Kaleesi of CPython core development bots Get a bunch of talks and webinars on that And I think this is important because she changed core development forever back when I was a lot more active than nowadays a Lot of the day-to-day work as a core developer means meant downloading patches from round up Applying them trying something out back porting stuff between branches and so on you spend a lot of busy work And all this work has been completely eliminated by bots nowadays Now I've been told that there's also an open space today at 1120 which is right after his talk. I'm sorry max So if you're interested into this kind of stuff This might be for you But that's all I'm gonna say about the mechanical parts of the pull request process Now what happens after all the checks are passing someone has to review it in the beginning It's probably you as the project grows you don't want to review everything yourself You literally can't review everything yourself. You also don't want to try it all bucks answer all questions There's a natural limit to how much you can do especially if that limit is your free time so you need to build a community and Building communities is hard and there's lots of material on a net I don't have much you to add but there's one thing that's important to me I want to talk about and that's about community empowerment. I Find it important given the history. I've been watching in the Python community that you give your if you contributors to the feeling that the project is there too, I'm gonna note that I wrote this talk way before the latest Python community drama and It was a problem back there, too It just hadn't been talked about it a lot and the problem is that it's very shitty to let others do the work To build your brand for nothing in return Contributors should be celebrated and taking all the fame for yourself may feel great in a short term And you get to retweet all the praise about you and your projects and how awesome you are But it will backfire eventually people will burn out for not feeling valued I've seen people get very resentful. I've seen people write blog posts So this is thing For this reason once address grew bros grew beyond a certain size and a lot of the code was from other contributors It's most notably typing. I has been written by a bunch of people from mostly Dropbox some of them from pilot I've I honestly do not understand all of it yet. And I would like three contributors review those those PRs and And I felt bad to make it look like it's all my work because it wasn't and there was still my name on the github And I was a practical reasons because there's a bunch of functionality missing from personal projects versus Organizational projects so I moved errors into a github organization and anyone who contributed to the project can have full access now it's our project and If it's less obvious that the project is yours people are also less likely to add to telling you that Your free labor is ruining your lives. So Upside all around so how do you decide whom to take in into your project when you give commit rights? I What I've learned is that you should not make a big deal out of it for the most types of projects If someone wants commit rights, just give them to them and I learned this very Zen approach from my friend Cori Benfield We did amazing work on a Python HTTP stack before we tragically lost him to a fruit company and Pie pie does the same thing. So I see I saw a lot of pie pie people around so you can talk to them and There is nothing people can do and get or mercurial that can't be reverted if you just protect your master branch and force everyone through pull requests And if the process is clear people usually will adhere to it And if not you revert their changes you re you take away their rights. It's that easy But it never happened to me or Cori or pie pie people tend to respect code This is like the only value seem to be shared because it's much more likely that you have to kick off people from mailing lists because They don't respect other people as much as they do code. So it's kind of sad, but here we are So finally providing support can also be very stressful, especially on synchronous channels like IRC or God forbid slack So I started moving support to stack overflow This has multiple advantages. So first of all, it's asynchronous. So many of us are Europeans. So we know this problem that a lot of our open source Friends are in a very different time zone. So if people from San Francisco ask something I Don't have to be awake to answer and maybe I have the chance of someone else answers before I get awake and see it It's sortable. So if I answer one question once the answer does not vanish in some obscure archive It's there and that the duplicate the duplication of questions is not my problem by the problem of stick overflow moderators, which is great And if I have to answer in the end at least I get internet brownie points out of it in a form of stick overflow a reputation So but I still don't want to hang around on the page all day So what I do is that I set up tags for my projects and then I follow them on RSS Yes, RSS you may have heard grandma talk fondly about that just imagine Instagram But there's no stories No photos and you can choose your own client. It's great There's a downside Not everyone can set up tags. You need a certain amount of reputation. I think it's like 1500 points So don't ask me. I don't have that much reputation. People don't ask that many others questions I'm barely over 1,000, but there are many people in the pattern community who can help you out there So back to our pull request Let's assume I reviewed it while doing so I didn't have to pass through you about the line length the import order the type of quotes the trailing about trailing commas Missing trailing commas failing tests broken documentation and nothing of that. I just enumerated is made up I've passed her people about it before because I have strong standards for my from my projects that I'm not willing to bulge on But I am willing to do everything to make them go away and in this case Robots got to be the assholes and studies have shown that people take pestering from a robot much less personally than from other people So Robert is is not unless it's some AI thing that has been trained with racist data, but Robert usually is They just look at your code and see the problems that you told them to detect and who doesn't love an asshole robot So now we merge it then as a maintainer. I would like to encourage you to say thank you I've been doing this for many years, but I still find Commentless mergers super rude like I don't know. I just feel bad. I've spent some time to fix a bug You probably are grateful. Just express it like speak your heart Now for everyone to use your great contribution, it's time for a third and final act The release and what I hope you realize is that you if you fold act one and two you can release at any time Because your poor request based workflow with a CI that makes sure that it's everything is green insured The master branch can be released anytime and it is not only convenient This can be essential if you have an emergency like a nasty bug or a security problem so The problem is if your project is ready to be released at any time But you don't because the release process is a drag and you procrastinate on it It's kind of worthless and it leads to bug reports like oh my god. The last release is so long ago This is even maintained I'm sure you've seen something like that before you don't want that what you want is to fully automate And if you look at it Releasing a package to pipe here. I it's just a matter of replacing replacing a bunch of drinks running a bunch of commands and Double-checking a bunch of outputs. That's all that's that's no rocket science here You just have to pick whether you want to let the CID releases which is increasingly popular and the amazing hypothesis project takes us to 11 By just pushing a new release for every poor request they merge so they have a lot of releases and I believe my friend Justin Meyer sitting here will talk about something like this on Friday how you can have that so Check this out. I Personally am not a big fan of that because I'm a control freak. So I prefer local automation Because I just have like to have more interactive control and like to centralize my tools This is the more important part for me because I maintain multiple Projects and projects tend to multiply once you embrace the glamorous open-source lifestyle So you want to avoid duplication of code and knowledge? So what I do is that I rely on conventions and those are conventions I can enforce because I'm in control of my project. That's the big benefit of being a maintainer and Because I can rely on conventions. I only need one release script for all of my projects One of my conventions is how I handle metadata. Oh, I forgot to click how I handle metadata. So all projects of mine have this block In the main dunder in it. Most of this is our Python conventions, but this one is mine. So what I like to do is that I My packages in development always have the next version with a dev zero suffix to make clear It's not the last version anymore. And it's not the next version yet. So it's not ambiguous about this one And when I release I just have to strip that suffix and my code is ready. All I have to do is No, wait one more thing. This is the canonical data of my project And I really like that to make the codes the canonical thing and everything else derives from that So my setup dot pi derives from that just parses it using regular expressions my comfort pine documentation reads this file This is really nice. And if you are using alternative packaging tools like flit or poetry You will have to do more work than that So what what else do you need you need a changelog So in my case, it's just I have to release Replies a string called unreleased with the current date And that's it Technically a project is ready for release the version is correct changelog is ready. Let's ship it Now shipping the project itself is a few simple steps. I wrote a blog post about it mark Smith talked about yesterday You just commit your changes. We just talked about take your version build a package push it to pi pi It's done your contribution is there and everybody in this room can automate everything. I just talked about It's like no rocket science whatsoever. And even if it seems trivial Paper cuts will vary you down to two Okay, and we're being waved at myself with with the time I have one minute though There's so much more like to talk about how to handle coverage for example local and NCI Managing changelogs using tools like town crier if you have a lot of merge Problems that's something for you. I had to kill 20 slides about documentation and my eternal love will read the dogs and Eric and an entire rant about 79 characters being the only true line length I Had an essay on how to prevent packaging mishaps like empty source distributions on pi pi Use a sources directory and I had a whole tech talk about semantic versioning being well-intentioned Ultimately fundamentally flawed But I'm already being waved at so I hope everyone got something from that I already made my plot twist on Twitter. So it's all everything. I said is also relevant if it is your job Yeah, automate Document have a short feedback loop That's all I have for you. This is the link I talked about get everything I talked about there Follow me on Twitter get your domains from viral media if you speak German, she beats her dutch works, too I'm here next. Thank you very much