Packages! Packages! Packages!

All right, take it away

Speaker 1: since you're MC.

Speaker 2: Since I'm the MC. Um Okay, welcome back everybody. Uh we're gonna be doing a panel here, uh moderated by Tim, who I'm sure everyone has uh knows by now. This is the uh packages, packages, packages panel all about wagtail packaging and wagtail ecosystem and all that good stuff. So uh yeah, quick introduction. This is Tim Allen. I'm Vince Salvino. This is Jacob uh top Mugglestone. And uh we have Will Barton. Take away Tim.

Speaker 1: Thank you. Thanks everybody for coming. Thanks for coming for the whole event. This has been fantastic. And uh I just wanted to start by saying what packages mean to me. Because sometimes we call them packages, sometimes we call them modules. But basically to me, what a package is in the Python community is anything you can pip install. So if you have made it so it can be pip installable, then it's a package. That's the definition I'm working with in 2024. Even though, you know, that might not be technically 100 % 100% correct. I think that's the easiest way to understand it. If you can pip install something, it's a package to me. And um there are different ways that you can start developing packages. So for example, you can pip install something from Git. So you can do you know Git plus SSH or Git plus HTTP and install something directly from GitHub without actually putting it into the Python package.

Speaker 1: And I wanted to give a quick shout out. Yesterday E. Durbin was here, and they are they're an old friend, but they're also one of the few people who worked the ultimate thankless job of managing the Python packaging authority. So the Python packaging index is when you type pip install wagtail, it's hosted on the Python package index or PyPI. And that is run by the Python Packaging Authority, which is E. E. Durbin and several other volunteers who put in a lot of hard work to put out new versions of PIP. to put new features up for package maintainers like us to have an easier life and to make sure that the criticality of Python can really not be overstated. And I think it's something that we don't really appreciate all the time. time. Uh my friend Dustin Ingram posted a great picture a couple of years ago

Speaker 1: of half of the Python core team crossing a busy intersection at the same time. And uh, you know, every Fortune 500 company's insurance rate should have gone through the roof then, because you know that's an amazing amount of risk right there And uh we don't appreciate a lot of the work that really goes into making it. So, you know, it's reliable that when every supply chain in the world, when somebody does a pip install on it and every Fortune 500 company has five Somewhere in it, that it just works and it's reliable, and it's been astoundingly reliable. And uh when I first started with Django , Um my first major feature that I worked on with Django was if you've ever started a new Django project and you've seen the rocket ship, that was one of my contributions with a fellow colleague. Here at Wharton.

Speaker 1: And one of the Django core team at the time was sort of shepherded me through the project. And he had this very wise advice when he was asked, What is Django? And he pointed out that Django is a community first, an ecosystem second, and a pretty cool web framework third. And in that same order, I think we can say, you know, Python is a community, an ecosystem, and a programming language. And Wagtail is a community and an ecosystem and the best CMS on the planet. I'm not biased at all in that. But the point of that is to say we're going to be talking really about, we have the community here at the conference, but we're really going to be talking about that ecosystem. So that ecosystem impact. the secret sauce, the wagtail packages that allow you to take what

Speaker 1: does there's so much more wagtail, but extend it further for specific needs. So with that, that's enough out of me. I want to give everybody a brief uh moment to introduce themselves and talk about some of the packages they maintain that allow you to extend web to help further starting with Vince.

Speaker 2: Yeah, so um one of our main uh packages is uh uh previously known as CodeRed CMS but uh now Wagtail CRX. And basically that is people often think it's a fork or a distribution of Wagtail, but really it's just a bunch of extra stuff pre-built in Wagtail. that you can fip install, get up and running. But then we also do uh Wagtail SEO, Wagtail Cache, which I highly encourage you to use. It will Both of those are kind of necessities and Wagtail at this point, and then we maintain a few others as well through Code Red. So yeah, that's my I I haven't really contributed much to Wagtail Core, but uh contribute through the packages.

