Changing the role of the Technical Board

[Andrew Godwin]

Hi everyone,

I want to start a conversation about the Technical Board and its role in Django, and how I'd like to change it, including its name.

Since its inception, the Technical Board has effectively only functioned as a backstop vote for large features that require DEPs, of which there have been only two in the last five years. I believe it can be much more useful than this, while still not dominating Django's direction.

I would like to initially suggest the following high-level changes, that I will start formalising into a process DEP if we reach broad agreement:

Eligibility requirements are loosened and made less code-oriented

Anyone who demonstrates a "decent" history of contributing to Django in any fashion, and who does not have any conflicts of interest, and clearly wants to work in the best interests of the framework, would be eligible. (Yes, this is going to be fun to define in a DEP).

The current eligibility requirements include the need to have participated in discussions about the direction or development of Django in the last two years, which given the relative lack of big discussions in the last two years makes it rather problematic.

A more active role is taken in suggesting features

A regular "call for big ideas" is taken by the Board, and a clear set of "these are the technical/design/process/etc. ideas that we'd like to do" is published. This list would be, among other things, useful to raise money for grants to work directly on those features.

DEP 10 already mostly provides for this - it says that the Board should "put out calls for proposals and ideas for the future technical direction of Django", so this would more be us just Doing The Thing rather than changing too many rules.

The name is changed to "Steering Council" (like Python)

I believe this is a more accurate reflection of what the group should be doing and a reflection that you should not need to be directly coding Django every day to participate - and names have meaning, and thus power.

The overall election process, other powers, and current members remain the same

I think this part works relatively well. I did consider if we should allow simultaneous Technical Board/Steering Council membership and DSF Board membership, as this is currently banned, but I think the reasons behind this still hold for now.

This of course would be a "major change" and trigger a lot of procedure, notably a supermajority vote of the current Board, and a DSF Board vote, but I do believe it is in the best interests of the framework.

I am very interested in any feedback on these suggested ideas, including any additional changes you think might be appropriate that I have not covered here.

Andrew

[James Bennett]

Something I note here is that it's presenting a solution, but not clearly (at least, from my reading) presenting the problem to be solved.

Is it a lack of people proposing features? If so, I'm not sure this helps -- it would, to me, suggest that only members of the Technical Board/Steering Council/whatever-it's called are supposed to do that, since it's in their job description. Would people then expect to, or be expected to, run for a seat in order to contribute something?

Is it a more general lack of engagement? If so, I'm still not sure how this helps -- the idea of DEP 10 was to make it *easier* for people to step up and get involved, since it got rid of the idea of the "core team" with their special privileges, but I don't think any form of technical governance actually solves engagement issues. At best it can make engagement-specific efforts easier, but I don't see how re-centralizing authority (or creating the impression of it) would achieve that.

Is it to make fundraising easier? That sounds again like something that technical governance really can't do on its own -- it needs to involve the DSF Board, and there are reasons why the DSF was historically wary about doing targeted fundraising for specific features in Django.

Loosening eligibility is fine, though I agree it's going to be very difficult to write down in an enforceable way -- the DEP 10 language and process was intended primarily to prevent trolls and other bad-faith actors from being able to run effectively for the Technical Board, and there's a balance where the more you loosen it up, the more you also open the door for those kinds of people.

Also, regarding the multiple roles restriction: it currently is allowed for a single person to simultaneously be on both the Technical Board and the DSF Board, and there are even procedures in DEP 10 for things like mandatory recusal for DSF Board votes and actions that affect the Technical Board. What's not allowed is simultaneously being a Merger and on the Technical Board.

[Andrew Godwin]

These are some great points, James - let me try to tackle them roughly in order.

Proposing features - this is already in DEP 10, so I more just want to get that aspect of the Board actually going (and, as a side-effect, have something to aid fundraising). I am talking with the current Board separately on an internal thread, where the current stance (not everyone has responded) is that I am personally happy to take on all the work here for now - but I want to make sure it's not just me in the long run, be that merely proving that the idea works or attracting board members who want to specifically mediate such discussions and interaction with the wider community.

