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