Updating our DEP process / DEP 1

[czue]

Thanks @sarahboyce for routing me here. It was great reading through this topic and seeing that this is a situation that the Django community is both aware of and trying to address. It was also nice to see my own startapp thread being cited as an example of the problem.

My perspective is maybe different from most of yours, in that I am by no means “old guard” or a significant contributor to django (like the fellows). However, I have been involved - sometimes in a leadership role - in many other open-source projects and communities. Here I’ll mostly wear the “new contributor to Django” hat, but colored by my experience with this situation in other communities.

For me, the most frustrating part of the experience was not the disagreement, or having my suggestions shot down by some of the old guard without clear reasons (though that was frustrating). The most frustrating part—which @Lily-Foote already articulated well and which think you are trying to solve with this thread—was that there was no clear process to having the decision made.

@carltongibson has pointed out that we don’t have many disagreements. That may be true, but we still need to have a way of addressing them when they do come up. Whether that is a benevolent dictator, a steering committee, a vote, or simply “if there is a disagreement, we close the conversation and don’t change anything”, the process has to exist so that it can be clear how to get to a resolution. You all, as the people more familiar with the culture and history of Django can decide what the process should be, but it’s not fair or good for newer contributors for there to be no process.

Ironically, deciding on the process will itself likely involve a lot of disagreement—or at least many ideas—and therefore require using the process! Depending on your outlook, this could either be the perfect opportunity to dogfood something, or it could be a death-spiral into the same limbo state as these other conversations…

Of the ideas floated on this thread, the one that resonates the most to me is the one proposed by @sarahboyce where these conversations are discussed and resolved by the steering committee (if that body exists?).

Finally, I would suggest that whatever ends up getting decided be documented clearly, and shared liberally with contributors new and old. For me, I knew it was going to be more important to know how the change would get decided than than the details of the change itself, but no one could give me a straight/satisfying answer on that. I think having that clarity will make for a clearer path for people who want to improve the framework.

Thank you all for your thoughtful dialog and efforts on this! I could add a lot more thoughts about my own opinions of how one might evaluate a particular change, but I worry that would lead to bike-shedding away from the core need (not unlike what happened on the urls/startapp thread).

-Cory

[carltongibson]

@czue

or simply “if there is a disagreement, we close the conversation and don’t change anything”

My understanding was that is was “consensus for the change” that was required, so this is close to the status quo, except we didn’t say, “And no more conversation”.

Django is old, and much used, and good, so there’s a lot to be said for abiding by the previous/existing decision. (“Why Django?”)

@czue

whatever ends up getting decided be documented clearly, and shared liberally with contributors new and old.

+1. Even if nothing changes, spelling it out should help expectations.

[nanorepublica]

I was reflecting on the latest Django Chat podcast episode featuring Lily, and I was reminded of this thread.

Disclaimer: I haven’t yet delved enough into Trac or further into the Forum to see if the below exists, so please direct me if this discussion already exists!

Essentially I was wondering whether the idea of a gap analysis would be of interest to anyone?

By a gap analysis, I mean comparing the current Django implementation of features with the expectation of features as they relate to the Django product values.

A couple of examples might explain what I mean.

For a list of values, I am referring to the five items at the top of this page: Django overview | Django

• Fully loaded (or batteries included) - Again I would be looking to common third-party packages and judging whether they should be moved to the core or perhaps a meta package that installs a bunch of them? or another recent discussion on here of having a list of recommended packages.
• Reassuringly secure. - The auth system is amazing, but there is a gap compared with industry standards such as MFA and passkey being supported by default. While there are third-party packages, there have been discussions of some of them coming into the core.
• Ridiculously fast - The old deployment scenario comes to mind here. This is one of the biggest hurdles in getting to a completed application. I don’t have a solution for this one, but if this value is to be retained, then I would want to have a better answer than the ones around now.

While I wrap up, I don’t want to diminish the excellent work everyone does or increase any maintenance burden on anyone.

