We're all part of this Jazzband 5 years later

Hi

Speaker 1: Django community, I'm Janis. Most know me by my nickname Jazz. Today I want to talk to you about the project that I started five years ago called Jazz Band. But first, many thanks to the conference team for running Giant Con Europe these year this year under these sir special circumstances. I'm particularly happy about speaking to you all since 11 years ago I co-organized the first community-driven DjangoCon Europe in Berlin, in Germany, starting a series of conferences that brought our community together all over Europe. So thank you for being here. At my day job, I'm a software engineer at Anaconda and work on the Conda Package Manager that is mostly known for its use in the Python scientific community.

Speaker 1: It not only handles installation of Python packages, but also is designed to manage packages and dependencies within any software stack, including low-level dependencies that are often required in scientific environments Conda is more like a j Debian 's apt or homebrew on macOS than Python's Pip Package Manager. Before Anaconda, I was a staff software engineer at Mozilla, working first on the Django-based Mozilla Developer Network to document web technologies like HTML, CSS, and JavaScript. And then later on worked on the Mozilla data platform, working on data tools to manage and analyze the telemetry data that Firefox sends to Mozilla.

Speaker 1: But my open source background though, and the reason why I'm speaking here to you is a lot more varied and ran often in parallel and a few times in support of my day job. Years ago, I was an active Django core developer and worked in all kinds of projects in the nascent Django ecosystem. I've released a lot of early Django apps to the Python package index and through my work with the PinX project tried to figure out how best to build reusable reusable Django apps. One result, for example, was static files that was added as a contrib app to Django later. I also co-maintained Django's localization and the PIP and virtual Env projects for a few years Currently, I mostly volunteer on the Python Software Foundation board, the packaging working group and finance committee.

Speaker 1: And of course, Jazz Band. So speaking of jazz band, as you may know, Django is named after the popular jazz musician Django Reinhardt. Whose jazz manush was a favorite of one of Django's co-creators, Adrian Holovati, a jazz guitarist himself But before diving into the details about what the Jazz Band project is, I want to first acknowledge that jazz as an art form is deeply rooted in African American culture and is a lot uh older than many from my own heritage would sometimes recognize. Because these roots are important to know. to fully grasp the history of jazz and how it influenced the European variants like Django Reinhardt's work.

Speaker 1: This matters I think because when we use names and concepts to build technology communities They invoke different associations depending on our individual backgrounds. So what is Jasmine then, the project? Remember when I told you earlier that I was involved with a lot of projects and also package management? The obvious elephant in the room to make all of that possible was the rise of the platforms that would allow so-called social coding, such as Bitbucket, GitHub, and GitLab. These platforms have been very successful at lowering the barrier for collaboration and community building and I think Django is a good example where that ecosystem was able to attract generation after generation of contributors and users.

Speaker 1: I'm not sure if you've seen this graph yet. This is using data provided by the Python package index. And looks at the number of downloads of any project that has either Django or DJ in its name, excluding Django itself of course. That's million by the way. I don't know about you, but that trend is pretty clear. Except maybe I'm not sure what happened in 2018, to be honest. Let's speculate on that later together. My guess is this was a new generation of Django app authors and users that showed up So going back again a bit, in 2015 while while working on a number of Django apps, I noticed that many of the first generation of authors, including myself

Speaker 1: um had trouble finding others to share maintenance responsibilities or hand over their projects to the next generation of maintainers in the first place. And while the code hosting platforms would encourage creation and publishing, their interest in long-term maintenance and finding others to share that responsibility wasn't as obvious to them. Granted, I think since then it has improved and there was a number of publications about maintainership like Nadia Akbar is working in the public that is shown here on the slide. This is a great look into how open source in the public has been working out

Speaker 1: And as a maintainer myself, I felt like that the way how those platforms work with repository permissions and how forking and pull requests are used. Each project hosted there was kind of a silo that new contributors needed to break in first before they reached a perceived trust level that the authors required before collaborating more closely. Or to put it differently, I think I've seen too many projects that use core teams as organizational structures and isolate themselves too much for their own good. pr in effectively preventing an equal chance of participation by others. So the idea for Jazz Band was born out of that feeling, of a lack of participation, and my hope was to replace

Speaker 1: that social coding with cooperative coding that encourages collaboration and focuses less on the developer-user divide. One way to work towards that goal is to further reduce the barrier of entry. Basically stop having to prove yourself first to get a commit bit and instead rely on other techniques like codes of conduct to create trust in a group of people. For Jazz Band that means you can become a member of Jazz Band right now Go to jazzband. co, the website, click join, and you'll be able to commit to any of the projects that's since since you are automatically added as a member to the JazzBand GitHub organization. Actually, let me show you this real quick how it works so you

