I agree the Technical Board has not followed the letter of DEP 10, and I think the things you have highlighted are all valid failings, but I want to focus on - what should we do to remedy them?
Given the lack of candidates we already have, if we ditch the current Board and try to elect a new one that has to do all these things, it's likely we will fail to have a valid election, and from what I recall, there is no provision for that in DEP 10. We could consider changing to a board size of three to overcome this, but that would increase the workload even further. We could hope that five incredibly willing people are waiting in the wings, but I doubt it. At this point, it is my view that it is our job to govern with the people we have, and the time and energy they can provide, and that's my intention with these suggested changes. I honestly think you and I both want the Board to do the same rough role - my current draft "extension DEP" on top of DEP 10 is literally just "change the name and tweak the eligibility clauses", it's not like we're going to throw it out. I just want to come at this a bit more incrementally with our current set of people, and throw the net a bit wider so we do have more of a chance of finding five people with the energy to run the tasks assigned to the Board with the vision we initially had. At the end of the day, my feeling is that inaction is not the right path - we need to enact some sort of change. I'm more than willing to hear alternative suggestions for what that change should be (though as outlined previously, I really don't think that change should be "remove the entire current Board for underperformance and have another election"). Andrew On Wed, Oct 26, 2022, at 12:23 PM, James Bennett wrote: > I'm going to avoid trying to get too much into point-by-point back-and-forth > argument here, and try to present the larger picture. > > The Technical Board has multiple active responsibilities under DEP 10. Let's > look at some of them: > > 1. Canvas for feature proposals once per feature release of Django. This also > comes with a responsibility to ensure the proposals are archived in a useful > way -- we used to have wiki pages in Trac for this, but DEP 10 doesn't > require any specific mechanism. This is supposed to happen within one week > after feature freeze of each feature release. > > 2. Set the release schedule for each feature release of Django. This is > supposed to happen within one week after the prior feature release coming out. > > 3. Maintain the teams of Mergers and Releasers, including by nominating and > confirming new members of those teams when the Technical Board considers it > necessary (or when the current roster falls below the DEP 10 quorum). > > 4. Vote, as requested, on DEPs. > > 5. Vote, as requested, on any technical decision that fails to resolve > through normal public discussion. > > (1) has not been happening. It's possible that (2) has been happening and > just hasn't been that formally published, but I suspect it's been the Fellows > who've been doing that one. For 3-5, things have gone... not so great. > > It took multiple attempts to get the Technical Board to vote on the first > Merger nomination (Claude), and if we're being pedantic it still wasn't quite > done correctly because his appointment as a Merger should have been temporary > and auto-expired after the first Technical Board election unless the new > Board voted to confirm him permanently. > > The first time the Technical Board voted on a DEP was the proposed DEP 484 > for type hints. The Technical Board's discussion and voting on it apparently > took place entirely in private and the result was communicated publicly via > Carlton copy/pasting the reply he got from them. And we lucked out that the > Board didn't accept the DEP, because it was at a time when an election was > pending and thus they had no power to accept a DEP (similar to the Merger > nomination -- once an election triggers, the Board cannot accept DEPs and can > only make temporary appointments of Mergers/Releasers). > > On (5) the only explicit request I can find in this mailing list's archive is > one from Carlton to make a decision on ticket 31747. Although several > Technical Board members posted opinions in response, I'm not finding any > statements of their votes on the matter. > > If grant a half point for the Merger nomination (though the Board really > ought to hold a public vote to properly permanently confirm Claude), and > maybe another half point for the fact that release schedules have been > getting set (though, I suspect, not explicitly by the Board), that gets us to > 1 out of a possible 5. This is not a great track record. > > Before we propose a different setup, I think we need to figure out what went > wrong here. It already seems like some members of the Technical Board may not > have really been familiar with the responsibilities, or may not have > understood that some of the required duties were in fact required. And it > seems that several members of the Technical Board found themselves in > positions where they didn't have the time/capacity to carry out the > responsibilities, but also took no action to communicate this outside the > Technical Board. > > Are these things that would be solved by yet another governance rewrite? Or > are they things that could just as easily happen again? I suspect the latter. > So I think proposals for new governance should be on hold for now until these > things are sorted out. > > Also, on a personal note, I'd be a bit annoyed if DEP 10 were basically > tossed aside without being properly tried in practice. > > > -- > 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/CAL13Cg-Y90u7wH8v9ZoWRT_5ZEnr%3Dhpe9ga6t28tn%2BrPH_Ussg%40mail.gmail.com > > <https://groups.google.com/d/msgid/django-developers/CAL13Cg-Y90u7wH8v9ZoWRT_5ZEnr%3Dhpe9ga6t28tn%2BrPH_Ussg%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- 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/b0dbf74f-a6e1-40f4-8b4a-e66972df7296%40app.fastmail.com.