I hope this provides a possible lens to get some proposals unstuck from discussion stagnation and to provide another perspective for getting consensus for a feature to be accepted.
We have values (whether they match exactly what’s on the site currently is another discussion) that could be explicitly used to help decide which features should be accepted or which packages get into the core of django. I imagine this is done implicitly already by those contributing, but as has already been said, making the process more explicit is no bad thing.

A related podcast to this discussion in general: Developer Tea :: <!-- -->Good Plans, Bad Plans, and Road Trips

[czue]

@carltongibson

My understanding was that is was “consensus for the change” that was required, so this is close to the status quo, except we didn’t say, “And no more conversation”.

Right I think this is the de-facto current state, and just making that explicit would be an improvement. Wouldn’t be my favorite outcome but I get why it would end up being chosen.

@carltongibson

Django is old, and much used, and good, so there’s a lot to be said for abiding by the previous/existing decision. (“Why Django?”)

Without getting too theoretical, this reminds me of the classic tension between progressivism and conservatism in societies. You’re representing the case for conservatism (“what is old and good should remain”). But that doesn’t work without progressivism as well (“we can make things better”). I know Django does improve regularly, but if most of the decision-making is made by the old guard it might lean too far towards being conservative instead of embracing progress. This has certainly been my felt experience as a newcomer to contributing what I believe most people agree is an obvious improvement, though I may be over-generalizing on that one experience.

[carltongibson]

First time I’ve been called a conservative in a long while

@czue

…it might lean too far towards being conservative instead of embracing progress.

Absolutely. But, where we maybe/likely differ, is that I think we’re a long way from there: we’re constantly pushing forwards. (Mentally compiles a list of absolutely blinding changes since, say, Django 2.x timeframe… )

I hear frustrations being sounded. I get that. Heavens, I’ve felt those myself (on numerous occasions).
Folks want to do new things? Do new things! Be my guest. I’m all with you. Really! I’m out there trying to do the same. (I’ve said how many times how excited I am about where Django is and where it’s going!)

But don’t (trying to paraphrase the long-standing arguments, that were there long before I was involved):

• Affect the stability of existing features in Django.
• Bring more into core than we (really) have the ability to maintain.
• Experiment with new APIs that are not settled inside Django itself.

Pretty much all of these are addressed by doing things in third party packages. Where it’s not — async being the best recent example — experimental APIs — exceptions are made.

Aside about the specific recent proposals

FWIW I think the objections to the `startproject`/`startapp` templates are about the first point.

startproject is more complex, because there are various factors in play, from simplicity, to settings, to production readiness, that come together, and need handling as a group; I think that does need a plan.

Ref the startapp proposal, I’m sorry you’ve been frustrated; the other view there is that it’s a nothing change, requiring updates to tutorials and who knows what else for no real benefit, the evil “churn”. In this case, given the lack of consensus for the change (the criterion in play) I’d say stability wins, so go with no.

[czue]

Responding to the aside in another aside.

Aside on templates

@carltongibson

startproject is more complex, because there are various factors in play, from simplicity, to settings, to production readiness, that come together, and need handling as a group; I think that does need a plan.

This makes sense to me. I’d also be happy to contribute to that discussion if it’s happening somewhere. I believe you told me once this was the one area of Django where I might have valid opinions.

@carltongibson

Ref the startapp proposal, I’m sorry you’ve been frustrated; the other view there is that it’s a nothing change, requiring updates to tutorials and who knows what else for no real benefit, the evil “churn”. In this case, given the lack of consensus for the change (the criterion in play) I’d say stability wins, so go with no.

“We agree it’s net positive but the extra work created doesn’t justify the small gain” is the first coherent argument I’ve heard against the change so thank you for finally articulating this position! If someone had said that on the original thread I think it would have led to a much more productive dialog. E.g., we could debate the cost/benefit of the work involved instead of the change itself.

