DEP 19 Is Approved. Quorum Still Counts Ghosts

Django’s homepage still leads with two governance notes. DEP 19 is approved. The voting-membership bylaw is not. Comments close October 7. The Board meets October 8. Download button on the same page: Django 6.1.1. Today’s other calendar item is Django Day Copenhagen. The release is not the news. The roll is.

We already wrote that Django’s survey was fine with the boring monolith. This week is the foundation that ships that monolith. Technical governance got simpler on paper. Quorum still counts members who have not voted in years.

DEP 19 is a smaller door, on purpose

Tim Schilling, writing with the Steering Council on September 22, says both the Council and the DSF Board approved DEP 19. Two Boards’ worth of people and “dozens of community members” went into it. The pitch is not a new architecture. It is a revisitation: simplify and reduce Django’s technical governance so more people can approach it.

The change Schilling flags as the one he cares about is Steering Council eligibility. They wrote a wider set of qualities that could make someone useful on the Council, hoping people who already do the work will recognize themselves and stand for election. That sentence only matters if the next election actually sees new names. A broader rubric that produces the same five people is a PDF.

Next steps, still from the post: update the docs in the Django and djangoproject.com repositories, then move the DEP to its final state and folder. Approved is not deployed. If you are waiting for the governance page to match the weblog, that is the remaining ticket. Do not cite DEP 19 as if the HTML already changed.

For a web team this is not trivia. The people who can land a release blocker, who can say no to a feature that would break your upgrade, sit in this structure. A Council that only looks open to a certain kind of résumé is how you get a project that surveys as a monolith and still feels like a closed room. Schilling is trying to make the room look enterable. The docs update is the part that will either prove it or file it.

The bylaw is about quorum math, not exile

Jeff Triplett and the DSF Board, September 18: if you voted in a Board election in the last two years, you are active and you count toward quorum. If you have not, you remain a member, you stay on the website, and you do not count toward quorum until you say you want to vote.

The problem they name is standard nonprofit arithmetic. Quorum today is measured against everyone on the rolls, including people who no longer vote. As membership grows, the denominator grows, and valid elections get harder. They call counting the entire roll the outlier. The Python Software Foundation’s analogue is in the post: voting members affirm they intend to vote, and in June 2024 the PSF board waived that affirmation for anyone who voted in the previous board election.

The defensive paragraph is doing necessary work. No one loses membership. Active status is a quorum flag. They say they will send reminders before elections and post on the blog and the forum so people are not dropped from the count because they missed one email. If you want to vote, you contact them before the election opens and they add you to the roll.

The artifacts are public. Bylaw pull request #13. Forum thread. They already talked it through at DjangoCon US. Comments until October 7, 2026, on the PR or, for members, on the members-only thread. If nothing major blows up, the Board votes October 8.

That is this week’s actual deadline. DEP 19 is done. The membership flag is not. If you are a DSF member who last voted in 2022, you are the ghost in the current quorum. The proposal is to stop pretending you will show up unless you say so.

Why a web framework post is a bylaws post

People who ship Django apps skip foundation posts until a security release. Fair. Then a vote fails quorum, or a Council slate looks like a closed shop, and the skip gets expensive.

Starlette’s BadHost landing on CISA KEV was a reminder that the people who maintain the stack you import are a finite set of humans with a finite process. Django’s process is about to change twice: once in technical governance, once in who counts when the Board is elected. FastAPI fans who watched Python Workers go GA without bringing Uvicorn already know the runtime is not the whole product. The foundation is part of the product.

If you depend on Django 6.1.1 in production, you depend on a Board that can hire, fund, and not stall. The Executive Director search was already a 2026 plotline on the same weblog. Quorum that cannot be reached is how that plotline dies in a meeting that does not officially happen.

The PSF comparison is the strongest argument in the post because it is not theoretical. Python’s voting-member affirmation exists because huge open-source membership lists rot. Django is smaller and is already hitting the same math. Waiting until a Board election is invalid is the worse time to invent the flag.