Speaker 3: Yeah, um so Jacob, I've maintained a few. Um so probably the one mo most people have used um of mine is things like WhiteL content import, but I also kind of jointly maintain a few others including WhiteL transfer, which lets you transfer content between White different WhiteL instances and keep those instances connected. So keep track of what content you've transferred in the past. Why your content import itself at the name of Z selects you import content, but primarily from Google Docs, but also some there's some word features in there as well. There's a bunch of kind of some smaller ones and some ones like I draft tail anchors, which was fun to see get a little shout out earlier. And you know, I've been kind of jointly involved in um maintaining some others at various points, not right now, but you know I've jumped in on White

Speaker 3: Hall review, a few others along the way.

Speaker 4: So I'm uh Will. So and CFPB, we maintain collectively several packages. We have uh Django flags, which is a feature flag library for Django, and then Wagto Flags, which puts out Wagtail. We have Ragtail tree model admin, which is based on the deprecated model admin that create that creates a kind of a tree-shaped structure in the UI based on foreign key relations between models. We have Wagtail sharing, Wagtail inventory , the Wagtail content audit. package that we shared earlier. Yeah, so we we we have several of those packages and I

Speaker 4: I want to emphasize that at for us it's it's a team effort.

Speaker 2: I think we've probably represented like the top ten Wagtail packages up here.

Speaker 1: Probably, unfortunately. Well that that leads into my next question. So two of the biggest, most popular packages that I've made maintained or actually started by somebody else who then got me involved and then ran for the hills. Alex Gleason, some of you may remember Alex, but that was Wagtail Fawn Awesome. Wagtail error pages, which have sort of since been subsumed by Wagtail Core having better font support. But how do you get people interested in getting involved and working on packages with you and uh maybe make a pitch for getting more people involved?

Speaker 2: Yeah So for us it's kind of uh you know we we kind of uh latch on to to Wagtail Core itself in a sense. So oftentimes people uh We'll look how can I get involved in Wagtail? And it's kind of a daunting code base. I mean it's pretty big, it's pretty mature. Some parts of it are a bit intricate and uh a lot of times you know we could point people to a package and say well this package is uh a little bit easier to to get started with it's less involved than wagtail uh and a lot lot of times contributors come through that as well starting with a package so it in a sense we can kind of uh direct people from from Wagtail uh core as well

Speaker 3: Yeah, I mean I definitely agree. It's definitely a much more approachable starting point than the Wikil port in in many ways. There are different there are differences. My kill transfer I always feel has a particularly high barrier to entry just because involved connecting multiple W instances and that dev environment setup is a pain even when you're um used to it but I think Cynically, uh make a pack uh make a package that does something really cool and then have it not do something that someone desperately wants it to do. Or if you're being really bad, break it on the next web colour. So definitely don't do these things in don't do these things in real life. But like the best way to get people invested is to have that initial kind of rush of engagement to be doing some solving some cool problem. But obviously you don't have time to solve everyone's cool problem. And uh they'll have some

Speaker 3: something that latches onto yours and you can get them involved that way. The other thing I'll say is like it's really nice to be part of larger organizations. So that could be, you know, uh ADC like TorxBox, so we take on a lot of packages, and I'm really grateful To our support team who've stepped in to do like true uh Wikel upgrades on a number of my packages and I've just code reviewed them, which is great because they're things I was gonna get to, but they got done for me first and I could just be the reviewer, which is really nice. really nice to do but also things like the WhiteL organization or even Whiteout Nest, things where you've got a network of people to call on. So when you're busy around the time of WhiteO update or you've got someone else to call on, someone else has that motivation to call on come in and help out. So yeah, that's the public and the um organization side I think.

Speaker 3: Yeah.

Speaker 4: I think too it's hard to know necessarily what you find like you're solving a particular problem for yourself. yourself usually right you're not thinking what does someone else need out in the open source world and so a lot of times it's hard to know this thing I've made is that going to be useful to someone else and I think one way to get others involved is doing exactly this like coming to spaces like Wagtail Space to Django Commons in community settings and sharing sharing what you've done so that like you know our well to use our example from today like our what we think of as really specific content problems that we're struggling with might be useful there might like the solutions we've come up to those might be useful to others and in like the conversations we've had

