Hi All. 

OK, so last week I was at DjangoCon US in San Diego. (Thank you if you 
organised that! Hi! if we met and chatted.) 
I gave a talk ("Your web framework needs you!") inspired by the discussion 
on the 
<https://groups.google.com/d/topic/dsf-members/GWOzvsOAGUs/discussion> DSF 
list and the proposal to dissolve Django Core 
<https://github.com/django/deps/pull/47>. (Can’t see the DSF list? Join the 
DSF 
<https://docs.google.com/forms/d/e/1FAIpQLSd5lbWxAO-sylEEjHVKBNIpmHlhdJRf0_LCo8glnLUWd-Q2Sw/viewform>
.)
I was asking for more participation in general, and participation that is 
more representative of the wider Django community in particular.

There was lots of good input from many people, including (but not, at all, 
limited to) representatives of groups such Pyladies, DjangoGirls, and so 
on. 


The recurring themes seem to me to fit into three categories:

   1. The importance of *mentoring*. 
   2. The difficulty of *finding tickets*. 
   3. The importance of *sprints*. 

The rest here is a summary of that. Hopefully it’s useful. 

Mentoring

For whatever reasons, the exiting *Contributing How-To* 
<https://docs.djangoproject.com/en/dev/internals/contributing/> doesn’t 
lead to contributions from a demographic that matches the wider Django 
Community. 

The point that came up again and again about this was that *mentoring* is 
one of the best (perhaps the best?) tool in helping to change this. 

Django Core Mentorship

We don’t have an official mentoring programme but we do have the 
django-core-mentorship 
list <https://groups.google.com/forum/#!forum/django-core-mentorship>. 

This must be about the best-kept secret in the Django world: it’s gets ≈0 
traffic, but I told everybody at DjangoCon about it, and that they should 
use it. 

If you are not on django-core-mentorship, and you’re willing to help 
prospective contributors, please sign-up. I’m hoping we can drive some 
traffic to it. 

Maybe there’s call for something more formal, but at least until DCM is 
actually being used, that seems (to me) like something we can postpone. 

Finding Tickets

The next thing was that there’s not enough guidance on what to work on. 

The guidance is to look for *Easy Pickings*. There are ≈1300 accepted open 
tickets in TRAC. 13 of these are marked *Easy Pickings*. 

That’s not enough. I think we’re too tight with it (or need another grade). 

There are *many* tickets which aren’t super hard: I put it that, most of 
our community solve harder problems every day *using Django* than most 
tickets require. 

Yes, they still require time, love, energy, etc — and maybe some mentoring 
— but it’s not primary research, in the main.

I talked to people who had (at the conference) got the test suite running 
and such, but been overawed by the (for want of a better phrase) *sheer 
face* of issue tracker. 

We would do well to invite people better here. (I don’t have instant 
solutions.) 

Sprints

I’m not historically a Django-sprinter. (I have too many children for that 
TBH, but they’re getting older…)

I always thought it was for a hard-core to work on hard issues. 

Shows what I know… 🙂

It was strongly impressed upon me that the real benefit of sprints is being 
able to give new contributors the support they need to make their first (or 
second or…) contribution. 

In particular, groups such as Pyladies can organise a sprint event with the 
specific goal of helping members of the community get across the barriers 
to contributing. This can reach numbers that otherwise simply aren’t 
possible. (So wow. Basically.)

Sprints & Mentoring

Obviously having mentors at sprints is a key component. 

But even if you (or I) can’t attend a sprint, maybe we can (sometimes) be 
available at the right time to contribute remotely. Maybe, in fact, remote 
mentors are a key resource in more remote parts of the Django-sphere. 

It turns out just being on e.g. Twitter can be enough here. 

If we’re all on django-core-mentorship, maybe sprint organisers could post 
notice of an upcoming sprint. 

Sprints & Finding Tickets

It turns out it’s equally hard for a sprint organiser to work out what 
tasks to give sprinters. 

At DjangoCon (some) people have a topic and asks others to join them. But, 
maybe if you’re short of experts and so on, that’s not necessarily a model 
that allows that scales out in other contexts. 

It was put to me that, if we had something like curated project boards 
(think Trello or GitHub projects) with groups of tickets… perhaps some 
easier, some harder… Perhaps with a *curating mentor*, even if remote… — 
*THEN* it becomes much easier for a small groups to organise a sprint, 
whatever their group may look like, wherever they may be. 

It struck me that, whilst we can (say) filter tickets by component (and 
such) we’re were a way from this. 

(Again, I don’t have instant solutions — but I suspect there’s an 80:20 
available somewhere here…) 

And finally…

Beyond all that, we clearly have a problem with the on-ramp. Anything that 
smooths that is welcome. 

I asked in particular that leaders from outside the demographic that is 
already contributing help in that process. (I just don’t think we’ll get it 
right otherwise.) 

The discussions leading to the points I’ve summarised here are part of 
that. Just the beginning I hope. 

All positive input very welcome. Hopefully there’s nothing actually 
controversial in all of this. 


Kind Regards,

Carlton


-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to