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 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/46c7e2a6-78be-48f9-95f9-66b891d1d5d3%40app.fastmail.com.
