DEP 0019 - Technical governance for the Django project

[tim-schilling]

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:

• Make it easier to enact our governance.
• Make it easier for others to understand our governance.
• Make the governance more flexible, allowing more action with less procedure.

---

Related governance changes:

• Add draft of security team charter. dsf-working-groups#56
• Added Mergers team charter. dsf-working-groups#71
• Added Releasers team charter. dsf-working-groups#72
• Add Triage and Review team charter. dsf-working-groups#79

[Stormheg]

@tim-schilling is this right? The links 404

[RealOrangeOne]

It will be - the Security Team WG doc is still being worked on.

[Stormheg]

@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]

@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.

[Stormheg]

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]

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.

[shaib]

I find this unclear, or maybe just too abstract.

[tim-schilling]

Let me provide some context and see if we can arrive at a better way to phrase this. If a person has been building python apps for a while, but not always Django applications, they likely have a decent amount of knowledge of Django applications. If that person also has a group of people they can rely on for questions about Django or how to build things, that means their accessible knowledge about Django is more than what they know themselves. They would be able to survey their network to ask for opinions or understand a different concept more readily.

We wanted to capture that distinction because many people will just think about what do they themselves know rather than, who is in my direct circle that I could talk to to understand this? That latter has a lot of benefit at the Steering Council level because the surface area is so large.

Let me know where there's confusion and/or how we can reduce that concept into a short sentence.

Maybe:

Has a network of Django practitioners and builders they can consult to access perspectives and expertise beyond their own

[shaib]

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.

[carltongibson]

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)

[shaib]

This is a laudable position -- a model to follow, even -- but I think the wording that hides it behind the missing "else" of "if there's agreement" is suboptimal.

Suggested change

	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.
	When asked to make a technical decision, the Steering Council should
	first discuss this amongst themselves. It is up to each Steering Council
	to decide how to resolve disagreements. When there's a decision 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.

One thing to consider around this is transparency -- the legislated voting system did, to a degree, give us that. When I go voting for the next SC, and some existing members are running again, I want to have some info about how they functioned within the SC. On the other hand, there is value in keeping internal discussions private -- that usually makes it easier for people to both express opinions and change them. I don't have a concrete suggestion how to solve this tension, but I thought it worth bringing it up.

[carltongibson]

One thing to consider around this is transparency ...

Sure, and transparency is important, and something we've tried to promote via publishing our regular meeting notes, actively engaging on topics that come up in the Forum and new-features repo, and publishing the more occasional Update™.

That goal is hopefully addressed by the Steering Council reports section of this document. (To which clarifications are of course welcome.)

A separate thing is whether SC deliberations (rather than decisions) should be public, and/or constrained to a specific format. On both of those, I'd lean to a hard no (for the reasons given).

How do we judge an SC's performance? Well, what got done during their term? Did they achieve what they set out to? Did they do what they said they would? Or at least try?

One big change is that ≈ DEP 10 conceived of the SC as ≈ only there for tie-breaks, whereas it became evident that the SC needs to play a more active role than that. In which case, I think (both) that if an individual SC member is sat doing nothing, that would be pretty evident in a community like ours, and that public formal votes wouldn't help that. (Indeed, the latter would likely give an appearance of activity where none really exists.)

Or, my thoughts are along those kind of lines. It's not the How decisions are made bit that's the key locus there. 🤷‍♂️

(No problem with the suggested edit here!)

[shaib]

| It's not the How decisions are made bit that's the key locus there. 🤷‍♂️

Well, the title of this section is "Decision making process of the Steering Council"...

| How do we judge an SC's performance? ...

