Category: tech

Hi there, for those that haven’t come across me yet, I’m very active on the Discord, joining a couple of years ago, I serve as a moderator and generally helping out. I have also authored a Working Group proposal that is almost ready to go live, pending Board approval. Finally I organise the monthly Django Social in Cambridge.

However perhaps what is most relevant to my nomination for the Steering Council are the blog posts I have written this year. They have been short & snappy where I have prodded and explained different aspects of using Django, the contributing process and other aspects of the community.

I am nominating myself for the Steering Council to ensure that Django has a secure future. Personally I have used Django for the last 12 years and it has been integral to my software engineering career. The last two and half years have been the best in terms of getting involved in the community and has increased my passion for improving Django itself and seeing it have a future beyond my personal usage.

While there is energy in the community, the technical vision has stagnated and needs a reboot. As Django is about to celebrate it’s 20th birthday, I want to see Django celebrate it’s 30th & 40th birthday’s and still be relevant to the world of web development. But what does that mean for us now as a community and how to do we ensure that future? In short I believe the next Steering Council needs to experiment with a range of ideas and gauge the community reaction to them. These ideas will form the first iteration of processes that future Steering Council’s can progress and mature.

To me these ideas need to focus on the following high level goals:

• Transparency & Consistency of communication
• Clearer, simpler Governance
• Vision of where Django could be in 10 or 20 years from now.
• Strengthening the community through teams that provides growth for each and every member

Each of these goals have plenty of actionable items… for example:

• Communication: Coordinate with the Board to recognise the work of the wider ecosystem of packages on the website and in other resources.
• Governance: Deeply examine the DEP process, simplify it where needed so we can normalise the process of writing a DEP to be closer to Forum post.
• Vision: Identify potential landmark features for the 6.X release cycle and beyond. Even propose what features might be in the Django 11.X cycle (10 years time).
• Teams: Start to create career tracks within the community, this would include Djangonaut space, Google Summer of Code, existing teams and new teams yet to be formed.

Do I expect this next Steering Council to achieve all of these goals above in one go? While these goals are idealistic, I expect this next Council to lay the foundations for futures Council’s to thrive and creating the on-ramps for a larger vibrant community of Djangonauts, ensuring the Django’s future is bright and secure.

Feel free to reach out to me if you have further questions about anything above.

I’m running for the Steering Council to help push Django forward over the 6.x release cycle.

We’re at an exciting time for the framework. There’s a whole fresh wave of new contributors keen to experiment. I think we should lean into that. My particular interest here is in helping to support, promote, and leverage the third party ecosystem better that we have done. I wrote at some length on that in my recent Thoughts on Django’s Core, if you’d like the details.

Beyond that, I want to help our mentoring effort. There’s a big gap between starting to contribute and staying to maintain. We’ve got all the resources we need to turn the new generation of Django’s contributors into its next generation of maintainers. That’s where I increasingly see my time and focus being spent over the coming years.

I was unsure whether to run for election or not. Whilst I was never part of the old Django Core, as a former Fellow, and maintainer of packages such DRF, django-filter, and crispy forms, I’m certainly towards the older-guard side of things, that we’ve heard much about in recent posts. We’re at a delicate time. With the governance updates needed, I feel that I still have lots to offer, and can be helpful in advancing those. As I say, I think we’re at an exciting time for the framework. I’d be honoured to serve if chosen.

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.

The community does a really great job of reaching consensus post-BDFLs but occasionally decisions do need to be made and a direction chosen.

I would like to think my long history with Django and my wide and varied use of it as a consultant gives me a unique perspective not just as a consumer of Django but as a manager/executive helping others to make decisions around how and when to use Django. The decisions that are made impact many people and organizations in sometimes subtle and non-obviously ways. I have a ton of skin in this particular game personally.

Django has been a huge part of what has driven my career and I would be honored to help steer for a bit.

For those who don’t know me, I’ve been using Django professionally for almost a decade, spending over half of that focusing on performance and security. I’m also on the Core team for Wagtail CMS.

Django has a great reputation for being “batteries included” and for “perfectionists”, however that reputation is starting to age. Now, people think of Django and clunky, slow, and only useful for building big monoliths. Many developers choose leaner frameworks, and end up having to re-implement Django’s batteries themselves, instead of starting with Django and focusing on building their application.

For Django to progress, it needs to recharge its batteries. The ticket backlog, as well as many developer’s dreams are filled with great feature ideas just looking for a little push in the right direction. Not just the big features like 2FA, Background Tasks or even type hints, but also quality of life improvements to templates, views or even the user model. To achieve this, it requires more than just code – it takes people.

From personal experience, I’ve seen the friction from trying to add even small features to Django, and the mountains to climb to contribute large features. To encourage new contributors, that needs to change – just because it’s the way it’s always been, doesn’t mean it has to continue. Django is a big, complex, highly depended on project, but that doesn’t mean it needs to move at a snail’s pace for everything, nor does every contribution need to be 100% perfect first time. Open source projects are built on passion, which is built up over time but destroyed in seconds. By fostering and enabling that passion, the Django contributor community can flourish.

