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 firstname.lastname@example.org. 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.