Speaker 4: that's the case so it's like back to what you said at the beginning It's like the community, like being part of the package ecosystem is also, I think, being part of the community and just interacting with people and talking to them. Helps to get others.

Speaker 2: Yeah, on that note with the human element to it, um, as a maintainer, you're often uh very spread thin and uh it's very easy, you know, people like to file issues on GitHub. band it's it's very easy to just say if you wanted to implement it yourself go away you know

Speaker 1: I never do it on GitHub I just hit you up on Slack but uh but you know

Speaker 2: it's it's it's easy to get overwhelmed as a maintainer so sometimes you have to step back and say, okay, no, let me be nice to this person. I'm not gonna be mean. And uh

Speaker 1: helpful when I just type Vince it's broken.

Speaker 2: But uh you know but but being being uh you know uh welcoming in that way uh can definitely kind of turn people on to your package. For example, someone might ask about a feature and rather than just saying If you wanted to implement it yourself, it's open source, leave me alone, you know. You can just say, well, you know, I thought about it and I thought about implementing it this certain way. Maybe you could go in that direction. And a lot of times the person might come back a month or two later having implemented it based on that initial feedback that you gave them. So that that's another way for for maintainers especially is just you know remember to to to try and give people a little bit of direction rather than just uh you know um

Speaker 2: ignoring it or or something that's that's usually the easy first response a couple sentences and you're you're off you can give them something to work on

Speaker 1: Jacob dropped um Wagtail Nest really quickly and I don't know I I'm pretty sure that you know anybody who's watching this on YouTube in the future is gonna have no idea what we're talking about. How many people in this room know what Wagtail Nest is? One, two, so maybe like 10 to 15% of the people in this room who came to a wagtail conference know what wagtail nest is. So let's take a moment and talk about wagtail nest. Wagtail Nest is a group collaborative effort for us to maintain packages in the Wagtail ecosystem as a team. So none of us are doing it alone. And uh if anybody is looking to get more involved with Wagtail and the Wagtail ecosystem, ecosystem and you know improve your coding chops with some of the you know top software engineers in the world. Wagtailed nest is a great way to get involved.

Speaker 1: We need more people to help maintain I was just, you know, talking before here that one of my major goals for Sprints this year is I have a bunch of wagtail projects where I am the sole maintainer. That means if I win the lottery or get hit by a bus or whatever, abducted by aliens, those packages, you know, you're gonna have to go through a whole process with PyPI to sort of

Speaker 3: see what When the Lost Ray, you're not just gonna spend the rest of your life maintaining the fighting packers?

Speaker 1: Probably not. Probably not.

Speaker 4: I realize we haven't gotten to the joys part of this, but isn't that like Fulfilling.

Speaker 1: Yes, fulfilling. No, I'm I'm gonna be too busy running conferences, you see. So uh but uh Wagtail Nest for everybody out there is it's similar to you may have heard of Jazz Band for Django, which is a collaborative group of people that come together. And now uh our friend Tim Schilling is starting Django Commons. So there's several of these efforts to sort of create a group that together maintains several packages which also you know would allow you to kind of get out of the boredom of always being locked in. into one or share your specific piece of expertise across multiple packages. Like if I go down a deep dive today and learn about a new feature, like if I'm converting black and flake and i sort all to rough. once. Maybe I could do that for multiple packages while it's fresh in my mind. So uh there are a bunch of options for anybody here

Speaker 1: or anybody out there who is interested in getting involved in contributing to open source. Wagtail Nest is a great place to get started, I think. Has anybody uh heard would anyone like to add anything to Wagtail Nest beyond uh I'm sure Cohen is uh somewhere smiling right now.

Speaker 3: Yeah, nothing for me. I think that was a great summary.

Speaker 2: Yeah.

Speaker 1: Okay. Well we can move on. Um, you know, E, who was here yesterday, the work they have done at the Python. packaging authority that I mentioned earlier over the past couple of years uh to improve the experience for people like us has really been impressive. Like I remember when I first started in Python there wasn't a pip release for four or five years speaking, you know, we'll get onto developer burnout, but you know, it'd been basically maintained by one person in the most thankless job you can imagine with something that we mentioned, the criticality earlier. But you know, over the past few years I've become a huge fan of tools like Setup Tools SCM is a wonderful thing for people package maintainers where instead of having to make a completely separate configuration file saying these are the files I want in my package, it just introspects your git repository and says