Speaker 1: uh it's easier to understand So this is the website uh of Jazz Band where you can see, for example um a bunch of information, some documentation, also the list of members and the list of projects and more information and the code of conduct of course but the more importantly down here there is a link login to join So if you click on this, you're automatically redirected to GitHub to authorize the Jazz band board to initiate the invitation to the GitHub organization. So if you click on here, you go back to the

Speaker 1: JASPEN site to consent to a number of items that we need to fetch information through the GitHub API in your name, etc. And once confirmed , you'll see you're already logged in on the Jasmine site. And to the final step to actually start the invitation to GitHub is you have to click on here the send invitation now uh link. And that's it, basically. From here on out, um GitHub has sent you an email to your inbox, to your email inbox, inviting you to the Jazz Pandic GitHub organization. You can also click on this link and see the invitation show up here right away. As you can see, the Jaspan bot invited you to join the Jazz Band organization 14 seconds ago.

Speaker 1: So if you click on the invitation, you just have to click this button here and you're done. You're now member of the GitHub organization for Jazz Band. You have access to all the repository there, repositories there and can create issues, review pull requests, etc. Of course, I encourage you to go back to the JazzBen site and actually take a look at the all the projects that are that exist in their organization. We have plenty of ways to uh to sort and explore more of those lists at those projects here. Some of those are more starred, some are less start. It's a great list of organization uh of of projects.

Speaker 1: So you see joining and starting to to to participate and review that pull request that you have been waiting on is straightforward. Adding a project though to Jazz Band goes through a vetting process to make sure that it follows the Jazz Band guidelines to and increases the chance that it will be successfully maintained by the Jazz Band members. That means that if a project wants to uh to join the Jasmine project, there it requires a few things before it can be accepted. Such as the project needs to cover a non-trivial feature set so that we can weed out toy projects from the get-go. There also needs to be documentation already, not just API docs, and if possible, host it on read the

Speaker 1: docs to get the automation for it. I also love following the diatex framework that Daniela uh introduced us to recently. There also needs to be tests. That run on GitHub actions automatically and can also be run easily in development environments for for Jaspan members. And finally and most importantly, the project is required to adopt the Jaspin Code of Conduct, which uses the well-known contributor covenant as its basis. There are usually other small things that will be noticed during the review of the project proposals, such as one example recently where a proposed project was using a license that wasn't approved by the open source initiative.

Speaker 1: Which alone could reduce the chance for interest and maintenance by the community drastically. So Now let's take a closer look at a few statistics from the past five years of Jazz Band. Brace yourself. Let's take a f first look at uh at the members. Jazz band has currently a bit more than 900 members, but over the years we actually had in total Close to four fourteen hundred unique members. That means around four hundred and fifty people have left again for one reason or another. Jazz band has also currently 40 uh 54 projects currently and over the past years we had in total 65.

Speaker 1: 20 projects on the other hand are currently being proposed to be transferred to Jazz Band. Fifty-seven of our members are currently acting as project leads. many and multiple projects at the same time. On the other hand, eight projects are without any lead, where I act as a pullback. Next, let's take a look at releases per month. Here you see the number of releases that the Jaspand projects have done to the Python package index in the past years. As you can see, it's been growing year over year and shows that with increase of number of projects, we also see an continued activity once they are transferred to Jazz Band. That's important to know to make sure that those projects are re

Speaker 1: receiving the maintenance that need they need. Now let's take a look at activity. 160 people were pushed in total 6,000 commits over the past years to Jazz Band projects. Four bots pushed four hundred and forty-five commits. And now that's a incredible statistics. Uh assist that 14,500 people start Jazz Band projects in in total of 22 ,000 times. So many stars. Let's take a look at issues. 2,000 people opened 3,000 new issues. And in total 4,000 people commented

Speaker 1: uh 17,000 times. That's a lot of comments. 600 people closed two and a half thousand issues, which means that we are currently having a surplus of issues Let's take a look at pull requests. Over the past years, a thousand people created in total 3,000 pull requests in all the Jazz Brand projects. And 300 people commented commented on those pull requests 3,000 times, which in which is which means both comments as well as code review comments. 270 people closed 3. 5,000 pull requests, which is a good indicator because that means that more pull requests were closed than opened. And again the bots

Speaker 1: the the bots opened in total 600 pull requests and four of those bots closed 200 pull requests again. Okay, I know this is a lot of data and a lot of numbers. I'm sorry, this was maybe too much. But as you can see, there's a lot of go a lot going on in Jazz Band projects. And you're probably wondering, how do we make sure there's no abuse or other malicious behavior? The security of digital infrastructure has been in the news recently and I think it's pretty r uh it's a pretty serious thing. Jazz Band uses a number of ways to prevent things like that. Like well documented mechan mechanisms to report code of conduct issues, security best practices and other technical abilities to enforce the core