What to do before October 7

If you are a DSF member, read the PR. The comment window is the product. “I didn’t see it” is the failure mode they are trying to engineer around, and also the failure mode of this proposal if people treat October 7 as decoration. Three places: the GitHub diff, the public forum context, the members-only thread if you have it.

Say something specific. “What happens if someone voted in 2024, sat out 2026, and wants in for 2028” is a better comment than a vibe. “Reminders” need a channel you actually read. If the only reminder is the weblog, a lot of members will still miss it. Ask where the email list lives and whether the forum banner is enough.

If you are not a member and you run a Django shop, this is still your week to decide whether anyone at the company is a member who votes. A lot of teams consume the framework as if it were a cloud service with no customers-who-govern. It is not. Membership is how the quorum denominator gets honest, or how it stays a ghost roll.

If you think the two-year lookback is too short or too long, that is a comment, not a screenshot. Two years is “the last Board election cycle,” not a loyalty test. Shorter lookbacks make the active set tiny. Longer ones keep ghosts. The PSF waiver for recent voters is the template. Argue with the template if you have a better one.

Do not confuse this with DEP 19. Eligibility to stand for Steering Council is a technical-governance problem. Eligibility to count toward Board quorum is a corporate-form problem. Both are about who is in the room. They are not the same room.

Docs lag is a web-dev problem you already know. DEP 19 is approved in a weblog post and not yet the page a new contributor will read. Until the Django and djangoproject.com repos actually change, onboarding still describes the old room. If you maintain an internal “how we work with upstream” doc, wait for the HTML, then update your pointer. Linking the weblog as if it were the policy is how teams argue from a press release.

The same lag will hit the bylaws. A Board vote on October 8 does not rewrite the membership page on October 8. Someone has to merge PR 13, regenerate the site, and send the reminder they promised. Ask who owns that ticket. If the answer is “the Board,” you already know the ticket will slip. Pick a name.

Ken Whitesell’s member-of-the-month post is the human version of the eligibility change. A longtime forum helper is exactly the person a wider Council rubric is supposed to notice. Whether he, or people like him, ever stand is the metric for DEP 19. A month profile is not a candidacy. It is a hint about who the project already relies on without putting them on the ballot.

Copenhagen is today. The vote is next week.

Django Day Copenhagen is on the events list for October 2. Django On the Med was September 23 in Pescara. DjangoCon Europe 2027 is already on the calendar for Innsbruck in February. Ken Whitesell is DSF member of the month, a forum helper since 2017, posted September 24. The social layer is not paused for bylaws. That is normal and it is how people miss the PR.

If you are at Copenhagen, the useful hallway question is not “did you like 6.1.1.” It is “did you comment on pull 13.” A conference that produces three talks about async ORM and zero comments on quorum has recreated the problem the Board is describing: lots of names on a roll, not enough people in the meeting.

For everyone not in Denmark: 6.1.1 remains the current download. Upgrade on your own schedule. Put October 7 on the same calendar as the release you actually care about. The governance page will lag the weblog until someone merges the docs. The bylaw will lag until October 8, and only if the comments stay quiet enough.

A web framework is code, a security process, and a membership list that can still hold a vote. DEP 19 tried to make the technical side look enterable. The DSF proposal tries to stop counting people who left the building. One is approved. One is a week of comments. The ghost roll does not fix itself because the homepage still puts the notes in the same column.

If you write Django for a living and you have never opened dsf-bylaws, this is the week it is short. PR 13 is not a code review of the ORM. It is a review of whether the next Board election can be declared valid without pretending the 2019 donors still vote. The FastAPI crowd does not have an equivalent public clock on the same homepage. Django does. Use it.

October 7 is a Tuesday. Put the comment in before the workday ends in your timezone, not at 23:59 UTC when the Board has already queued the October 8 agenda. Late comments are how “no major objections” gets written by default.