Speaker 1: these are the files I want in my package. So you're not doing the same exact thing twice and it respects get ignore. Are there any other of these new goodies that you've seen in the Python packaging authority over the past couple years you'd want to mention that uh have been particularly handy?

Speaker 2: Um yeah I'll I'll bring one up and it's not so much a goodie as just python kind of evolving and that is the general use of pyproject. Toml. So uh Toml, some some people are still flame warring over that, but uh it's included in Python now as of 312, so there's no need for flame But uh you know we all kind of know anyone who's built a package has probably used setup. py in some capacity, uh but basically uh Python includes everything you need to build a package at this point and you can define it in your Pyproject. toml uh and uh from there I I think it's part of setup tools or something but uh it all kind of works uh under the hood you don't have to think about it. So

Speaker 2: I've done one package that way and there's like so much less to configure. You put a couple things in your Pyproject. toml and that's it. You run it. You run a command and it builds it and it publishes it and it does everything. So you could have a package with one single file, and that one single file could be a Pyproject. So it makes it very easy.

Speaker 1: Yeah, it can also handle your requirements, your tool configuration. So if you want to set your standards for code formatting and linting, you can do that all in one file now instead of having like eight different configuration files throughout your package. So even if you're not looking to publish the Pi PI, it's now best practice to have a Pi Pi project. toml at the root of any Django project.

Speaker 2: Yeah.

Speaker 1: So instead of having separate requirements files and things like that, you can just put it all in this one file and it's standardized and it's uh it's come really a long way.

Speaker 2: Yeah, and like you said, Tim, uh I also encourage people to do that because a really common scenario in like industry is that you need to have private, you need a private package. You don't want it on PyPI it has your business logic or something, right? So you don't necessarily need to make a quote unquote package. You can put that in a Python file, add a Python project. toml and then you can pip install that in your private you know proprietary project without having to uh think about IPI or anything like that

Speaker 3: Very boring answer, but I have to um second the Pyproject. tumble. I think that's the only one that's like I've really caught up with and it is really useful and particularly makes it much easier to standardize that configuration. for all your different tools which I really value. I'm sure there's more to catch up on and yeah it's definitely not from the back of the authority but I'm also quite excited about things like RAF combining all these different

Speaker 4: Yeah, we we've started doing like using Rough for all the things. in cf. gov and then in a few of our other packages and it 's awesome. The one thing that I've found delightful recently is PyPI trusted publishing from GitHub simplifies a lot of the kind of boilerplate that we put in repositories to like to to do the uploads to to PyPI. Like there's that combination of the trusted publishing GitHub actions and then the the PyPI's GitHub action to do that. has replaced a lot of a lot of the sort of thing that you don't like maintaining, which is is

Speaker 4: is great. We just need org support on PyPI. But I know it's coming sometime.

Speaker 1: It's on the way. It's coming. So it seems like a small problem that look at through one of these reports. And not there's no contention in the Python community about how it should be implemented either. So easy as pie, right? Easy as pie, P Y. Um so

Speaker 2: great.

Speaker 1: Well that does lead in you mentioned a lot of the tedium and a lot of the the like I just don't feel like it today. Like I sometimes hear that t teenager in the back of my head, but I don't wanna. It's like okay new versions of Wagtail is coming out. I know I've got three packages that I need to get compatible. I don't wanna I don't wanna We've all faced developer fatigue and potential burnout. Because you know sometimes it's a very thankless job maintaining maintaining these packages. What recommendations do you all have for avoiding that eventual burnout that may have come with maintaining a package and ditching it on me and running for the hills. Yeah.

Speaker 2: I would say the the biggest thing is don't be too ambitious. kind of take it slow because uh when you start doing a package it's really exciting like if you're you know everyone in this room is like really into this kind of stuff we're all nervous here and it's like you make your first Python package and you're like wow this is cool it's on PyPI it's on GitHub people are starring my uh repository and people are are filing issues and saying I'm using this in my uh such and such project and you're like wow this is everywhere it's it's really growing um and that's that's really exciting so you sometimes you get a little uh you get a little hit of that and you want to start say I want to do this feature and I want to do this feature and uh at the end of the day

Speaker 2: whatever you build into your packet you're gonna have to maintain forever or until some uh until you won the lottery. So um so you know just just kind of think about that and take it slow and uh a lot of stuff that we started doing in the very beginning We've kind of rolled back a little bit or deprecated some things here and there or tried to get some stuff kind of merged into Wagtail Core itself just to lessen our own burden and that's made it so much easier to maintain. So you know just don't try to over-engineer it when you're when you're starting.

Speaker 3: I think for me obviously I can go best advice, second best advice third best and I think best advice is dump it on Tim and run to the hills. If you're forcing me to go with the second but third best solutions, second one really is get other people involved. Like as we said, there are now organizations like Wagtail Nest, but also might, if you fought your company, there might be people who are just using it that you can get involved. And third kind of leads into that. Lower the barrier to entry. Like anything you're doing to make it easier for other people to get involved, to make it easier for other people to know the direction the package should be going, so that they're not throwing completely random solutions at the wall. And it's even doing to add documentation, so it's clear so it's clear how people should get started developing and if you're doing with tests.

Speaker 3: That stuff can be really boring, but it is multiple your effort there, boring as that might be, is multiplied exponentially by the fact that other people can now help you. you out rather than it all being on you. So I would say like put that small bit of effort into making your package approachable, lower the barrier to entry, and that effort is multiplied. And particularly like if you want to get involved with mentoring people through features like that's really helpful. Like I I've always encouraged people to get involved with Google Summer of Code because you put a bit of effort in as a mentor and don't get me wrong, it is a big effort, but that effort is massively multiplied by someone else enthusiastic coming up of the project and doing a lot of cool things. So yeah, community really.

Speaker 2: Great point about the tests and stuff, like having a little boilerplate test that someone can copy and paste and change like the first time I got a pull request that had a test and that had the feature the tests and the dot I was like, oh my god, this is so nice. Would

Speaker 1: that be?

Speaker 2: It was too long ago to remember. But yeah, so just give someone a test and a doc. be like here copy this and they'll do it. So

Speaker 4: I also think a little bit about something you said a minute uh minute ago, Vince, was about the time commitment and you know getting an issue and it's not working for someone and like most most everything we're talking about are libraries right that we've created a library that someone else is going to use And most of the time, like the times they're going to interact with those are probably when they're installing it for the first time and because they have a particular need and this seems to fit it. And if it does, that's great. They move on. And then they don't interact with it again until they need to update.

Speaker 2: Four years later.

Speaker 4: Right. And it's like those are both moments in which they're like Our libraries are potentially blocking them from achieving the actual thing they're trying to do, right? And so I think there's a degree of empathy that helps in those moments, which is exactly what you were talking about. And I think that also extends to us because I I know a lot of my fatigue and burnout comes when like there's a new wagtail release and then there's a question on like in like the package channel uh the wagtail stack of like hey this doesn't work with like wagtail sharing or something like that right and it's like that crap I gotta go like there is a need out there and I feel bad

Speaker 4: that like a library that I'm responsible for is blocking someone else right um so there's that degree of encouraging someone else to help and all the things that we can do ahead of that but I think there's also just allowing yourself to realize that you know it's okay we are humans we'll get to it when we can we can help others Let us do what we need to, but at the end of the day, we're putting open source out there because it's useful to someone else. And that's a moment in which it is useful to someone else if you just did the thing and that's hard.

Speaker 2: Yeah.

Speaker 4: You know? Um

Speaker 1: yeah one of

Speaker 4: the yeah

Speaker 1: one of the

Speaker 4: that doesn't actually answer the question. That just explains the feeling.