By the time Django hits 7.0, I’d love to see it more modern, more sustainable, and living up to the ideas we all have for it.

Hi! I’m Lily and I’ve been a contributor to Django for about a decade, mainly working on the ORM. My biggest contributions were adding check constraints and db_default. I’ve also contributed as a mentor within the Django Community. I was a navigator for the pilot of Djangonaut Space (and a backup navigator in following sessions) and a Google Summer of Code mentor for the Composite Primary Keys project. I also joined the triage and review team in 2023.

As a member of the Steering Council I want to enable more people to contribute to the Django codebase and surrounding projects. I think in recent years there has been too much friction in getting a change to Django agreed. I have seen several forum threads fail to gain consensus and I’ve experienced this frustration myself too. I also think the DEP process needs an overhaul to make creating a DEP much easier and significantly less intimidating, making it easier to move from a forum discussion to a decision when otherwise the status quo of doing nothing would win.

I believe a more proactive Steering Council will enable more proposals to move forward and I look forward to being a part of this. I will bring my years of experience of the Django codebase and processes to the Steering Council to provide the technical leadership we need.

I’m running for the Steering Council so that I might be able to help others. I wouldn’t be in the position I am today without someone very helpful on StackOverflow many years ago who took the time to help me with my first endeavour with python.

Over the years I’ve strived to help others in their journey with python & django, an aim aided by becoming a navigator for djangonaut space and the technical lead of the Django CMS Association. Through all of this I’ve acted as a facilitator to help people both professionally and in open source, something which ties in with discussions going on about the SC being the facilitator for the continued growth of the Django community and framework itself.

Hello, I’m Ryan Cheley and I’ve decided to stand for the Django 6.x Steering Council.

My journey with the Django community began in March 2022 when I started contributing pull requests to DjangoPackages. My initial contributions quickly led to deeper involvement, and I was grateful and honored to be asked to be a maintainer following DjangoCon US 2022.

At the DjangoCon US 2022 Sprints, I worked on a SQLite-related bug in Django’s ORM. This proved so valuable that I was was able to give a talk about my experience at DjangoCon US 2023, where I delivered my talk “Contributing to Django or How I learned to stop worrying and just try to fix a bug in the ORM”.

Building on this experience, I returned to DCUS 2024 to present on “Error Culture” where I took a deep dive into the widespread but often overlooked issue of how organizations manage error alerts in technology and programming domains.

My commitment to the Django ecosystem extends beyond code contributions. I’ve served as a Navigator for two sessions of Djangonaut Space, helping guide newcomers through their first contributions to Django. This role has allowed me to give back to the community while developing my mentorship skills.

As one of the admins for Django Commons I work with some amazing folks to help provide an organization that works to improve the maintainer experience.

Additionally, I’ve made various contributions to Django Core, including both code improvements and documentation enhancements.

Throughout my involvement with Django, I’ve consistently shown a commitment to both technical excellence and community building. My experience spans coding, documentation, mentorship, and public speaking, reflecting my holistic approach to contributing to the Django ecosystem.

My focus will be in creating sustainable and inclusive leadership structures. This would, in turn, not only provide help and support for current Django leadership, but also develop and empower future leaders.

The avenues to meet these goals include gathering diverse candidates, providing mentorship opportunities, clearly communicating expectations, and removing financial barriers to participation.

As a member of the Django Steering Council (SC) for the 6.x series, I hope to be able to accomplish the following with my fellow SC Members:

• Establish a governance structure that allows the SC to be successful going forward by:
  • Providing Mentorship for future potential SC members from the Community
  • Reviewing the 18-month requirements for eligibility for SC
  • Communicating the expectations for SC role in Community
  • Working to increase the diversity of those that are willing and able to stand for the SC in the 7.x series and going forward
• Collaborate with Working Groups to
  • ease burden of fellows in a meaningful way via the Fellowship Working Group
  • work with Social Media Working Group to promote new or upcoming features
• Write up weekly / monthly reports, similar to the fellows reports
• Work with the Django Software Foundation(DSF) Board to establish a stipend for 7.x SC members going forward to support their work and allow more diverse participation
• Implement a road map for Django drawing input and inspiration from the Community, specifically from these sources
• Adam G Hill post
• Thibaud Colas Forum post
• Paolo Melichiore post
• Timo Zimmerman post
• Roadmap work from early 2024
• Work on and complete a DEPs to
  • Remove Dead Batteries, similar to Python PEP 594
  • Determine the long term viability of Trac, research alternatives, and come up with triggers that would lead to a migration if/when necessary.
• Review and approve or reject all current draft DEPs

The Django community has done so much for me. I’m hoping that with my involvement on the Steering Council I’m able to work to do my part to ensure the long term success and viability of the Django community and leave it in a better place than I found it.

I’ve worked professionally with Django and Python for the past 13 years. I’ve mostly lurked on the mailing lists and forums, but I have been around maintaining some smaller projects, most notably among them being django-safemigrate, aldjemy, hirefire, tox-travis, and backports.csv. I had the privilege of giving a talk at DjangoCon 2024 about Passkeys and Django.

Django has excelled in three areas. We take a batteries-included approach that empowers new developers, we have strong community governance, and we are conservative about the changes we make to maintain stability. These have been critical to Django’s success, but the combination has made it challenging for Django to keep up with the changing technology landscape.

To allow Django meet the changing needs of our users both now and for the future, we need to think carefully about the important parts of each of those priorities, and tune the tension between them to allow the Django community to thrive.

Django should transition away from including batteries directly, and toward enabling add-on batteries. We should favor proposals that empower interoperability between a variety of third party batteries (e.g. the Background Workers DEP), and disfavor proposals that wish to bless a particular solution in core, no matter how wonderful the solution is (e.g. HTMX).

Django should be encouraging work that aims to expose third-party packages in our official documentation and communication channels, especially those that implement core interoperability interfaces. This will make room for new ideas and more approaches.

Django should seek to make a clear boundary around a smaller core where our preference for stability is the more important factor in empowering our diverse community.

Django should favor changes that bring it into alignment with Python community standards. It should favor this even over the “one way to do it” principle. By encouraging using Python standards, Django will better meet its responsibility as an entryway for new Python developers to be better equipped to grow in Python generally. For example, Django could encourage using appropriate standards in the pyproject.toml over extending Django-centric idioms like adding to the settings.py.

Django should encourage proposals that seek to lower the footprint of a new project. Projects like Nanodjango should inspire us to make starting with Django trivial and minimal, and make each step a newcomer might take to grow be as small as possible, so they only need to meet only the challenges required by the work they are needing to do.

Django should favor proposals to begin to include correct types, even to the point of carefully making any necessary breaking changes to help make the types correct and usable.

The DSF should, when financially feasible, fund non-core batteries that can empower the community. It may be appropriate for the DSF to make some requirements about the necessary governance required of these projects in order to qualify for funding.

The Steering Council should strongly consider recommending changes to its decision making process to make it more feasible to make and reverse decisions as it faces new challenges. Stability is maintained by active, careful, and persistent effort, not indecision.

By making decisions with these principles in mind, we can help our community maintain the root of our goals: A stable community-governed base, empowering a diverse community that excels in the fast-paced world of web development, and being a gateway for new developers.

Django’s best strength is that it’s built by its community – but that’s also a weakness. The reality of a project of Django’s scale that’s been around for so long, and has so many contributors, is that making substantial changes becomes increasingly difficult. You may have heard talks about how daunting it can be to get a PR merged into Django, or how hard it is to get a feature accepted.

It doesn’t have to be that way.

In 2019, I added the cross-database JSONField as part of Google Summer of Code (GSoC). Many of Django’s big features have come from GSoC, and some of the contributors stay involved in the community – this year, I became a GSoC mentor for Django. As a core team member of Wagtail (a Django-based CMS), I have seen the same pattern with our participations in such outreach programs. Django can do a lot more in making community contributions more accessible and sustainable, and I think I can help.

Here’s what I think the steering council should do:

1. Organize a living roadmap for Django. Rather than waiting for a DEP to be proposed and acted on, the steering council should actively help the community in highlighting issues and feature requests that are high priority or most wanted.
2. Maximize the potential of mentorship programs. With a roadmap in place, the steering council could help find mentors and contributors who can take on the work. Programs like GSoC, Djangonaut Space, or other initiatives can flourish if we connect the ideas with the right people.
3. Communicate and document progress. To allow continuous feedback and improvement, the steering council should engage with the community and document the progress of their activities, as well as the current state of Django.

Django is at a turning point. It’s time for the steering council to take a more active role with the community in shaping the future of Django, and I believe I can help make that happen.

My deep knowledge of Django comes as a user and documentation contributor since 2009, and from working on Django as a Django Fellow from 2014-2019.

Since 2019, I’ve been contracted to develop and maintain several third-party database backends for Django, including CockroachDB, Google Cloud Spanner, Snowflake, and MongoDB.

I remain active on the Django Internals section of the forum and the Django ticket tracker, as well as writing and reviewing patches for Django.

If elected to the Steering Council, I would strive to grow our contributor base and improve the support structures in the community. I’d like to do the work to make everyone else’s lives easier.

I expect this to move slowly, but I do expect this to move. The three most important goals to me are the following:

1. Meet as the Steering Council regularly and post a record of the discussion and actions.

2. To check in on our various teams and individuals. For example, the Translations team isn’t a formal team yet, but it should be.

3. To encourage and support feature development based on community recommendations.

I will need help with this role in understanding the context and history of technical decisions in Django. The community can support me and others like me by continuing to engage in those technical discussions on the forum. Having folks provide context and clarity will be invaluable.

If elected, I would step down from the DEFNA board and step away as a DjangoCon US organizer. That would leave me being involved with the Steering Council, Djangonaut Space, and Django Commons, all of which overlap in my goal to foster community growth.

I expect there to be technical change in the next term of the Steering Council. However, my particular focus will be on the people. By engaging the community more and encouraging new people, we can strengthen the foundation of our community to support our ambitious goals of the future.

More detailed opinions can be found at: Steering Council 6.x Thoughts · Better Simple.
A list of my involvements can be found at: Tim Schilling · Better Simple