My guess is that many changes get rejected for similar reasons that are invisible to the contributors making them, so it’s a useful category of rejection to make clear to potential contributors.

[carltongibson]

@czue

the one area

“One”, not “the one”

[sarahboyce]

Personally, I have no critiscm or concerns around the decisions past or present in terms of outcomes to Django as a framework. I even think “Django is old and boring” is a marketing issue and I’d prefer us to start saying something more like “Django is established and progressing”. Django is in a good place. I see the consistent work that happens on the framework and I’m excited about it.

But… as many have said, this process has had negative outcomes in terms of the contributor experience. I know we need to think about it some more but I’d say this requires us to do something. Otherwise, we imply we don’t care (not true) or don’t know how to change things (sometimes true).

None of this has been that we don’t appreciate person X from expressing why they are against a proposal, or that we should say yes to everything. I don’t think anyone is expressing fustration or that they are upset just becuase they didn’t get their own way.

It’s mostly the drawn-out-ness and lack of closure that I see people struggle with. That added with a lack of process clarity or an understanding of Django’s values when it comes to making a decision.

I have just repeated things already said (sorry about that). But when I noticed Cory expressing frustration with his experience, I wanted us to remind ourselves that this process design still actively produces a negative contributor experience.

Aside about a gap analysis

I really like the thinking here @nanorepublica.

Google summer of code is the closest thing to a roadmap I am aware of: SummerOfCode2023 – Django (djangoproject.com). It isn’t a roadmap, but it’s a list of larger projects that we actively seek and read proposals for and are therefore likely to be done “some day”.

As a side note, a roadmap also opens up other opportunities also around sponsorship. I know Wagtail allow donations to help dictate a roadmap priority: Roadmap | Wagtail CMS. I also hear a lot of people being very curious as to what is on the roadmap for Django. So defining something could have a lot of benefits IMO.

[thibaudcolas]

Thinking of practical ways forward, how about we experiment a bit, and see what sticks? There’s two things in particular I’d love to try to organize if people are up for it:

““Roadmap”” workshop

This would involve brainstorming and voting on ideas for things to happen in the Django universe (core, community, packages). Similar in some ways to Django feature vote spreadsheets of the past, but more community-driven / non-binding, in the spirit of Jeff Triplett’s DjangoCon US Talks I’d Like to See.

I think this would help contributors have a sense of where other people’s interests are in broad strokes. If time allows we could even go beyond the voting; classify the ideas on an impact/effort matrix, discuss timeframes and ways to take things forward (“is this a good GSoC project”, “does this need a DEP”, “should we look for another MOSS-style grant”, etc). Perhaps even discuss risks / gaps (shifting expectations on static typing, deployment, bus factor on a specific module, etc).

Who knows, we might even identify some quick wins for new contributors like Djangonaut Space to take through!

““Sprint”” retrospective

Agile-style, we’d record our different pain points on working together as contributors, and also note things that work well. Spot any commonalities. Have people vote on the ones they relate to the most / think are the most common / worth discussing further.

Then we’d devise solutions on the spot. Or re-assess suggestions like the ones from Jacob at the start of this thread based on how likely they are to help with common pain points.

---

In essence, I’d really recommend an action-oriented attitude here. We can find meaningful improvements without having to figure out the best process ever!

[thibaudcolas]

Happy new year all Just wanted to follow up on the above – I’d like to proceed with those informal “roadmap” and “retrospective” exercises. If you’re interested in participating in either, I’ve branched out to a separate thread so as not to side-track discussion of the DEP process further: Informal roadmap & retrospective workshops for Django.

---

On the DEP process, if you want to help, I think we could use more “looks good” comments (or objections) on Feature request: allow writing a DEP in Markdown as well as rST #85.

[sarahboyce]

Want to link this: Proposal: Rename `runserver` command to `devserver` and add a `prodserver` management command - #16 by nanorepublica

Just so we stay aware that this discussion/challenge is still active