Engagement - It's not about "lack of engagement", and I think any issues there are deeper problems with OSS communities and the fact that we have to learn to sustainably work with the people we have rather than throwing everything at trying to recruit fresh, new people. I have ideas around this topic specifically, but they will not be solved in terms of the Board alone.

Loosening eligibility - If you're up for it I would very much value your help here in terms of refining wording once I have a first draft. My initial direction was to still require the 18 month history of contributions, but widen it from "technical" to more kinds of work (obviously the discussion part is in there too, but I think in general we can do a bit more of an OR rather than an AND on the current requirements, keeping a minimum time of contribution to prevent bad actors)

Serving on the DSF Board - you are of course right, I misread the DEP last week.

Overall, if all we do is change the name and start actually doing calls for features as outlined in DEP 10, I'll honestly be happy - but I think, given the most recent TB election was uncontested and several long-time Django contributors have told me they'd be more willing to join a TB that was less strictly technical-all-the-time, that it makes sense for us to also look at those requirements.

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-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg-mWWK0%2Bzkvi%3DCWu0e%3DbX-rOsLq4gHHdBuKQ8UL_8pRSg%40mail.gmail.com.

[James Bennett]

On Mon, Oct 24, 2022 at 2:24 PM Andrew Godwin <and...@aeracode.org> wrote:

Proposing features - this is already in DEP 10, so I more just want to get that aspect of the Board actually going (and, as a side-effect, have something to aid fundraising). I am talking with the current Board separately on an internal thread, where the current stance (not everyone has responded) is that I am personally happy to take on all the work here for now - but I want to make sure it's not just me in the long run, be that merely proving that the idea works or attracting board members who want to specifically mediate such discussions and interaction with the wider community.

I admit I haven't been following Django development all that closely since I mic-dropped after DEP 10 passed, but this is worrying, because canvassing for feature proposals is not an optional thing -- DEP 10 *requires* the Technical Board to do this at least once per feature release of Django. Has that not been occurring? Because if it hasn't, then we have a major problem, and I don't see how the current proposal would resolve it.

Overall, if all we do is change the name and start actually doing calls for features as outlined in DEP 10, I'll honestly be happy - but I think, given the most recent TB election was uncontested and several long-time Django contributors have told me they'd be more willing to join a TB that was less strictly technical-all-the-time, that it makes sense for us to also look at those requirements.

I have concerns about this because what it really feels like is a first step toward merging the Technical Board and the DSF Board into a single unified governance board of everything to do with Django, and I think the split between governance of Django-the-codebase and Django-the-everything-the-DSF-does is a useful and important one (not least for legal reasons).

[Andrew Godwin]

> Has that not been occurring? Because if it hasn't, then we have a major problem, and I don't see how the current proposal would resolve it.

It has not. While I cannot speak for the other members of the Board, I got burnt out in 2019, and then the pandemic began, and so it has not really been something I've pushed for in the past three years (and I believe I was one of the drivers of getting that in DEP 10 in the first place). We never really got into the rhythm of doing it, and I think a lot of us got busy or burnt out.

My personal belief is that if something is not working, it is time for a re-analysis of the situation and a change, even if what's written down in the rules is fine on its face.

This proposal is part of a larger set of community changes I would like to consider - I am, for obvious reasons, not blasting the community with them all at once, but I do believe that a strong, visible set of leaders, with a clearly outlined set of principles and shepherding a community-guided vision, is the most important thing to establish - both in terms of the Technical Board and the DSF Board.

I have a much longer blog post in me about my evolving belief in the need for visible, servant leaders in OSS communities rather than trying to embrace a flat hierarchy with mechanical checks and balances - but that is for another day.

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-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg93CvLgVU567MsvqKZAiWVBxxm1-L_YuEUhjr_JRySBwg%40mail.gmail.com.

[James Bennett]

On Mon, Oct 24, 2022 at 6:33 PM Andrew Godwin <and...@aeracode.org> wrote:

It has not. While I cannot speak for the other members of the Board, I got burnt out in 2019, and then the pandemic began, and so it has not really been something I've pushed for in the past three years (and I believe I was one of the drivers of getting that in DEP 10 in the first place). We never really got into the rhythm of doing it, and I think a lot of us got busy or burnt out.