Speaker 1: the code of conduct in the most extreme of violations. But the central part is treating the git repos as just an intermediate step for the software that people will actually use in the end through the Python package index. Jazz band project releases go through a verification process because of that, before reaching the Python package index. That's a responsibility of the project leads that I mentioned earlier. That works well because the majority of the time spent on maintenance of those projects is work on bug fixes and features, which is to say coding and code review. Releases on the other hand very rarely happen. So it's totally okay to have that as a separate step to review them.

Speaker 1: Those project leads don't have any other increased privileges and are determined during the proposal and onboarding process for projects that are moved to the Jasmine organization. And for the transfer to Jazz Band, we have the set of guidelines and proposal process to make sure there is enough information to secure the long-term maintenance of the project. It's not always just sunshine though to run jazz band. Besides personal attacks and conduct violations, it's It's not always easy to explain the intentions of Jasmine, of the Jazz Band project to new members or others that are considering to transfer a project. I've also seen big organizations trying to use Jazz Band to move their in-house projects into the open without interest in doing part of the maintain maintenance on their own.

Speaker 1: But I get why it would attract that attention, since figuring out sustainable development of open source projects is an important topic and more so with the continued rise of open source. But to but to be fair, I'm a bit worried whether Jasmine is up to the task and continue this growth. To recap, Jazz Band's current strategy is to lower the barrier for long-term maintenance, basically to help the existing mem maintainers to find new ones. But a sustainable way forward with that requires serious financial support to have a lasting effect. In that sense, I'm not super enthusiastic about the attempts of some platforms to create sponsorship programs like GitHub sponsors, since it seems to me

Speaker 1: mostly focusing on individuals donating to other people only. And don't get me wrong, I think that will obviously benefit a great number of people in a tiny way, but building a life on it is probably going to be a privilege of a small fraction of people on those platforms. In that context, I consider the social coding experiment to not have lived up to its promise, to create an equitable community that is truly social. Instead, I think it pulled a lot of people on its platform without providing effective means to monetize their participation. And this created a form of community debt that I think many of the organizations that profit from open source have yet to pay back.

Speaker 1: That's why I'm hopeful for the rise of cooperative coding that would make it easier for maintainers to woo to do what they love. and do well and companies to use their significant financial power to support them. Right now I see these platforms full of software and I think it's not really clear how it will be maintained in the future. Maybe in their spare time for free, maybe not at all. For Jazz Band, that leaves a lot of questions, like how will jazz band look like in the next five years? Can it sustain its growth and continue its mission of supporting maintainers to secure long-term maintenance? How can we attract the attention of companies to support those maintainers? And what needs to change in Jaspine's structure to do that?

Speaker 1: A few options have presented itself over the years. From corporate offers, blockchain promises to venture capital, all of which I turned down because I don't think it would be in the b in the spirit of Jasmine's mission to go in those directions. And I'm also a fan of nonprofits kind of personally since since they provide structure and frameworks to work mission-driven and not purely for financial gain. And here's the thing, my my search with for WayForward for Jasmine has just recently been successful. Since I'm I'm extremely happy to announce that as of a week ago, Jazz Band has been accepted as a fiscally sponsored project by the Python Software Foundation.

Speaker 1: Fiscal sponsorship, right? If you're not familiar with this, fiscal sponsorship, it's an option for US nonprofits like the Python Software Foundation. to provide the tax exempt status to mission-related projects like Jazz Band and handle back office issues and provide legal support, etc. It also allows the PSF most importantly to earmark donations to be used for those projects only. For Jazz Band, that means for the first time it has a broader legal status that would allow it to receive funds and work with third parties for its mission of securing the long-term maintenance of Jazz Band projects Other fiscally sponsored projects from the PSF are for example the Pellets Project, Django's sister web

Speaker 1: framework that has been able to grow a number of projects such as Flask. Ginger2, Click and Werkzeug, to group to a group of maintainers and secure its maintenance financially. Other fiscal sponsorees are user groups and conferences, like the PyLadies Community or the PyCascades Conference. So yeah, I'm really excited about this because this is a great step forward for Jazz Band. I'm not completely sure yet where this new setup will take us, of course. But it will certainly allow Jazz Band to extend its mission and increase its footprint in working toward a better sustainability of its project. Projects. Obviously, striking that balance between volunteered contribution and sponsored work will be the field of tension that needs to and it that needs input from the existing community members and new ones

Speaker 1: To make sure responsibilities in the membership continue to be fairly shared. My guess is that we'll need to evolve the Jazz Bank guidelines to better cater to what can be expected from volunteered contributions. and where sponsored work makes sense in support of the mission. Some other items that I think are in on a future roadmap for JazzBans are for example, I want to revamp Jaspin's infrastructure on website and do a redesign and do other user experience improvements. I also want to extend the documentation for onboarding new members as well as projects and document the lifecycle of a Jasmine project. I also want to start to formalize the evolution of jazz band

