Draft Steering Council DEP

[Andrew Godwin]

Hi all,

As a followup to my previous post about potential changes to the Technical Board - for which I thank you all for the feedback - I have taken the process to the next step and written a draft DEP:

https://github.com/django/deps/pull/75/files

(If you wish to see the DEP with styling, it can be viewed at https://github.com/andrewgodwin/deps/blob/steering/draft/0012-steering-council.rst)

I could just merge this into the DEPs repo as a draft given our process, but I would like to invite both review of the DEP styling and layout (to ensure it's ready to merge in that regard) as well as initial feedback on its content as well.

I have copied in the DSF Members mailing list as it is a governance-related DEP, but if we could keep all discussion on the thread in the Django Developers mailing list, as per DEP 0001, that would be great.

Thanks,

Andrew

[James Bennett]

On Wed, Oct 26, 2022 at 4:34 PM Andrew Godwin <and...@aeracode.org> wrote:

I have copied in the DSF Members mailing list as it is a governance-related DEP, but if we could keep all discussion on the thread in the Django Developers mailing list, as per DEP 0001, that would be great.

My main concern remains the thing I've been saying repeatedly in the other thread: how does this actually solve a problem that Django is facing right now?

We've established that the Technical Board was not carrying out its duties. There's also been a claim advanced that probably there is not a replacement slate of board members who would step up and have the capacity to do what DEP 10 asks.

So, either this new DEP is intended to be a slight clarification of the Technical Board's role, in which case I don't see how saying "same as before, but this time we actually expect you to do the thing" solves the issue. Or it's intended to be a first step toward a more active group, in which case I don't see how it can succeed given that a lower required level of activity has already failed.

I also have concerns with the "Steering Council" name. In Python's case it's something resembling Django's old technical board, which was made up of core devs elected by core devs (technically Python does it as "must be nominated by a core dev", not "must be a core dev", but in practice it makes little difference). I don't want to create the impression that Django's governance looks even a little bit like that, because it doesn't look like that.

[Andrew Godwin]

On Sun, Oct 30, 2022, at 10:42 PM, James Bennett wrote:

On Wed, Oct 26, 2022 at 4:34 PM Andrew Godwin <and...@aeracode.org> wrote:

I have copied in the DSF Members mailing list as it is a governance-related DEP, but if we could keep all discussion on the thread in the Django Developers mailing list, as per DEP 0001, that would be great.

My main concern remains the thing I've been saying repeatedly in the other thread: how does this actually solve a problem that Django is facing right now?

By widening the set of people who can run for the Board/Council.

We've established that the Technical Board was not carrying out its duties. There's also been a claim advanced that probably there is not a replacement slate of board members who would step up and have the capacity to do what DEP 10 asks.

So, either this new DEP is intended to be a slight clarification of the Technical Board's role, in which case I don't see how saying "same as before, but this time we actually expect you to do the thing" solves the issue. Or it's intended to be a first step toward a more active group, in which case I don't see how it can succeed given that a lower required level of activity has already failed.

It is intended to allow for a more active group by giving us a wider set of candidates who can run and thus a higher chance of people being on the Board/Council who want to be that active.

Andrew

[C. Kirby]

Having run the elections for the current technical board I agree with Andrew's assessment that a more open requirement to run is a good idea. It may create a bit more work on candidate verification for the DSF Board and Fellows, but anything that can work to encourage new blood in the "Leadership" of Django and the DSF has a +1 from me.

I don't have a strong feeling on renaming of the board, but as such don't really see it as necessary.

I take James points that DEP 10 hasn't really been followed to it's fullest. This DEP to me doesn't really have an impact on the process of DEP 10 but does open up the board to more people.

Assuming for the sake of argument that James' assertion that DEP 10 has not been followed rigorously either due to lack of the awareness of the detail of DEP 10 or the detail being ignored, I'd be of favor in adding more to this DEP to help alleviate those issues. I think there are 2 areas that could use improvement. Hopefully not to replace the meat of DEP 10, but to enhance the understanding of it.

1. There are several of timelines and triggers listed in DEP 10. A section that lays them out explicitly with references back to the details could be immensely useful. A flow chart perhaps - what are all the things that happen when the final release of a major version occurs. A list of trigger actions would be useful as well - Fewer Than 3 remaining members of the technical board - elections, Fewer than 3 mergers - select new Merger, etc. A TL;DR; for the Technical Board on the "day to day" working of the board.

2. Probably controversial - an enforcement mechanism. The DSF Board has a regulatory requirement to meet and follow the bylaws as a registered non-profit. We can be subject to lawsuit if we don't. The Technical Board has no such liability, except for the, perhaps stronger, moral liability to the community. To be clear I am not suggesting a legal enforcement mechanism, but perhaps a community one. I dearly hope that it would never be needed, but not having one at all seems an oversight. Something along the lines of:
"DEP 10 enforcement: Any DFS individual member may make a public statement of no-confidence in the technical board by identifying a material breach of DEP 10. Upon seconding by another individual member of the DSF the DSF Board SHALL no later than the next scheduled board meeting evaluate the merits of the statement of no-confidence. If the statement is found to be accurate and correct the Board shall inform the Technical Board of the breach and provide 2 weeks to rectify said breach. If the Technical Board fails to rectify the breach in the time allotted Technical Board elections SHALL be triggered and current members of the Technical Board shall be barred from running in the no-confidence election"

Chaim

[Andrew Godwin]

On Tue, Nov 1, 2022, at 6:54 AM, C. Kirby wrote:

Having run the elections for the current technical board I agree with Andrew's assessment that a more open requirement to run is a good idea. It may create a bit more work on candidate verification for the DSF Board and Fellows, but anything that can work to encourage new blood in the "Leadership" of Django and the DSF has a +1 from me.

I don't have a strong feeling on renaming of the board, but as such don't really see it as necessary.

It is not an absolute requirement from me, but I think it's a better description of what it should do and also helps us distinguish it from the "Technical Team" a bit more, so I will keep it in the DEP unless there's strong objection.

1. There are several of timelines and triggers listed in DEP 10. A section that lays them out explicitly with references back to the details could be immensely useful. A flow chart perhaps - what are all the things that happen when the final release of a major version occurs. A list of trigger actions would be useful as well - Fewer Than 3 remaining members of the technical board - elections, Fewer than 3 mergers - select new Merger, etc. A TL;DR; for the Technical Board on the "day to day" working of the board.

Agreed, and I think this is something we should do either way - if this DEP goes in, doubly so, as we want to have a single place to reference things rather than multiple DEPs.

2. Probably controversial - an enforcement mechanism. The DSF Board has a regulatory requirement to meet and follow the bylaws as a registered non-profit. We can be subject to lawsuit if we don't. The Technical Board has no such liability, except for the, perhaps stronger, moral liability to the community. To be clear I am not suggesting a legal enforcement mechanism, but perhaps a community one. I dearly hope that it would never be needed, but not having one at all seems an oversight. Something along the lines of:

"DEP 10 enforcement: Any DFS individual member may make a public statement of no-confidence in the technical board by identifying a material breach of DEP 10. Upon seconding by another individual member of the DSF the DSF Board SHALL no later than the next scheduled board meeting evaluate the merits of the statement of no-confidence. If the statement is found to be accurate and correct the Board shall inform the Technical Board of the breach and provide 2 weeks to rectify said breach. If the Technical Board fails to rectify the breach in the time allotted Technical Board elections SHALL be triggered and current members of the Technical Board shall be barred from running in the no-confidence election"

Interesting - having the DSF board moderate that makes it more agreeable to me, though if we are going to introduce this we should _also_ introduce wording for what happens if we fail to elect a Board, as this makes it much more likely (barring the entire previous board from running).

Andrew