My personal belief is that if something is not working, it is time for a re-analysis of the situation and a change, even if what's written down in the rules is fine on its face.

Well.

My first reaction to this is: if having a DEP that says the Technical Board is supposed to take the lead in gathering feature proposals didn't get them to do it, it doesn't feel like another DEP saying they're responsible for that is going to fix it.

And it's not just the lack of canvassing for features that's worrying; if members of the Technical Board didn't feel they were up to the job, they should have let someone know that. Getting burned out or overcommitted is a thing that happens, and a thing that was anticipated in drafting the governance -- DEP 10 has a procedure for it!

Why did no member of the Technical Board do that?

This proposal is part of a larger set of community changes I would like to consider - I am, for obvious reasons, not blasting the community with them all at once, but I do believe that a strong, visible set of leaders, with a clearly outlined set of principles and shepherding a community-guided vision, is the most important thing to establish - both in terms of the Technical Board and the DSF Board.

I have a much longer blog post in me about my evolving belief in the need for visible, servant leaders in OSS communities rather than trying to embrace a flat hierarchy with mechanical checks and balances - but that is for another day.

And I strongly disagree -- I think Django is far better off without centralized hierarchical leadership, which is why I wrote and pushed DEP 10. People who want to be technical leaders for Django are free to do so already; there's no need to have to occupy a formally-titled hierarchical role in the project's governance in order to do that. And the lack of requirement for such a formally-titled role is crucial to ensuring other people feel *they* can jump in and start contributing their technical leadership, too.

But what's most bothering me is that, from the sound of it, the DEP 10 governance wasn't even really tried.

I know people have asked for Technical Board input at least a couple times in threads on the django-developers list, and I've looked at them and I'm having a hard time finding anything resembling what was supposed to happen under the DEP. It seems clear that the duty to collect feature proposals was not carried out. And from the sound of what you're saying in this thread, the Technical Board is mostly communicating with itself about this, in private, when the direction of Django is supposed to be worked out publicly and transparently. That's why we shut down the old private communication spaces for the former "core team" after DEP 10 was adopted.

So forgive me for being blunt, but: if the Technical Board is not following the governance we have, I think replacing the Technical Board's current membership should be higher on the list of remedies than replacing the governance.

[Florian Apolloner]

Hi James,

On Tuesday, October 25, 2022 at 12:27:03 AM UTC+2 James Bennett wrote:

On Mon, Oct 24, 2022 at 2:24 PM Andrew Godwin <and...@aeracode.org> wrote:

Proposing features - this is already in DEP 10, so I more just want to get that aspect of the Board actually going (and, as a side-effect, have something to aid fundraising). I am talking with the current Board separately on an internal thread, where the current stance (not everyone has responded) is that I am personally happy to take on all the work here for now - but I want to make sure it's not just me in the long run, be that merely proving that the idea works or attracting board members who want to specifically mediate such discussions and interaction with the wider community.

I admit I haven't been following Django development all that closely since I mic-dropped after DEP 10 passed, but this is worrying, because canvassing for feature proposals is not an optional thing -- DEP 10 *requires* the Technical Board to do this at least once per feature release of Django. Has that not been occurring? Because if it hasn't, then we have a major problem, and I don't see how the current proposal would resolve it.

To be honest that is not how I understood and read the DEP. In my understanding the goal of the DEP was to make contributions easier and put the power into the community. The role of the technical board as I understood it was to assist or step in when our other decision making processes fail. As such I didn't read the DEP 10 as a requirement for the technical board to put out calls for proposals and ideas as long as those ideas are around anyways. With the powers the technical board has, I was always rather hesitant to use them unless it seemed necessary.

> And it's not just the lack of canvassing for features that's worrying; if members of the Technical Board didn't feel they were up to the job, they should have let someone know that. Getting burned out or overcommitted is a thing that happens, and a thing that was anticipated in drafting the governance -- DEP 10 has a procedure for it!

> Why did no member of the Technical Board do that?

Because on one hand, even with a process for it out there there might be a mental barrier to do so and admit failure to yourself. On the other hand, and this is probably my reason, is that we apparently have a different understanding of how the technical board is supposed to work. This is probably fully my fault, but the impression I got from the previous technical boards was that the role was to be rather passive and a tie-breaker when all else fails. I also think that I am not the only one who thought so.