Speaker 1: guidelines, similar to Python's enhancement proposals. I also want to relaunch the Jasbin management to include more people and have a broader set of experiences. And finally, I also want to reach out to more organizations that have benefited from Jaspand projects and raise funds. So where is Jazz Band going in the next five years? I'm hoping to see an increase in participation from others to help make Jazz Band a continued success and evolve it as needed. I'm hoping to further the collaboration with organizations like the Django Software Foundation and learn from the experience with the Django Fellows program. Why not figure out ways to start a Jazz

Speaker 1: Band Fellow Program? Similarly, I'd like to take a look at participating in programs that increase the diversity in tech, like outreachy that I've seen so so successful at Mozilla. So, what would you like Jazz Band to do next? In any case, please feel invited to join Jazz Band and help make this happen. Remember, we are all part of this. Thank you. There we go. Okay. Hello. Hey everyone.

Speaker 2: Hi.

Speaker 1: Thanks for all the claps. Appreciate it.

Speaker 2: Yeah, thanks for the talk. It was very inspiring.

Speaker 1: I hope so. I I wanted to uh give a longer talk kind of but I tried ten times the recorder longer and it's kind of yeah. Anyways, so maybe we can actually use the time to discuss a little bit more about this in case we have questions. shoot. I have obviously there there's a ton of more things I can talk about what happened over the past five years, like the day-to-day of jazz band. So yeah

Speaker 2: I have a question if you want.

Speaker 1: Yeah.

Speaker 2: So I joined JetSpend um two years ago, I think, when I started using all the packages jet span and I'm still using some uh great piece of software like PipTools and Django configurations and other great software that are part of Jets band and um every time I'm asking myself if there is A way to protect some um of this very important piece of software like uh Django debug toolbar. because they now are very um important to all the stack in the Django ecosystem.

Speaker 2: I think everyone used Django, the back toolbar. And so if you ever thought about protecting some particular um used packages or or not, I think.

Speaker 1: Yeah. Um I think that's a great question and that goes kind of in the same uh direction that the current PSF fiscal sponsorship is great at is that so far this was a literally a privately run project, like Jazz Band as a as a kind of me trying to figure out ways to make it easier for everyone to kind of work on this. But you're right, there are obviously like serious um constraints to that. Such as on one hand I want to make sure that I'm not the bottleneck. So there's a kind of a catch 22. So that's why I I really hope that we can grow the team of people that manage Jazz Band itself and in

Speaker 1: its infrastructure in the future. Um as well as on the other hand uh basically providing the best practices so that the Jazz Band projects can can be securely maintained, such as like security best practices, making sure that For example, recently Django debug tool had a security release. And prior to that security release, I worked with the project leads of the of that project to make sure that everything is kind of uh communicated well with the Django project itself, that we have a blog post up and that we have um a CVE number about the about the incidents, uh about the security release. And like to summarize, I think

Speaker 1: yes, there are critical packages that are used more than many others. And there are many ways to make sure that this is the case. And for example, the fiscal sponsorship would allow us to make sure that we in the future may have people dealing with those very important tasks first so that it's clear that um you're not waiting on uh security related things for example Is that is that where you were going with that question? Is that does that make it?

Speaker 2: Yeah, you asked for my question. Thanks.

Speaker 1: Okay. So let me check whether there's something going on in Slack. Yes, we definitely need jazz hands emoji. I should have requested one before On the ear for the Slack organization, uh Slack team. So is someone uh earlier asked um on Slack What do the projects do without that don't have any project lead? Like no Jazz Band member that is that is volunteering to have that tiny bit of responsibility out to confirming releases. And in those cases, um, I just wanted to repeat what I wrote there. Uh in those cases, I'm the fallback for the for for that role. That means that when the release process is kick-started, not only the product leads usually get the email to make sure that it's confirmed, but

Speaker 1: me as the manager basically of the whole thing I also may uh I also get it so that we don't lose sight of those releases. Um and in the in case of no project leads, I'm just basically the only one receiving that email. Um My background in Django development means that I can most of the time help with those the Django projects to kind of facilitate that release of confirmation. Sometimes it was a little bit harder where I had to actually read up on what has changed since the last release and was there like some obvious Uh issues with the code that was introduced since then. But yeah, this is this is not a super great way and not really scalable, to be honest. So I recognize that.

Speaker 1: That's why I think it's best if we actually have people And multiple multiple people as well step up as project leads for those that are, that haven't. If you go to the project list on the Jaspin side, if you want to find out basically which Uh projects don't have a lead, you can basically see if I think filter by number of leads, if I recall correctly. Or maybe not, I don't know Something like that. And it's also visible on the project page that there is a project lead missing here. Obviously, we can improve that communication and the messaging quite a bit. Anyone else? Has anyone yeah, go ahead.

