*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. 🙂)
On Mon, 24 Oct 2022 at 23:24, Andrew Godwin <and...@aeracode.org> wrote:
> 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
>
> On Mon, Oct 24, 2022, at 2:54 PM, James Bennett wrote:
>
> 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.
>
>
> --
> 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-mWWK0%2Bzkvi%3DCWu0e%3DbX-rOsLq4gHHdBuKQ8UL_8pRSg%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAL13Cg-mWWK0%2Bzkvi%3DCWu0e%3DbX-rOsLq4gHHdBuKQ8UL_8pRSg%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/6386c4ae-0dd1-41aa-af6e-24c1b879da64%40app.fastmail.com
> <https://groups.google.com/d/msgid/django-developers/6386c4ae-0dd1-41aa-af6e-24c1b879da64%40app.fastmail.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/CAJwKpyT%2BQZ1JjB9Pz1KpwHmo-K%3DJH%3DmR99e2RDqCaszhnVdpsg%40mail.gmail.com.