Speaker 1: One thing that we did that I think was a really big help and is kind of uh So we advocated to the Wharton School and specifically our division for time to work on open source. And at the bottom of every readme, and I'll just read We say this package was created by the staff of Wharton Research Data Services. We are thrilled that the Wharton School allows us a certain amount of time to contribute to open source. project. So it gives them a feather in their cap, encourages them to allow us to participate in this, allows us to reach out to other staff members and say, hey, this will look good on your performance appraisal. This is a strategy we can all use with our workplaces. But then we continue. We add features as they are necessary for our projects and try to keep up with issues and pull requests as best we can. Due to the constraints of our time and our full-time jobs, feature requests without a pull request

Speaker 1: may not be implemented, but we are always open to new ideas and grateful for contributions from our our users. So right up front we say, hey, it's wonderful you're here. We're glad you're using it. We'll do what we can, but we have full-time jobs too. So it's not our full-time job to make this work for you. It's our full-time job to make it work for us. And if that also works for you, setting those expectations up front and giving a feather in the cap to the employer to encourage them to allow us to continue to work on open source Source on their time while they're paying us can go a long way. And it's not a hard sell for employers typically when you point out like how much they're getting free from Wagtail and Django and so on. on how much developer happiness and employee happiness they're getting by letting this all happen. You know, that's a conversation that can happen with your employer

Speaker 1: and uh and really go a long way that I know a lot of people have haven't had and it can make you look like a leader and an advocate. Um that you know it may look good for your resume on your next performance appraisal if you're the one who brought sort of an open source consciousness to an organization. organization. There was a real aha moment within our organization. You know, we maintain Wagtail Code block, which is syntax highlighting for Wagtail. So when you type in the admin side you see real-time syntax syntax highlighting and on the flip side it's just a front-end shim for Prism JS. But uh you know that's because you know the website that Ryan's team over there maintains has thousands and thousands of code snippets in multiple languages on how to access our data. Our users use it every day. There's a lot of value there.

Speaker 1: We also maintained the Django Rest framework Excel endpoint converter, which we started getting some pretty major pull requests that allowed like for full colorization and templating and when our boss was like wait you mean we can now put all of our branding in every spreadsheet that's downloaded from the 300 000 excel spreadsheets that are downloaded from our platform every year and it It didn't cost me a dime in time or money. And we were like, uh-huh. He's like, I like this open source thing. You know, it's easy to point back to. like that you know share the release notes with your bosses on the new features you're getting that will save the staff time you know the comments section in web The new editor features.

Speaker 2: of like why are we even doing this? You know, why does open source even exist? Uh is it just because we're all neurotic and we feel the need to It's part of it. Yeah, it is part of it. But you know, the reality is I think most open source, uh at least the bigger projects out there they're promoting something or they're helping you use you know they're helping you use a paid service or they're promoting a service or they're promoting a company or an institution institution at some point. And you know, and that's great because you get something for free in exchange, uh, you know, the the publisher gets a little bit of visibility. So You know, I I encourage people to support if you're using an open source project and you really like it, you know, uh

Speaker 2: say thank you to a maintainer. But but then there's like there's other reasons why you would do it. And a lot of times it is Is simply out of the kindness of someone's heart. And you can't forget that. And I want to give a little shout out to a package that uh I would say 50% of all Django sites use and that is uh MySQL client. So you're either using PG uh Psycho PG. Psycho PG

Speaker 1: or Psycho PG now.

Speaker 2: Which is just Psycho PG. So you're either using that or you're using my SQL client for pretty much everybody. And uh MySQL client client is maintained by one person. And I learned that the hard way because I was fixing a bug in my SQL client and uh uh you know, the the maintainer was like, you know, I I'm out of the country for a couple months or something. Uh it's gonna, you know, I'll I'll I'll get to it in the next release. And it was like Uh you know, it was a a really long kind of lag time. Uh and I'm not complaining about that because it's literally one person doing it purely to be helpful. They're not profiting off of it in any way. shape or form and uh you know it's kind of scary it's like the the uh