Speaker 3: Okay. Hi, Yanis. Thanks for your talk. I wanted to ask, are you only looking for code contributors or you're looking for people who can help? in other ways, not necessarily code contributions.

Speaker 1: Absolutely not. Not uh coding as we all know, and I or at least I hope that it's so far uh clear that code skills is just a important part obviously, but definitely just um part of the whole open source ecosystem. Documentation um triaging of issues. Honestly, like I'd love to get more designers involved to have, you know, for those projects such as Django debug toolbar, where it's obviously having a an actual front end where we need um uh user like user experience design skills. Um no no it's uh my opinion um and my hope at least it would kind of attract not

Speaker 1: only the the experts that already exist in the community, but also those that have kind of trouble uh kind of getting a um kind of foot in the door kind of in the open source world. And given the wide range of projects, both very simple and as well as very complex. I think there's kind of there is enough work for everyone to be clear. I think that's but um yeah, I hope that that explains it. Um No, no, I'm especially like my to me personally, like having been involved with a big Django documentation refactor years a years ago, I'm super interested in improving documentation both for beginners as well as for experts. So yeah.

Speaker 4: I've got a question.

Speaker 1: Yeah, go ahead.

Speaker 4: So I was wondering, could you expand a bit on the nature of the like how the Python Software Foundation supports you the financially. Like do they just give you a bunch of money and then you distribute it how you want? And then the stuff around corporate sponsorship Uh is it is the the realm of that have companies been reached out to and asked for money? Or is there a a a breakdown in a link between Finding who benefits financially from these products and urging them to support them. What's the breakdown there? What's missing? What is the reality of that?

Speaker 1: Yeah, makes sense. Okay, uh great questions. And I think that's actually quite um the current topic for me. Uh and I've been so in general that the Python Software Foundation may probably a lot of people know, but maybe you're not uh aware, is is a US based nonprofit. Um that's that is based uh most of its work on on donations from both the corporate sponsors as well as um regular like uh individual sponsories or to donate uh donors. Um and the fiscal sponsorship program that the PSF basically uh runs uh means that It extends the nonprofit umbrella, so to speak, to project like project-related or Python-related projects, such as conferences, meetups, that's why it was introduced originally.

Speaker 1: um to make sure that uh they don't have to set up individual legal entities to cover the work on on Python-based projects. So what that means in in in uh specifically means that uh the PSF doesn't hand me a chunk of money right away. But what that means is that Jazz Band as a fiscal sponsoree Is able to raise money uh through the PSF without having to have a separate illegal entity. That's a especially in the US, that's a huge deal because the tax exempt status means that uh big companies are looking for the that kind of thing uh first. In Europe, that's a different thing in our especially especially Um unfortunately uh you can't get a uh like the donations to the US entity of the PSF

Speaker 1: means you can't Get tax credits in Europe for that. So that's kind of the bummer and that's that sense. And I recognize that speaking to you at GenCon Europe means it's a lot less useful. But again, um A good, as I mentioned, a good example for how this works, for example, is the pellets projects where Flask and Sister projects are maintained. And they are receiving regular donations from both individuals as well as corporate uh sponsors. So and to your second questions kind of uh relating to that. Uh absolutely corporate sponsors are obviously uh the best friends uh of open source projects, to be clear. I think um there's um

Speaker 1: uh Like individual sponsors can only do so much. It's I think we need to be clear about this and to kind of be realistic about this. But on the other hand, corporate sponsors also profit much more so because they're basing their own projects and commercial success on it. So in my opinion, it's kind of a win-win situation. They can make sure that to uh support the projects that they're basing their own uh work on and at the same time support the continued development of them. And uh the jazz band Jazz band 's direction in that uh in that regard is a wave to start that process for Jazz Band. This is not a done deal kind of. Um in the past, uh

Speaker 1: indeed a lot of people have reached out to me. Hey, how can we support you? And uh frankly, since I am Yeah, since I was the uh the legal representation basically of that project meant that I didn't want to put this on my plate, frankly. Uh like dealing with uh sponsor money is uh and So all kinds of uh has has all kinds of red tape that if you are an individual, you you need to make be sure that you're willing to go in that direction. So yeah. So I'm I'm super happy, seriously. Even though in the recorded talk I didn't s look so happy, I'm seriously happy about that. Um because it means that I uh for the first time I have this legal entity that I can uh refer people to

Speaker 1: if they're asking.

Speaker 4: No, thank you. That's that's interesting. I didn't really understand the yeah the legal complexities of an individual versus an organization. And yeah, well congratulations. It's great.

Speaker 1: Yeah, and uh I honestly I can r really recommend uh reaching in case you have other and you know, for example Django Con Europe would be a good case. Um I've had the pleasure to to kickstart um or like co-collaborate with others to kickstart the Django Association in Germany back in the day when we ran DjangoCon Europe. That was the case where if we would have had the PSF to have to provide that umbrella to this legal umbrella, it would have been made making much more sense and made it much easier that way. Um because yeah Yeah, I hope that helps. Someone asked uh what's your favorite Jazz band package? That's a great idea to I should have used those. Port a little bit more.

Speaker 1: Damn it. Okay.

Speaker 5: Uh I do have a question.

Speaker 1: Yeah, go ahead.

Speaker 5: Um so I was wondering uh a bit more if you could talk a bit more about the process of uh transferring a package to chass band and to uh what is the role of a project so I I'm going to to make this a very concrete questions question. I'm maintaining a few packages that I'm not doing it well. But some of those packages are directly linked to some of my clients. So could I basically uh transfer my project to uh to jazz bands if it's accepted of course and become the project lead on jazz bands but then benefit from the help of the jazz band

Speaker 5: community to uh review and merge uh pull requests that are made uh to the project that I usually only see three weeks later and things like that.

Speaker 1: Yeah. It's um it's a very good question and frankly kind of hitting the nail on the head. That's uh a constant struggle to figure this out. Um so One thing you already mentioned, the guidelines are a very high-level view on what goes in and and and it makes sense. Uh that's and I re recognize that also, that it's based on the a lot on my own personal experience with maintenance. So um but I really want to stress that to answer this Um for good, it depends on the project, basically. Um we need you would need to sit down, see how it goes. But uh you becoming a project lead is perfect makes perfect sense because Um what I've seen in the past um

Speaker 1: is that when projects were transferred to Jazz Band, is that for example some of those projects uh the original authors or author did not want to do anything with it anymore. They basically said, okay, I'm done with this. I don't have time with it for it anymore. For whatever reason. And that's fair. You know, that's uh it's more important and it's uh better to then have someone to hand it uh uh over than to just have it linger or even like being kind of a dead project basically um So yes, you uh it's it's easier to to have original authors being project leads. What I usually try to have is have a separate person uh or member of

Speaker 1: JSPand in in addition to that original author. So that it's kind of a natural progress of communicating with each other. um kind of a little bit of forcing the hand of the original author to share why the project was maintained in a certain way, etc. And that's really key because remember, the the intent of Jazz Band is to make sure that projects are maintained for long term. And that means um kind of uh carrying forward what past decisions were made were made and why. So yeah. Feel free to open uh uh an application and we can uh can basically review it and see what's going on

Speaker 5: Thanks.

Speaker 1: Yeah, I'm I'm happy to. So yeah, anyone else? Let me see. Someone okay, there are no

Speaker 6: okay

Speaker 1: a couple of people already said.

Speaker 6: Hi Yannis.

Speaker 1: Yeah, hello

Speaker 6: Yeah, hello. Thanks for the talk and thanks for everything you do. Inspiring. My question is about new contributors. People come to Django and they're like, can we get started on Django? And the answer is always yes, right? Of course you can get started. But Django is big and bulky and it can be hard. Um You know, it it's old and there aren't necessarily smaller tickets. And one thing I'm I always say is, well, you know, there are lots of third-party packages which can be a really good place to get started. And I'm kind of always thinking that looking at Jazz Band and thinking maybe there's a kind of a tie-in, maybe there's a way we can have an on-ramp where we can kind of s advertise Jazz band as part of the getting involved in Django as well. I wonder if you have any kind of thoughts on that. Because

Speaker 6: you know, a smaller project in Jaz Band might be an easier first contribution.

Speaker 1: Yeah, absolutely. And I did didn't we talk about this last year? I think uh this is really um Absolutely dear to my heart because you know remember that's my own past as well. It's that I stumbled into Django development and did not only Django itself but also worked on plenty of those other small smaller uh applications. And I think that in a how should I say this? Uh for the health of Django itself, I think it mean it it really matters that we kind of have kind of make sure that we can point new contributors to the to projects that are not as complex as Django itself. And I, you know, I totally get where what you're saying is that the easy pickings are all gone, kind of it's the low-hanging fruit and

Speaker 1: That's okay, you know, the Django 's uh age is kind of showing. And um so yeah, absolutely. I think uh I've been meaning to find a good way to do this, um, and frankly I'd I'd be interested to see whether the the Django Software Foundation would be interested to kind of Find a good collaborative collaboration there. Um so far I just don't I haven't really found uh good way to formalize this. I think s in the past the Google Zum of Code was usually a good way to formalize this. Yeah. I'm I'm all ears. If you have uh suggestions that are um

Speaker 6: Okay, fine.

Speaker 1: Yeah, I'm I'm totally open

Speaker 6: Well I I have I have plenty of ideas and plenty of like thoughts so we we can discuss and I guess we may have we may have talked about last year but then The world intervened, I think. So we haven't made much progress in the last world. That's okay.

Speaker 1: The jazz band should be able to handle a situation such as last year, frankly. That's kind of the whole point, is that we we all have lives. We We need to recognize that uh having a good work-life balance is important and open source tends to kind of uh hide that a little bit. Uh that uh because everyone wants to contribute and be part of something, but it's better if we kind of share that responsibility. It's just as simple as much we are much more powerful that way.

Speaker 6: Yeah, I mean then everybody needs a break, you know.

Speaker 1: Yes. Absolutely.

Speaker 6: Thank you. Thank you, Yes.

Speaker 1: No problem.

Speaker 6: Let's talk.

Speaker 1: Okay, anyone else? I think we are how long you know is is anyone coming into those QA sessions and saying no stop

Speaker 2: I think we can speak time we want.

Speaker 1: Just want to make sure that you're not missing any of the other what's what's when's the next?

Speaker 2: If two

Speaker 1: thirty oh it already started, right?

Speaker 2: If I if I can I want to ask a question to you and to Carlton at the same time because I was uh my thought was there is some very important uh peggies in in jet 's band um maybe uh some of them will be part of the Django Foundation because they are so important now

Speaker 1: Which is which project is that?

Speaker 2: I I was my thought was debug toolbar or other very important pieces of software. I was also uh um talking about I don't know Django Redis and I I I saw that there is a project now to integrate directly. Um so I don't know if it's it's better to don't don't repeat yourself to reuse um the effort we already uh put in the these packages to I don't know protect and in the Django Foundation itself.

Speaker 1: Colton, you want to go first?

Speaker 6: Anna 's here as well, so. Uh what would I say? Um We can't pull too much into Django itself, into Django Django, simply because there isn't the capacity to maintain it within Django Django. And so one important thing is to keep Django small enough so that within the capacity that the the DSF has, Django is maintainable. If we pulled in Django Debug, you know, uh chat the channels repos are already part of Jack the Django organization and they're massively under maintained because it's just me on my spare time trying to do it, it's all the worst things, and so we we need more comp um maintainers there. We bring lots of Jazz Band repos in. It's like a danger of flooding Django.

Speaker 6: So in a way I'd say keep Django safe, keep it separate so that we know we can protect it. In the same breath I'd say, but we have to make sure we support Jazz Band with all we can. And we have to, you know, so this thing, this announcement with the PSF is just amazing. That's awesome. Just on the Redis comment, we're going to have a back end for Redis, but it's not going to compete with Django Redis because it's just going to be very simple, you know, equivalent to the existing back-end cache backends. It's not going to do all the extra things that Django Redis does. So those those are you know in initial thoughts on what you initially said. Um then I want to know what Anna Thanks.

Speaker 1: Oh yeah. So let me just uh say something real quick because I think we want to hear hear what's what Anna said uh wants to say as well. Um In certain ways uh Jasmine was in the time also created because I I mean I mentioned that earlier the experience I had with m maintenance. And in particular, I was uh one of the people that uh removed Django local flavor, uh like the the Contrab app local flavor from the Django code base and put it into a separate package Same for form tools and the was the last one. I think there was a third one. And we put it in the into the Django GitHub organization. and it kind of was kind of not receiving any

Speaker 1: contributions there. So in many ways I'm I can totally echo what Carlton says is that I think it's really delicate. Oh no no hot delicate It's very uh I think it's very hard to get focus from the co community to contribute to Django projects that are not Django itself. It's just a I don't know why. Um so that's why I I feel that personally third party organizations that have their own way to maintain are better suited to deal with even with high level or very important projects. It's um it's kind of but on the other hand, uh again, like Jazz band and the PSF uh sponsorship now

Speaker 1: may allow kind of a little bit more of an official way to do this. Um so yeah, that's my hope uh at least. But yeah, let me actually uh let Anna say something about it. Go ahead.

Speaker 3: All right. Okay. So uh I represent the DSF, which is basically the legal and fundraising. I'm of The Django Software Foundation. So I can't speak as to merging uh those other Django packages into Django that has to be approved by the Technological Board. However, on behalf of the DSF, we would be happy to supports uh Jess Bend in other ways. Um we have um some packages like uh Django packages Uh at one point in time, uh Danny wanted it to end it over to the DSA for us to manage the course and we can help with that. If you need help maybe with uh costs maybe we can find ways to help with that.

Speaker 3: If you want to hand over a project to to the DSF, uh We accept you handing over, but then it will no longer be in your control. So but we have to go through certain processes. So I think we it's better for them to remain with uh Just and if you need help from the JSF, the JSF is always open to assist, especially if packages are widely used in the Django community. We are happy to assist anything that has to do with Django. But not necessarily taking them under the arm of uh the DSF. So far we've got only two fellows, uh one who works part-time and one who works full-time. So I think bringing in more projects would be quite a lot to handle for us. But we are happy to support