Obviously the way I see (saw) the role of the technical board is not how you and probably others see it. As such I have no problem stepping down from the technical board if people feel I over- or understepped.

Cheers,

Florian

[Carlton Gibson]

Loosening eligibility is fine, though I agree it's going to be very difficult to write down in an enforceable way -- the DEP 10 language and process was intended primarily to prevent trolls and other bad-faith actors from being able to run effectively for the Technical Board, and there's a balance where the more you loosen it up, the more you also open the door for those kinds of people.

I think it’s very easy for us to overplay this difficulty by thinking that we ex ante need to define what contributions would qualify someone to stand for the Steering Council. 

In reality it’s usually entirely clear in any given case whether someone has been contributing to Django or not. 

The issue here (I take it) is that we both want and need to widen the notion of contributing so that it’s not so tightly focused on current, active, engagement with the development on django/django. I thought the wording in DEP 10 was good, but, two elections in, it’s already clear that it doesn’t produce a large enough candidate pool, or one that’s representative of the Django community, or the DSF members. 

Rather than struggling with too much precision, I believe we’d be better suited with something deliberately vague — a history of contributing to Django, say — and then including a list of exemplars of that…

Such contributions may include, but are not limited to: 

• Code contributions to django/django
• Organising Django community events
• …
  (I leave this in sketch format deliberately.) 

Thinking of all the recent discussions on what contributing to Django means — I have Kojo Idrissa’s keynote from DjangoCon Europe, and Jeff Tripplet’s comments during the panel at DjangoCon US in mind that would be/will be accessible to all via YouTube, and which are both on-topic — it’s likely that there’s nothing that we can pick out as uniting everything that we’d call contributing. 

Still, it remains clear-as-day in most cases. Frank, who replied already here: clearly yes. Some troll off the internet we never heard of: clearly no. There will be (likely few) difficult cases in the middle, sure — that’s universal — but it’s unlikely to be significant which way we decide in such a case. 

Practically, let anyone stand, but also let anyone ask for a review of any one standing. If so asked, let the Board, who are organising the election, judge, perhaps asking around, if this person is really a legitimate member of the community. Let the judgement of the Board be final. 

I think the Steering Council should — as per the suggestion — pick up the proposal side of it. That this hasn’t happened already is, I think, a slight side-issue. (Surviving the ongoing pandemic has kept everyone busy. Having a pool of candidates can but help.) 

+1 to the proposal. 

Kind Regards,

Carlton

p.s. That a current Merger cannot also on the TB has proven correct: to have a fallback is essential for Merger sanity, e.g. the typing proposal, for which it’s not reasonable for the set of Mergers to make such a decision. (This is independent of oversight, which we’d all agree is necessary to have, even in we assume Mergers always to be benign. 🙂) 

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6386c4ae-0dd1-41aa-af6e-24c1b879da64%40app.fastmail.com.

[Andrew Godwin]

On Tue, Oct 25, 2022, at 12:12 AM, James Bennett wrote:

My first reaction to this is: if having a DEP that says the Technical Board is supposed to take the lead in gathering feature proposals didn't get them to do it, it doesn't feel like another DEP saying they're responsible for that is going to fix it.

I agree. Me proposing the DEP changes is mostly merely formalising some other changes I want to catalyse here - the DEP is an outcome, not the start, here.

Getting burned out or overcommitted is a thing that happens, and a thing that was anticipated in drafting the governance -- DEP 10 has a procedure for it!

Why did no member of the Technical Board do that?

Again, speaking for myself - because we were doing almost all the functions of the Board except for the feature canvassing. I also saw the relative lack of candidates for Board elections and essentially thought "better burnt-out me than literally nobody".

And from the sound of what you're saying in this thread, the Technical Board is mostly communicating with itself about this, in private, when the direction of Django is supposed to be worked out publicly and transparently. That's why we shut down the old private communication spaces for the former "core team" after DEP 10 was adopted.

That is not the case - this thread is the majority of the discussion. I opened a thread on the TB mailing list in case people there wanted to give specific, blunt feedback about how they would feel about being affected by this as current Board members, but it has only a couple of replies, and nothing that hasn't been discussed here.

