Django 6.x Steering Council Candidates

For a longer version of this statement you can read this post on my blog

For a video on similar topics, you can watch my recent Djangonaut Space session on YouTube

As a member of the Django community for the past 10 years, I've had the privilege of witnessing firsthand the project's growth and evolution.

Over the decade, I've seen many exciting changes and improvements that have shaped Django into the powerful tool it is today. However, I've also noticed a gradual slowing down of this evolution in recent years.

I have also benefited from said growth and Django's reliability and stability as I have been running a business who's main activity revolves around Django for that same amount of years. Whether it be creating, reviewing, maintaining or updating software. My application to the steering council is one of the ways in which I can give back to the community.

With my candidacy as a member of the Django Steering Council, I want to highlight my focus on ensuring Django remains relevant and sustainable for the next 20 years.

Lowering the barrier to contribution and involving a more diverse set of contributors

Most code contributions merged into Django are bug fixes or cleanups. I believe this trend is not due to an unusual abundance of bugs within the project but rather due to an unsustainable barrier to contributing new features or code improvements. Contributing to Django requires a significant amount of time, mental energy and effort, which can be discouraging to most. And often, those who have bit the bullet and gone through it once do not go through it a second or third time.

Myself and others have noted, more or less recently, that the process of contributing code to Django, including but not limited to DEPs, is daunting. The words "brutal" and "bureaucratic" have been used by myself and others to describe the process.

If elected, I aim to identify areas that hinder effective code contributions to Django and work towards simplifying the process of contributing code to the project; while keeping the right balance to also protect the time, energy and sanity of the Fellows and the review team.

Dealing with the realities of an aging code-base

As Django approaches its 20th anniversary, it's essential to acknowledge the aging code-base and technical debt accumulated over time. My goal is to initiate a review process of the existing code-base, carefully evaluating technical debt and identifying areas where improvements can be made without disrupting existing functionality.

Missing batteries and deadlines

One of the core principles of Django has always been its commitment to being a "batteries included" framework. However, in recent years, I've noticed that many of these essential features and tools have remained stagnant, without new additions or replacements emerging to support the evolving needs of our community.

Furthermore, the third-party application ecosystem that was once thriving and a jewel of the community, has become harder and harder to navigate and discover. It has also become more time-consuming for developers to have to evaluate a large set of third-party applications to solve a specific need.

As a member of the steering council I would like to work on bringing better visibility and discoverability of those 3rd-party packages and evaluate whether any such package should be brought into Django, either Django core or a spiritual successor to contrib or some other way. Some packages that come to mind are django-csp, django-cors and django-upgrade but this is in no way an exhaustive list.

Feature requests and Roadmap

I plan to use my position to champion "feature requests" – a critical aspect of the council's role that has never been utilized to this date. Feature requests being also a key part in being able to set a roadmap for Django and provide guidance to potential contributors on where to get started on their journey.

Code ownership and groups

My belief is that, as an unexpected side-effect of the dissolution of the core team and the high barrier to contribution, expertise in specific areas of Django has begun to erode. However, it can be regained through targeted efforts. People involved in the aforementioned code review process would be perfect candidates for these roles, as they'd already have taken a deep dive in thoroughly understanding specific areas of the framework.

Moreover, frequent contributors to an area of the framework are often well-positioned to take on a leading role in "owning" that part of the project. However, this implies recurring contributions to said area. I believe that we need to find ways to incentivize people to become area specialists. Which brings us back to need for lowering the barrier to contribution.

More generally, I think that the project can benefit from those specialized groups, starting with an ORM group.

Closing thoughts

I believe that everything listed here can technically be achieved during the 6.x cycle if I'm elected but... things take time in the Django world. So, I don't want to over-promise either.