Speaker 3: in other ways. It

Speaker 1: it's really great to hear and I appreciate you uh doing all that work because I think you know again it's essential for us to I think to you know for everyone here to keep Django in a in a safe way and like having the fellows work on this, I think that's really essential. To be clear, I think It's okay for us to keep this in the jazz band. Uh any help would be super cool. And I'm I'm yeah, I'm I'm happy to collaborate on figuring out ways to to do this. like specifically like what's uh what's an area where jazz band is failing at providing the the appropriate care to the packages. And then you know if if we find those areas, then we can I think uh come with forward with a good example. Um since uh you know I know I know DSF

Speaker 1: foundation work is a lot to handle already. So I appreciate your work by the way, Anna. Thank you.

Speaker 3: Thank you. And we are happy to help. If you want, we can uh continue this conversation maybe sometime later and cut on as well.

Speaker 1: Yeah, love that.

Speaker 3: Yeah

Speaker 6: Okay. Listen, apologize, I have to run. I'm gonna go by the way. Thank you. Bye

Speaker 1: bye.

Speaker 3: Thank you.

Speaker 2: Bye.

Speaker 3: Bye.

Speaker 1: In case uh unless anyone has a question.

Speaker 7: I I do have one. Um I was wondering because one of the requirements, even though it's not uh final I think uh is uh using the GitHub actions and some other tools that are baked into GitHub. Does your security policy also involve using the newish security tab on the on GitHub. So for generating CVEs and all of that. I I noticed on your website you have a a contact policy for responsible disclosure, but can you speak a bit about that and if uh An example that has happened in the past, maybe?

Speaker 1: Yeah, of course. Um so this is absolutely uh we we are Like especially you're you're referring to the incident that happened recently aro around uh code con. Um sorry.

Speaker 7: I have no idea about any incidents. I'm just curious about it because I'm currently working on a security company, so just wondering.

Speaker 1: No, no, of course. So we are definitely following the best practices that that pr GitHub provides because that's kind of a given that all the Jasmine projects are hosted there. That means that we are trying to follow their lead as well, both with best practices as well as the tooling that they provide for a security um uh incidents. So and recently we um that was kind of the the first where we used that pattern. Um we had other security releases in the past where we did it basically the old fashioned way and just released it and made an announcement, etc. Um but uh recently we had a this debug toolbar um issue which was quite complex given the fact that it went back years. Um And it were like multiple like major versions were

Speaker 1: vulnerable too in SD Bug. And in those cases, we uh got a CDE before uh created uh um the secure the security incident uh through the regular GitHub functionality, and then worked with the project leads to to ship those. Um those releases. And that was in my opinion, like that's personally that was my first use of the that tool tool chain that GitHub provided. And what that was actually quite um satisfying to use. And before that it was basically similarly done, just not using GitHub's own tools. Um yeah. Does it make um

Speaker 7: Yeah, yeah. Yeah, thank you. And um check it out because I'm interested in this type of things.

Speaker 1: No, absolutely. I

Speaker 7: any

Speaker 1: that's that's the more and yes, uh I think the um Yeah, especially since everyone just can just join um jazz band and commit right away to the repos. We need to be very clear that we have to have be a little more s restrictive than other regular Django projects out there on GitHub. Um especially around like which uh CI system to use, for example, we um uh recently made the decision to stop using like any kind of CI system that the pr the projects may have used before they transfer transfer to Jazz Band. And instead just rely on GitHub actions because it allows to focus on Just that one platform that we can be secure and um yeah. And there are other

Speaker 1: I mentioned uh mentioned it in a talk. I let me say to say that this is an ongoing process that I will have more to say in a soon about it because we will need to button down the hatches a little bit more um and and make sure that that the more projects are on the jazz band um in the jazz band organization uh that we can make sure that they are secured and um Yeah, not opening up.

Speaker 7: Thank you.

Speaker 1: Yeah, no problem. So let me see. We are losing people already. I am in the spirit of wait wait, there's someone saying Carlton, usually new contributors. Usually new contributors go to GitHub org page and look for highly updated maintained packages and start to look. Yeah Um yes, the repos which don't require active maintenance therefore just aren't discoverable enough to attract new contributors as they Lag behind in the list. Yes, that's kind of a big uh problem and sometimes a little bit awkward with the JSBand website because it's a separate entity where you have to go to to find your projects. And as we know, the GitHub user uh

Speaker 1: interface is not the kind of doesn't cater to that type of um discoverability. It's not yeah. It's a it's an ongoing problem, is similar to adjustment. I do hope that we get the time and funds to do a redesign and to improve that so that it's easier to find. Just been projects that need care. But yeah. So I think that's it. Going once, going twice. Thanks all for being here. I really appreciate you listening. And yeah. We're all part of this.

Speaker 2: Tory talk.

Speaker 1: Yeah. Bye all