So forgive me for being blunt, but: if the Technical Board is not following the governance we have, I think replacing the Technical Board's current membership should be higher on the list of remedies than replacing the governance.

Forgive me for being blunt but... that seems like a really bad idea? The current board ran uncontested, so if all five of us step down I suspect there may not be a Board at the end of the day. The DSF Board's current difficulties finding candidates I think reinforces that fact - one of the changes I was considering bringing in here was "what if we have to reduce the TB to 4 or 3 people in the near future".

Again, I'm not saying "we should write a new DEP and that'll fix it", I'm trying to come from a position of working out what we can and should be doing, and then ensuring our rules match that.

Andrew

[Eric Matthes]

I want to offer a perspective from outside the Django community.

> I also saw the relative lack of candidates for Board elections and essentially thought "better burnt-out me than literally nobody".

I appreciate Andrew's honesty here. I have been a volunteer on our local mountain rescue team for about 20 years. That has involved ongoing work with our local fire department, which includes EMS and dive rescue divisions as well. It also involves work with rescue teams from around Alaska, the US, and the rest of the world.

On our local team, many of us have been feeling badly because our numbers are down. People have left the team in recent years, and we have had a really hard time finding new members. We all start to think we're not doing enough, and not doing our work well enough. But when we start to talk to each other, we find that this is a widespread issue. Volunteerism is down all over the place: in all of the divisions of our department, in various regions of our state, and across the country. I'm less clear on how things are playing out outside the US. We are having ongoing discussions on how to maintain an effective rescue team with all of this in mind. It's not as simple as "offer better training", "have more social events", or "implement a recruiting drive". We are working towards reframing our team not based on the capacities that volunteers had 25 years ago when the team was forming, but based on the capacities that people have in our community today.

I don't claim to know if this relates to what we're seeing with the two Django boards. But I and others have wanted to step back from our mountain rescue leadership positions, and we find ourselves staying in these roles for exactly the reason Andrew mentioned here: there's no one ready to replace us.

I think the discussions here are moving in the right direction. We are looking at the community we have, and figuring out how to build and maintain an active leadership group based on the current capacities of our community members.

Eric Matthes

[James Bennett]

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.

[Andrew Godwin]

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

--

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

[James Bennett]

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

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.

If the problem in front of us is that the Technical Board isn't up to the level of activity DEP 10 asks of them, and you believe no substitute group of members exists that would be up to it either, I'm not sure I see how your proposals are going to fix that, especially since you seem to eventually want to create *more* responsibility for active intervention and leadership.

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

A Technical Board election will automatically trigger at the release of Django 4.2, which is not *that* far off. But the Technical Board could always trigger an election any time they want to.

I personally would still like to understand how the current Technical Board came to what seems to be such a misunderstanding of how the governance was supposed to work. And while there have been explanations presented for why the Technical Board didn't communicate the problems it was having, they also come across as worrying -- we're all adults here, and we need to be able to trust each other to speak up when there's a problem. How did we go, apparently, multiple years with the Technical Board not carrying out their responsibilities and also nobody saying anything about it?

Until we understand that I don't think we should be trying to change the governance again.

And I still would like to see DEP 10 actually tried out. Maybe it involves electing a Technical Board with much more explicit up-front communication of expectations, since it seems a lot of the current members were unaware of the Technical Board's actual responsibilities. Maybe it involves someone just constantly poking them with reminders. Maybe something else. But it feels wrong on many levels to start moving on from DEP 10 when it's becoming increasingly clear that DEP 10 was never really *tried*.

[Andrew Godwin]

My intention is indeed for us to run a new Technical Board election come the end of 4.2, with much better and more explicit communication about what will be expected of the new members, and a larger candidate pool to pull from to hopefully make that work.

I will be posting my actual proposed DEP shortly so it's more clear exactly what I want to change at a written-rules level - I suspect feedback on a more concrete proposal will help us talk about it more clearly.

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-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg_%3DbczbtMP5B6avbNTLi%3DLf1SU_Z%3Dchz6j0u5L1MPMbzw%40mail.gmail.com.