Repository navigation
DEP 0019 - Technical governance for the Django project - #107
Conversation
This is a simplification and reduction of the technical governance. It is a merge of DEPs 10 and 12, acting as a single source of truth for governance. Add bugfix release mention. Removes a lot of the extra context around the bugfix being for a feature release. It's not referenced anywhere else and may be noise. Consolidate the steering council voting eligibility revocations. This is a really long sentence now. Added additional links for DEP process and new-features repo. Allowed revisiting vetoed discussions and features at SC discretion. Allowed DEPs during Steering Council elections Add specific rationales for the changes to the relevant section. Remove initial list of definitions in favor of links in the document. Removed the CLA reference. Remove the phrase minor consensus. Add a reporting section that documents what reporting is occurring today. Replace all references to the DSF secretary with the DSF Board. Remove the paragraph about revoking the ability to vote. Remove ability for board members to run for the steering council. Add updated version of steering council eligibility requirements. Remove voting as the steering council's decision making process. Expand the technical direction section to call out ability to use DEPs for things without using the new features repo.
| .. _Mergers Team: https://github.com/django/dsf-working-groups/blob/main/active/mergers-team.md | ||
| .. _Releasers Team: https://github.com/django/dsf-working-groups/blob/main/active/releasers-team.md | ||
| .. _Security Team: https://github.com/django/dsf-working-groups/blob/main/active/security-team.md |
There was a problem hiding this comment.
It will be - the Security Team WG doc is still being worked on.
There was a problem hiding this comment.
@RealOrangeOne I was referring to all teams mentioned here. I can see the PR to add the security team documentation is still open.
There are already mergers and releaser team documents in the repo, but they are available under a different filename. Like https://github.com/django/dsf-working-groups/blob/main/active/releasers.md
Stormheg
left a comment
There was a problem hiding this comment.
@tim-schilling this file is named final/0018-technical-governance-6x.rst, looks like an oversight or typo. This PR title and the DEP contents refer to it as DEP 19.
There was a problem hiding this comment.
I don't know a lot about Django's governance model and thus can't speak to any of the specific details in this DEP, but for what it is worth, I liked reading about how the steering council will be run.
I scanned the referenced DEP 10, and I find this new version much more accessible to read and understand. Thanks for proposing it.
shaib
left a comment
There was a problem hiding this comment.
Generally, I find this document not clear enough about changes it makes. As an example, "reducing the scope of eligible voters" -- the doc claims it "allows effectively the same number of people to participate", but it never mentions if it's just the same number or the same people, nor what were the previous qualifications.
As such, it may be a good spec, but I find it lacking as an enhancement proposal.
Further point-by-point comments inside.
| * Presenting a merged governance document avoiding overruling | ||
| governance documents (DEP 10 & 12). | ||
|
|
||
| * A single document avoids having to read two documents to | ||
| understand the governance. | ||
|
|
||
| * Reducing the number of sections and topics. | ||
|
|
||
| * DEP 10 sought to provide information on how the new governance | ||
| would operate. While helpful in that moment, it eventually | ||
| became a burden when revisiting the document. |
There was a problem hiding this comment.
These together suggest that we should differentiate between documents which are literal DEPs -- documents describing the suggested change -- and documents describing the "achieved state", a "constitution" of sorts.
DEP 12, in particular, was mostly a change document. This one appears to be more of a result document.
There was a problem hiding this comment.
Yes, exactly. This is a replacement of DEP 10 and 12 so a person wouldn't have to sort out which pieces are being overridden.
I believe you're pointing out, what do we do in the future when we need to change this again and that's a good question. Maybe we pull this into the Django code base so there's a source of truth somewhere and then allow the DEPs to be change documents for governance.
We could also host it on the djangoproject.com/foundation/ section of the website so it doesn't need to impact the codebase.
|
Can/should this mention something about the governance of the |
There was a problem hiding this comment.
Thanks for the hard work, Tim! I agree with most points, but for the sake of improvement, my comments will focus on where I disagree:
I was pondering for a while if it was my place to say something, but I am not in love with the “traits.” I think I grasp their purpose, but I think their subjectiveness weakens the steering committee and, in turn, Django's technical oversight.
Moreover, I am missing accountability. I love how all meetings and decisions are currently published. Let's make this wonderful practice a written requirement in the future.
I'd even go a step further and propose a transparency amendment, allowing every DSF member to make a freedom of information inquiry, which the committee must always respond to in a timely manner. I don't believe there is currently much use for it, but it's a remarkable tool to build trust.
Lastly, I don't believe the steering committee should be self-governing. At least not on paper. I'd prefer a fully board-appointed and dismissed committee. This way the member board vote and its inherent legitimacy would propagate unhindered to the steering committee.
@benjaoming I think the mentions of the repository are sufficient at this time. We're still iterating on what that process looks like and sorting things out there. I think this document is better directing people to that repo to understand the new features process as a whole rather than trying to capture it here (and creating a second place for it to be updated in the future). Yes, it's currently owned by the Steering Council. We've had discussions on how to expand that membership, but nothing conclusive. It's going to be a focus for the second half of the year. |
Responding briefly to this (and not sure if this idea has already been withdrawn) -- I appreciate the separation of concerns by having the DSF Board not in charge of technical matters but rather concentrated on the practicalities of running a non-profit. Obviously there is overlap (it's a nonprofit with a technological mission), but my understanding is that it's already a problem that people run for the DSF Board thinking that a history of code contributions is an important qualification for the role, when really they should be running for the steering council instead. |
Thanks, @jacobtylerwalls. Tim has addressed this comment, and it was a misunderstanding on my side. Of course the board shouldn't be responsible for the technical oversight. My understanding is now that, under normal circumstances, the steering committee is member-voted. Making my comment obsolete. As previously mentioned. I read this as a complete noob to provide a fresh set of eyes. I hope it doesn't stir up too much trouble if I'm getting things wrong here and there 🙈 |
shaib
left a comment
There was a problem hiding this comment.
This is all responses to previous comments.
Co-authored-by: Shai Berger <shai@platonix.com> Co-authored-by: Benjamin Balder Bach <benjaoming@gmail.com> Co-authored-by: Fotis Adamakis <fotis.adamakis@preply.com>
|
When folks have time, can you review the open threads and see if there are any loops that can be closed? |
LilyFirefly
left a comment
There was a problem hiding this comment.
Looks good to me! I have one question about a (hopefully!) rare edge case, but it's not a blocker for me.
| * A qualified nominee will fill the vacancy if the Steering Council | ||
| votes to appoint the nominee. As an exception to the Steering | ||
| Council voting process described above, this vote must be completed | ||
| within one-week and it must be unanimous approval. |
There was a problem hiding this comment.
What happens in the case that one member is temporarily unavailable? For example they might be in hospital for that week.
Would we defer starting the vote until they are available?
There was a problem hiding this comment.
If we were facing that situation now (4 members trying to appoint a new person and one of the four is indisposed), that's what I would suggest. Unless there was something more urgent that required us to have the new person on board. If that was the case and this was getting in the way of us being productive of urgent matters, I'd likely push for tweaking the governance to not get in the way.
Co-authored-by: Carlton Gibson <carlton@noumenal.es>
Co-authored-by: Lily <code@lilyf.org>
|
This was approved by the Steering Council. I'll merge this and then submit it to the DSF Board for them to accept as per DEP 10. If it's not accepted, we'll bring the status back to proposed and iterate on the necessary changes. |
* origin/main: Removed SC voting language from the document. Updated language for annual release cadence due to DEP 20. (django#120) Marked DEP 20's status as Accepted. (django#116) Use X in Deprecation Policy section of DEP 20 for clarity. (django#115) DEP 20 Adopt Annual Release Cycle (django#109) DEP 0019 - Technical governance for the Django project (django#107) Finalized DEP 0018 Dictionary-based MAILERS (ticket-35514) DEP 0018 Dictionary-based EMAIL_PROVIDERS (ticket-35514) (django#105) Marked DEP 0014 Background Workers as final Extended project template (django#98) Add django command (django#100) Moved DEP 0011 to superseded (django#102)
From the motivation section:
This is a revisitation of Django's technical governance in which a simplification and reduction was made to make it more approachable to more people. The goals of these changes are the following:
Related governance changes: