We are in week 5 of Djangonaut Space’s 2024 Session 1. For this session, I am a navigator for Team Neptune, with our focus being the Django Debug Toolbar project. I help maintain that project with Matthias Kestenholz among several other regular contributors.
If you‘re not familiar with Djangonaut Space, it’s an 8-week mentorship program to onboard Django contributors with a focus on sustainability, inclusivity, sponsorship and mentorship. Put another way, it’s where contributors launch.
Team Neptune, like all the other teams, has a navigator, a captain, Psalms Kalu, and three wonderful Djangonauts:
Their productivity and effort have been fantastic to watch. They have merged three PRs over the past five weeks and are working on more still. They are always asking what’s next and what else can be done. Their enthusiasm is exciting and infectious!
During my time, one thing I noticed is that despite having issues labeled as Newcomer Friendly, they rarely are. Some appear simple, but on closer look, they get complicated fast as the edge cases form. With others, a person has to read through 15 comments to understand what the goal is. It’s obvious that I could invest some time to make these issues easier to digest and implement. It’s certainly reasonable to sit down with an issue, consider the various implementation options and identify all the work involved to see it to completion. For others, it may make sense to close long support based ticket, then create a bug issue with a summary and link to the previous conversation.
The challenge for me has been in actively developing changes for the project. My role is definitely “maintenance”. If someone identifies an obvious bug, we’re pretty quick to resolve it. Or if someone creates a reasonable PR, it’s easy enough to review and merge it. In both cases, there’s a relatively quick and positive reward at the end. Doing the legwork to prep an issue for someone to implement could have a much later payoff. For better or worse, it’s less satisfactory for me when someone I never see again in the community tackles the easy issues. If I’m going to invest the effort to make a ticket easier, but stop short of delivering the actual change, I want there to be benefit elsewhere. Ideally, it’s in the community at large. I want it to be the seed to help someone contribute more confidently and frequently. Admittedly, it’s not fair for me to judge someone negatively for tackling an easy issue if I never see them again. I certainly don’t keep tabs on everyone, nor do I know everyone. There needs to be a measure of faith.
This is why Djangonaut Space is fantastic from a maintainer’s perspective. The Djangonauts in the program have shown their dedication to the community (be it Django, Python or Open Source Software). I’m happy to invest time and energy into making their experiences smoother and efforts more productive. I can see the various ways that they will take what they learn and reinvest it into our shared communities to make all our lives better. Djangonaut Space, in a way, solves the problem of determining who I can trust with my limited time and energy.
That went on longer than I expected. The last thing I wanted to mention are my goals for the rest of this session. I’d love to help my Djangonauts feel comfortable picking up tickets on their own and responding to questions about the toolbar in public. I’d love to guide them to a place where they feel a sense of ownership over the toolbar. My hope is through their confidence of knowing they are good enough to work on the toolbar, they can speak up in the community and are stellar enough to work on any project in the Django universe.