That's not my question, though. I expect Steering Council members to have personal agendas, sometimes-strong opinions about the directions the project should evolve in, and I don't really expect those to be fully expressed in their public declarations (they might express them on the forum and in PR reviews, but it's very easy to miss such posts). Say I like "enterprise" features, and a specific SC member keeps convincing others to approve such features -- will I know to vote for them next time?

If the existing posts had, for every decision taken, a "Initial positions / arguments / final positions" summary, that would probably give all the info I want, but I'm well aware of the load this would put on whoever is doing the current meeting notes (and maybe even on the discussions themselves), so I don't think requiring that is a good idea.

As I said, I don't have concrete suggestions to make this better. There seems to be a trade-off here, and as such, the point selected along it is fine. I just wanted the point discussed in case someone does come up with an improvement.

[tim-schilling]

@shaib While you didn't ask this directly, when considering folks for re-election, you can look at what the team has accomplished, then dig into those to see how those accomplishments came together.

And for what it's worth, this SC has commented on various topics with their views before the team makes a decision. Though that doesn't make it easy to find when the next election cycle comes up.

[shaib]

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.

[tim-schilling]

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.

[shaib]

Are all possible abuses code-of-conduct violations?

[tim-schilling]

I think for what we would see in the case of passing DEPs during an election that the community at large doesn't want, yes. That combined with the oversight from the board for governance changes makes this safe enough from our perspective.

[shaib]

I find the "oversight of board" part convincing that the change is for the better. I find references to the Code of Conduct in this context counter-productive and even dangerous, because, IMO, they widen the scope of code-of-conduct enormously.

If a Steering Committee approves a DEP during elections because they think it is popular amond DSF members, although they believe it will hurt the project -- "election bribe" -- that is a bad move, but not a CoC violation. Even if a controversial DEP gets approved because it serves the interests of Council members who think they will be replaced, that is IMO still not a CoC issue (and the CoC Committee, last I checked, has authority to suspend people, but not to overrule DEP approvals).

In short -- I'd much rather that lack-of-integrity not be seen, in and of itself, as a CoC issue.

[tim-schilling]

I understand the concern around wanting to limit the impact of a wanton, ill-intentioned Steering Council. However, let's keep in mind our community is fairly small and they are elected. I think we should strive for governance that helps community members be effective and assume members act with positive intentions until we find otherwise.

There are four safeguards (I missed two from before):

• The election process itself
• The DSF Board takes action on their own
• A CoC violation (effectively our outside arbitration)
• Vote of no-confidence by a community member

[benjaoming]

Can/should this mention something about the governance of the new-features repo itself? The repo has a whole process that someone should own/develop? Is that the Steering Council?

[codingjoe]

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.

[codingjoe]

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.

[tim-schilling]

The “should not” phrase is relatively vague. My understanding is that most decisions are not self- but community-initiated.

The subsequent sentences in this paragraph outline specific actions the Steering Council can take to help encourage and support community driven ideas. I feel like that should help dispel the vagueness for a reader.

it may be a fairly good practice to separate those two powers.

Can you clarify which two powers you're referring to here please?

[codingjoe]

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.

[tim-schilling]

@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.

[codingjoe]

@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.

[tim-schilling]

... 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.

Do you have a suggestion on how to reword this? I'm not sure how to define a requirement as inclusive. By its definition it is gatekeeping.

[codingjoe]

They are everywhere else referred to as working groups. Sticking to one term might simplify comprehension of DSF governance.

[tim-schilling]

I recognize that's an oddity, but it seems small and reasonable to deal with for the time being.

[codingjoe]

The CoC currently has a working group, which otherwise isn't mentioned here. Which might be important if they can dismiss a member.

[tim-schilling]

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

[tim-schilling]

Can/should this mention something about the governance of the new-features repo itself? The repo has a whole process that someone should own/develop? Is that the Steering Council?

@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.

[benjaoming]

Suggested change

	The `Security Team`_ has the following powers:
	The `Security Team`_ ensures that security-related changes are addressed with the appropriate imminence and priority by Mergers and Releasers. The Team's role is:

okay I know it's a nit, but it's to avoid the word "power" and add a bit more verbosity.

See @tim-schilling's comment below.

[jacobtylerwalls]

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.

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.

[codingjoe]

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.

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]

This is all responses to previous comments.

[shaib]

This is a laudable position -- a model to follow, even -- but I think the wording that hides it behind the missing "else" of "if there's agreement" is suboptimal.

Suggested change

	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.
	When asked to make a technical decision, the Steering Council should
	first discuss this amongst themselves. It is up to each Steering Council
	to decide how to resolve disagreements. When there's a decision 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.

One thing to consider around this is transparency -- the legislated voting system did, to a degree, give us that. When I go voting for the next SC, and some existing members are running again, I want to have some info about how they functioned within the SC. On the other hand, there is value in keeping internal discussions private -- that usually makes it easier for people to both express opinions and change them. I don't have a concrete suggestion how to solve this tension, but I thought it worth bringing it up.

[shaib]

My point is that there is no special relationship between these two groups.
I think the section is redundant -- The "Interaction with other teams" section below covers the Security Team as well.