Speaker 1: shout out to daniela varazza who maintains psycho bg yeah and uh pyote vc is mike cleahammer So the fact that we know these individuals' names is a a little terrifying that like the criticality of database connectivity in the Python world is sort of hyper concentrated. And you know, Marius uh the the Django fellow who just retired. uh also does the Oracle connection pretty much as a a a sort of single project yeah covered by his employer. So if you're really into database engines, do we have do we have an opportunity for you?

Speaker 4: in terms of like creating useful packages and one way to avoid burnout maybe is to avoid being that one little person on the XKC that we're all familiar with.

Speaker 2: Yeah.

Speaker 4: That has created something so useful everything else is built on it.

Speaker 1: Well the left pads. Who here, does everybody here know the Leftpad story? Okay, so Leftpad was a a Node. js package that just simply removed or pad or no padded the characters to the left side of a string, you can you know you could add three spaces to the left of a string or three zeros or whatever you want. It was used by every node. js as a dependency package as a dependency of a dependency of a dependency for somewhere in the supply chain. Due to a trademark dispute, the maintainer of it pulled it out of the Node. js NPM index, as is his right. And every node deployment in the world started failing. So to give you an idea of the criticality, if you want to look up the uh the Node. js left pad story, it's another reason why it is

Speaker 1: very good that everything in the Python community is owned by a nonprofit. Rather than a for-profit company, which was part of the dispute as well. So that's another reason to thank your Python packaging authority people too. So we're almost at time, but I wanted to also say, you know, we've talked a little bit about burnout and stuff like that but I also wanted to you know I was I played with Legos as a kid and I loved the creative process and I love putting things together and I love building Legos But I also love that moment of show and tell where I get to say, look what I made. And there is a lot of joy to maintaining. open source packages. It's all not doom and gloom. There's a lot of joy and a lot of fun to it. And I wanted to give everybody a chance to share some of the joy that you've gotten from maintaining packages. Oh

Speaker 2: yeah. Yeah, a lot of the uh the joy comes from, you know, when you when you know that you actually help someone. And uh it a lot of times uh we only get the negative feedback, right? Uh we you get all these issues filed and uh you never really hear or know if anyone's even you know, using something. Um so whenever you get that feedback really for me and someone's like, oh thanks, you know, I I just use this in uh my my company and my such and such user is like really happy now and and it made their job so much easier and it's like, oh, you know, that that really you you actually impacted somebody's life in some way. Uh and and that always is as a is a moving thing. So

Speaker 2: once again on the flip side, if you are using a package, I would encourage you to open an issue and just say, you know, I'm you uh thank you for making this because I can't Guarantee you that will make the maintainer stay.

Speaker 3: Yeah, I agree. It's lovely to find out someone is using something particularly if you don't suspect that's particularly anyone. So like this was that lovely little moment with Jimmy earlier when I found out that oh draft draft anchors, which are the package I threw together, you know, quite quickly to solve a problem. um was actually um helping you avoid some really hairy good nasty HTML and sunlight. That's great. But If I'm honest, my greatest jury packages, and this is gonna sound a little bloodthirsty, is when they die. And I mean this in the sense that they die for a good reason. They die because their niche is now fulfilled by something else because they're fulfilled by normally by Wagtail getting better. So we're no longer solving a problem that editors have with Wagtail, but because this is in Wagtail itself, and it means that way more people are getting to use this than they would have

Speaker 3: in the package and that is honestly the greatest joy in pain a package maintenance for me seeing that final example or a package become fundamentally less useful within most of the functional so things like um didn't create this myself, but um I mentor the GSOC project that created it, um the Witel Stringfield Migration Toolkit. When that went into YTL pool, I was over delayed because uh even though almost no one would be installing the package anymore. Because people could finally solve what had been quite a hairy problem in WhiteTel now much more easily. And you know, this has happened in other places, it's happened with Whiteel Review, it's happened with um the short-lived kind of WhiteL comments front-end package. I created too while you were kind of working on commenting. But yeah, I'm really, really happy.

Speaker 1: I didn't know that was you. We used that.

Speaker 3: Oh my and

Speaker 2: also a little history lesson for everyone. Django Migrations was started as a package back in the day. Yeah, South. Django did not have migrations. and it was absolutely mind-bending to try and change anything on any of your models. So yeah, some of the best things, the features of of uh tools that we use all started out as packages.

Speaker 4: Yeah, I think my answer would be a variation on the theme here. Like I enjoy solving interesting problems and I enjoy creating useful software and when I can do both and solve an interesting problem in a way that's useful to somebody else that's that's the ball Okay, right. That's that's everything.

Speaker 1: Yeah, and just you know, for a a person I mean peop most people here know I'm in I'm in recovery from drug and alcohol addiction. And I've been involved for many years running a website for local recovery here in Philadelphia that runs on Wagtail , CodeRed Extension, CRX, Wagtail CRX. And I've had people come up to me and say their lives have been saved by having this technology available so they can find meetings easily when they need them. So if you don't think it makes a difference in people's lives, it really really does and there are people across the world who are using open source technology for you know really life and death important stuff and when you take a step back you know we have a lot of fun here we do a lot of cool creative things and we do a lot of stuff for work.

Speaker 1: But you know, when you consider that, you know, it's being used for really critical things in the recovery community for one. I'm not the only one story there. You know, there's a lot of good being done out there. And you know, Wagtail was kind of spun out by Torchbox to do good for the world, to work with companies that are doing good for the world. And you know, being involved in a community and an ecosystem like that that has that easy thirst behind it has always been kind of extra special to me. So any uh any final words

Speaker 3: Or shall we uh

Speaker 2: I will I will end on if you have ever thought about creating a wagtail package, please do because we need more of them and uh Yeah. Yeah. Question?

Speaker 5: Not a question, but just a shout-out to this package called just under the wagtail or called cookie cutter wagtail package.

Speaker 2: Oh yeah, cookie cutter page.

Speaker 1: Cookie cutter wagtail, yes.

Speaker 5: get much attention but um I think it's it's it's been updated and uh at BikeToT in London last week Cohen made a uh a really cool little package like a simple version of BikeLeck And he showed it off in the in one of the the enlightening talks. And actually most of the enlightening talk was it was about how quick it was for him to do it by using his menu. So it gives you all the the the tooling and the CR

Speaker 2: Yeah, and for anyone who's not familiar with with Cookie Cutter, uh Cookie Cutter is just a tool that basically generates a boilerplate files for your project.

Speaker 5: So

Speaker 2: you don't actually have to use Cookie Cutter to make your project package it just kind of gives you a starting point.

Speaker 3: Yeah it's it's it's pretty nice. I believe it's using Flip now, which is yeah that's been fun.

Speaker 2: So Okay. Thanks Tim. We have probably a little bit of time for some lightning talk. Oh, one more question.

Speaker 6: Yeah, how can we get involved with Light Sound

Speaker 2: How can we get involved with Wagtail Ness?

Speaker 1: I think the best way is to probably hop onto the Slack and uh volunteer in the uh in the channels and people will pick you up and uh help get you involved and get you. access to Wagtail Nest.

Speaker 5: There is a Wagtail Nest channel.

Speaker 1: Yes. So the Wagtail Nest channel is on the Slack. I think is probably the best place to start Great question.

Speaker 4: Yeah. And I know uh Tim Schilling was looking for volunteers for uh Django Commons.

Speaker 1: Django Commons as well, if you're interested at the Django level too. So the there are a lot of exciting projects coming up and it 's just such an opportunity to be an on-ramp for people

Speaker 2: Now there's a question. At what point do Wagtail packages start uh making it into Django Com

Speaker 1: It's funny you ask that because I I mentioned Wagtail Nest to Tim already. So it'll be interesting to see what direction things go. It's good to see so many many good people doing so many good things.

Speaker 2: Thanks so much, Tim. Thanks everybody.

Speaker 1: Thank you, panel.

Speaker 2: Thank you very much.

Speaker 1: Thanks everyone for coming.

Speaker 2: So we've got a little bit of time for lightning.

Speaker 1: Yeah, we'll take uh about five minutes to set up for lightning talks.

Speaker 2: So give us a minute to set up and we will

Speaker 1: we'll be right back, Zoom people.