DEP 0019 - Technical governance for the Django project#107
DEP 0019 - Technical governance for the Django project#107tim-schilling wants to merge 1 commit intodjango:mainfrom
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
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.
|
|
||
| * Be a DSF Individual member. | ||
|
|
||
| * Shared any of their corporate affiliations. |
|
|
||
| .. _DEP 44: https://github.com/django/deps/blob/main/accepted/0044-clarify-release-process.rst | ||
| .. _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 |
There was a problem hiding this comment.
| .. _Releasers Team: https://github.com/django/dsf-working-groups/blob/main/active/releasers-team.md | |
| .. _Releasers Team: https://github.com/django/dsf-working-groups/blob/main/active/releasers.md |
shaib
left a comment
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.
| If discussion of a Minor Change has failed to produce consensus, a | ||
| member may ask the Steering Council to make a decision. |
There was a problem hiding this comment.
"a member" of what? or should this be "a paticipant in the discussion" or "anyone"?
There was a problem hiding this comment.
Yes, that's how I interpret this. Any community member can call for help unsticking a lack of consensus.
| If discussion of a Minor Change has failed to produce consensus, a | ||
| member may ask the Steering Council to make a decision. | ||
|
|
||
| Rejected discussions and features are eligible to be revisited at the |
There was a problem hiding this comment.
| Rejected discussions and features are eligible to be revisited at the | |
| Rejected suggestions and features are eligible to be revisited at the |
|
|
||
| Below are several traits a Django contributor may possess that are beneficial | ||
| when on the Steering Council. An individual is unlikely to possess all of | ||
| them, but qualified candidates should have more than one. Each trait is |
There was a problem hiding this comment.
"more than one" or "three or more" (above)?
There was a problem hiding this comment.
| them, but qualified candidates should have more than one. Each trait is | |
| them, but qualified candidates should have three or more. Each trait is |
|
|
||
| * Experience building and maintaining production Django apps over years | ||
|
|
||
| * Has a network of people who maintain and build Django applications |
There was a problem hiding this comment.
I find this unclear, or maybe just too abstract.
|
|
||
| * Familiar with several areas of the Django codebase | ||
|
|
||
| * Has helped maintain Django or another well-used project for years |
There was a problem hiding this comment.
| * Has helped maintain Django or another well-used project for years | |
| * Has helped maintain Django or a well-used project in the Django ecosystem for years |
| When asked to make a technical decision, the Steering Council should | ||
| first discuss this amongst themselves. If there's agreement on a course | ||
| of action, a single member will respond on the `Django Forum`_, ticket, or | ||
| `new-features GitHub repository`_ on behalf of the Steering Council. It | ||
| may optionally include a dissenting opinion if someone wishes to include one. |
There was a problem hiding this comment.
This paragraph defines how to handle and publish decisions of the Steering Council, but not how to make them. It essentially assumes rough consensus (within the council) on any issue.
There was a problem hiding this comment.
but not how to make them
Yes, this is deliberate. The specification of the voting mechanism is DEP 10 was as good a demonstration as we could hope for of why specifying such a thing (especially for a small organisation like ourselves) is too heavy an approach.
For me (personally) rough consensus is exactly what we should be aiming for. A loose show of hands is one thing, but (for me) a formal vote marks a failure. (That we resorted to something so crude, even between just the five of us, is a lack of… something… I would argue.)
But equally, other SCs in the future can make their own decisions. Simple majority, super majority, unanimous, are all reasonable options to follow: it very much should be up to each SC to decide how they want to proceed.
The point with a dissenting opinon is exactly to give voice in any circumstance where (effectively) unanimous didn't carry the day.
In reality, despite often starting a discussion from quite different positions, we've not had a case where this has been necessary. Legislating for it (too heavily) is precisely what we're aiming to avoid with this new document.
(We can clarify here, if needed, sure)
| * 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.
| as the system working. If at any point, the trust in this system | ||
| is abused, the community can rely on reporting members for | ||
| violations of Django's Code of Conduct. |
There was a problem hiding this comment.
Are all possible abuses code-of-conduct violations?
| * This simplifies some of the governance by reducing exception cases. | ||
| Plus, these roles are meant to be time-intensive and it's unlikely | ||
| for someone to do both well. |
There was a problem hiding this comment.
Anywhere in DEP 10 where it had to mention something about a person being both a board member and steering council member. For example, the exception case that we missed, but you caught elsewhere in the document: #107 (comment)
| * This accurately reflects the process the 6.X Steering Council has | ||
| been using. Future Steering Councils may internally decide to use | ||
| voting, however it is not a necessary process. The discussion and | ||
| deliberation is a more accurate representation of how the Django | ||
| community arrives at consensus. |
There was a problem hiding this comment.
But this is not about how the Django Community makes decisions, it's about the Steering Council specifically; and at least in some cases, the Council's role is to decide when a decision needs to be made and consensus cannot be achieved.
I think that whenever a decision is made without consensus, it is preferable to have transparency (of course, consensus is inherently transparent).
|
|
||
| * Have three or more Steering Council Qualities. | ||
|
|
||
| * Not be a members of the `DSF Board`_. |
There was a problem hiding this comment.
| * Not be a members of the `DSF Board`_. | |
| * Not be a member of the `DSF Board`_. |
| * To request a Merger merge code to fix a security issue being | ||
| handled under Django's security process. |
There was a problem hiding this comment.
| * To request a Merger merge code to fix a security issue being | |
| handled under Django's security process. | |
| * To request a Merger merges code to fix a security issue being | |
| handled under Django's security process. |
I'm a bit unsure why requesting a merge is considered a "power"? Anyone can request something? The power would be to approve, merge or demand?
There was a problem hiding this comment.
I hear you. I can see why it can feel off.
The security team doesn't have the actual permission to merge or release code. They need the mergers or releasers to do that. Using the language of request rather than demand is a bit more open to allowing leeway in how things go.
If we're running into a situation where teams are nitpicking the language here saying, "you can only request!!!" we're running into major problems. I think it's fair to assume people in our community are going to be collaborative. If people are wielding specific language to shield their behavior repeatedly, that's a CoC concern.
| * To request a Releaser issue a release of Django containing code to | ||
| fix a security issue being handled under Django's security | ||
| process. |
There was a problem hiding this comment.
| * To request a Releaser issue a release of Django containing code to | |
| fix a security issue being handled under Django's security | |
| process. | |
| * To request a Releaser issues a release of Django containing code to | |
| fix a security issue being handled under Django's security | |
| process. |
Same question for this point, what does "request" really entail here?
|
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.
|
|
||
| (All DEPs must include this exact copyright statement.) | ||
|
|
||
| .. _DEP 44: https://github.com/django/deps/blob/main/accepted/0044-clarify-release-process.rst |
There was a problem hiding this comment.
| .. _DEP 44: https://github.com/django/deps/blob/main/accepted/0044-clarify-release-process.rst | |
| .. _DEP 44: https://github.com/django/deps/blob/main/final/0044-clarify-release-process.rst |
| Django projects at a fundamental level, and to help shepherd the | ||
| project's future direction. | ||
|
|
||
| While the Council should not define this direction entirely by itself, |
There was a problem hiding this comment.
The “should not” phrase is relatively vague. My understanding is that most decisions are not self- but community-initiated.
IMHO, it may be a fairly good practice to separate those two powers.
| Steering Council role | ||
| --------------------- | ||
|
|
||
| The Steering Council provides oversight of Django's development and |
There was a problem hiding this comment.
A few lines above the release processes defined by DEP0044. If this isn't a conflict, which I presume, it might need clarification.
There was a problem hiding this comment.
Can you elaborate on the confusion please?
| The Steering Council provides oversight of Django's development and | ||
| release process, assists in setting the direction of feature | ||
| development and releases, selects Mergers and Releasers, and has a | ||
| tie-breaking vote when other decision-making processes fail. |
There was a problem hiding this comment.
Hm… is that power limited to technical decisions? It seems odd that the steering committee would have the deciding vote on governance. I'd presume this power would be with the elected board.
There was a problem hiding this comment.
Please review my other comments. I think this one may be resolved since the SC is also elected.
| * To make a binding decision regarding any question of a technical | ||
| change to Django. | ||
|
|
||
| * To manage the Steering Council's membership via an election with the |
There was a problem hiding this comment.
In practice it might not make a big difference, but it's always good if a body with this much power doesn't self-elect members. If the governing body is appointed by the board, which is elected, you end up with a stronger legitimacy.
There was a problem hiding this comment.
To be clear, manage is referring to removing members or adding up to 2 replacement members if others step down. The Steering Council as a whole is elected by the DSF individual members, facilitated by the DSF board.
| Steering Council's goals | ||
| ++++++++++++++++++++++++ | ||
|
|
||
| The Council's goal is twofold - to safeguard big decisions that affect |
There was a problem hiding this comment.
emdash 🤖
| The Council's goal is twofold - to safeguard big decisions that affect | |
| The Council's goal is twofold — to safeguard big decisions that affect |
There was a problem hiding this comment.
FYI, this language is taken directly from DEP 12.
|
|
||
| * Be a DSF Individual member. | ||
|
|
||
| * Shared any of their corporate affiliations. |
|
|
||
| * Shared any of their corporate affiliations. | ||
|
|
||
| * Have three or more Steering Council Qualities. |
There was a problem hiding this comment.
That seems highly subjective. As much as I believe agreeing on a common set of values is helpful, they make for weak selection criteria, which in turn takes legitimacy from the selection process and opens it to subjective criticism.
There was a problem hiding this comment.
@codingjoe I feel like you may have a misunderstanding on how the process works based on a few of your comments. I'm going to explain a bit more in this comment, but I apologize if I'm over explaining. The Steering Council is elected by the DSF individual members. The candidates who are able to stand for election are limited by these traits which will be evaluated by the DSF board. People are able to vote for whoever they want.
Over the last few years, we've made consistent efforts to broaden the candidates for the Steering Council. By expressing traits, we're hoping people identify with several of them and realize that they are qualified to self-nominate themselves. The goal here is to be more accessible to candidates who haven't seem themselves as eligible in the past.
There was a problem hiding this comment.
@tim-schilling no worries, I wrote my comments as a complete newcomer to the DSF governance. So you can't overexplain anything :) My aim was to provide a fresh set of eyes and I appreciate your long explanation.
Back to the topic: I see, that's a great effort. But seeing how I was looking at this from the outside in and confused it, maybe this can be phrased under the pretense of inclusion. This particular sentence makes it seem more exclusive to me. Not a native speaker though.
| `new-features GitHub repository`_ | ||
|
|
||
|
|
||
| Teams |
There was a problem hiding this comment.
They are everywhere else referred to as working groups. Sticking to one term might simplify comprehension of DSF governance.
There was a problem hiding this comment.
I recognize that's an oddity, but it seems small and reasonable to deal with for the time being.
| A member of the Steering Council can be removed in the following | ||
| ways: | ||
|
|
||
| * They become ineligible due to actions of the Code of Conduct |
There was a problem hiding this comment.
The CoC currently has a working group, which otherwise isn't mentioned here. Which might be important if they can dismiss a member.
There was a problem hiding this comment.
committee == working group in this sense. We can revise the language to be consistent. Suggestion here: https://github.com/django/deps/pull/107/files#r3110813593
@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. |
| ways: | ||
|
|
||
| * They become ineligible due to actions of the Code of Conduct | ||
| committee of the DSF. If this occurs, the affected person |
There was a problem hiding this comment.
| committee of the DSF. If this occurs, the affected person | |
| Working Group of the DSF. If this occurs, the affected person |
10 participants
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: