Re: Widening participation (Thoughts from DjangoCon)

[Federico Capoano]

Hi everyone,

It's been great to read some good insights on this discussion.

How to attract new contributors from a different demographic (geographic 
area and age)? Good question.

I wanted to share with you my experience as (second year) organization 
administrator and mentor for OpenWISP  (an open 
source network management system built on top of Django) in the Google 
Code-In program , which I think can really 
help in attracting new contributors from a different demographic group, 
which is really great for a project, because brings in a more diverse 
perspective and fresh lymph and enthusiasm.

*Google Code-In* is the sibling of the *Google Summer of Code* (in which 
django participated several times), and it is a global contest in which 
pre-university students in the range of 13-17 learn how to contribute to 
open source.
It works as follows:

- some open source organizations are selected each year, the list of 2018 
participating orgs  counts 
some notable participants as Postgres, Drupal, Wikimedia, KDE, OSGeo, Fedora
- these organizations publish a series of tasks with the aim of helping 
students familiarize with their codebase and practices in order to start 
contributing
- each tasks contains information, tags and list available mentors for that 
tasks
- students can see the list of tasks in a dashboard, it is publicly 
available so you can also see it: https://codein.withgoogle.com/tasks/
- students choose the tasks they want to work on and they "claim" it, they 
then use the organization's support channels (eg: IRC) to interact with 
mentors and other fellows to look for help
- at the end of the contest, each organization chooses 2 winners and 4 
finalists who receive prizes, the 2 winners win a trip to Google's HQ in 
California

Tasks can be about coding, QA/testing, design, outreach/research, 
documentation/training.

This program brings some challenges and needs a lot of patience, but has 
been great for the OpenWISP community for the following reasons:

- we've been lucky to get some really great students, their skills for 
their age is just incredible (teenage prodigies really)
- they learn really fast, so total beginners become productive in 2 months 
while more skilled students become great contributors in no time
- the big influx of beginners who seem to all stumble on the same issues 
really helped us to understand which roadblocks had to be removed in order 
to improve our documentation and make it easier for them to onboard
- the demographic is really diverse, many students are from Asia but we got 
some great students from Poland, Russia and the Americas
- the contest runs online, worldwide and remotely, no physical presence is 
needed
- we've been able to close a lot of the easier issues and some very useful 
higher impact (non-trivial) issues
- just OpenWISP trained over 950 students in 2018 
, some of these 
students will become mentors next year, allowing us to train even more
- some of these students stick around and keep contributing also when the 
program ends
- they bring in a fresh perspective, helping us to keep the project modern 
and ensure generational handover (which I think it's an overlooked problem 
in today's open source community)

*One important note*: many of the good students of OpenWISP choose us 
because our system is built in Python and Django and they either already 
know and like this stack or want to learn to use it.

So I think having some Django mentors to participate in this program, 
either with a dedicated organization or under an umbrella organization, 
could be beneficial for Django and Open Source in general.

It's not a silver bullet, it's not a panacea, but it can help.

PS: in one of our training tasks we have our students do the DjangoGirls 
tutorial , they 
really love this task :-)

Federico

-- 
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/e4b230d9-7b09-4a99-9268-43dc4b07a810%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Claude Paroz]

Le jeudi 13 décembre 2018 09:17:49 UTC+1, Carlton Gibson a écrit :
>
> ...
> I'd like to push on these avenues (and similar) before we take on the 
> massive project of changing systems. 
> (Ultimately I think we'd change system and find ourselves in exactly the 
> same boat.) 
>

Thanks Carlton, I totally agree with this position. I'm convinced the 
difficulty is not in the tool (even if improving tooling is always welcome) 
but rather in the content. We should not complain that easy issues are 
solved, that's IMHO the sign of a good community. 
It's probably a common issue in mature projects. At some point, what you 
need is skilled and/or perseverant contributors with enough time to solve 
harder issues. And those contributors are not like fishes in the sea…

Claude

-- 
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/ec4e3794-2607-418e-8e84-3a1b150dc821%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Carlton Gibson]

Thanks for the discussion all. 

FWIW, I think Trac is OK. We have a massive history there, which is 
valuable. And you don't need the commit bit to be able to triage tickets. 

I don't think moving to another system solves the problem: we'd still have 
1400 accepted open tickets, which is too much for a new contributor to 
take-in.

I'm hoping to have a bit more time to think about it over the winter but my 
thoughts thus far are roughly:

* Dashboards, like http://dashboard.djangoproject.com/ are cool and useful. 
We should expand usage of those. 
* Filtering by component is an obvious candidate for this. 
   * It's much less scary that way
   * e.g. you can totally ignore the ORM tickets 🙂
   * e.g. There's ONLY (cough) 175 tickets for the admin 

 — 
that's more addressable. 
* Better use of "Easy Pickings" and/or a "Not Phenomenally Difficult" flag 
would give more texture. 
* Ultimately (whatever system we use) I think having experienced 
contributors who know a bit of the issue tracker and can flag or point out 
issues that would be suitable would be effective. 
* "I'm retired from contributing to Django, but this ticket wouldn't be 
too difficult, and maybe I could offer a pointer or two to someone who 
wanted to take it on."

I'd like to push on these avenues (and similar) before we take on the 
massive project of changing systems. 
(Ultimately I think we'd change system and find ourselves in exactly the 
same boat.) 

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/70720581-0166-4d7b-a75d-3dc9242abce6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Tom Forbes]

Regarding Gitlab: I love gitlab and for organizations it's one of if not
the best tools in its space. But it falls down for projects like Django,
and I don't think moving migrating the code from GitHub is a good idea.

The labels would need automating, which would require a GitHub bot of some
kind. The workflow could be as simple as "new tickets are assigned the
awaiting review tag" and "only members of the Django org can modify tags"?


On Tue, 11 Dec 2018, 19:38 Josh Smeaton  For what it's worth, I agree. I think we should consider using GitHub
> issues. I don't think there's anything in Trac, from a user perspective,
> that we couldn't really do with Issues. The main issue, I think, would be
> allowing non-committers (organisational members) to triage tickets and
> change the ticket status.
>
> But I don't have the time to plan or champion a change like that through
> these days, so while I'd like to see it happen, I'm not the person to push
> for it to happen.
>
> Jamesie: please see "Why not Gitlab?" [0]. While it might be better from a
> technical standpoint, it would not be better than GH Issues from an
> onboarding perspective.
>
> [0]https://www.python.org/dev/peps/pep-0581/#why-not-gitlab
>
> On Tuesday, 11 December 2018 23:20:21 UTC+11, Tom Forbes wrote:
>>
>> > The only reason Github issues would be a consideration is if the group
>> thought the onboarding experience (being where users already are with a
>> tool they're already familiar with) would have more value than sticking
>> with with the status quo which is strictly better from a feature
>> perspective than GH Issues
>>
>> I really think it's worth considering - I'm not convinced Trac is
>> strictly better from a feature perspective. Things like the dashboards are
>> interesting, sure, but what does it do that Github issues don't? And by
>> this I don't mean features that exist but we don't use, I mean our general
>> ticket workflow that 99% of contributors are exposed to. There are far
>> larger projects than Django currently using Github issues successfully and
>> they have a far more complex workflow including CLA's, high-granularity
>> tags, automatic reviewer selection, automatic closing, etc etc.
>>
>> The cost of a migration would not be cheap, but is it worth doing a
>> formal evaluation and consider it? The "why Github section" (
>> https://www.python.org/dev/peps/pep-0581/#why-github) in that PEP lists
>> some good reasons that apply to us as well. The key one for me is lowering
>> the barrier to entry which I think we should be aiming towards. If we are
>> looking to expand the development group and get more people onboard we may
>> need to shake things up, as the status quo is problematic in that area.
>>
>> On 11 December 2018 at 12:04:32, Josh Smeaton (josh.s...@gmail.com)
>> wrote:
>>
>> I don't think something like Jira would even be a consideration.
>>
>> The only reason Github issues would be a consideration is if the group
>> thought the onboarding experience (being where users already are with a
>> tool they're already familiar with) would have more value than sticking
>> with with the status quo which is strictly better from a feature
>> perspective than GH Issues. Incrementally improving Trac can improve the
>> value prop for not changing, but I don't think anyone that actually uses
>> Trac would say it's worse from a feature perspective. Even if that value
>> judgement did land on GH issues side, there would still be a large
>> operational undertaking to make that transition.
>>
>> Again, the PEP for doing this for CPython would be very similar for
>> Django, so please refer to https://www.python.org/dev/peps/pep-0581/ for
>> some examples of why and what operational concerns there can be (migration,
>> permissions, etc).
>>
>> On Tuesday, 11 December 2018 07:26:58 UTC+11, Ira Abbott wrote:
>>>
>>> Apologies for the double post - my last one was not clear.  "just that"
>>> means that the payment is intended to indicate that it is worth a JIRA
>>> license to me to not use JIRA.
>>>
>>> This group does great things.  I am sure that the group can come up with
>>> some interesting ways to scale that will ultimately benefit the framework
>>> as a whole.
>>>
>>> On Monday, December 10, 2018 at 3:21:53 PM UTC-5, Ira Abbott wrote:

 FWIW: Please consider my contribution of $84 (one bulk JIRA license for
 one year) to be just that.

 On Monday, December 10, 2018 at 2:14:07 PM UTC-5, Zachary Garwood wrote:
>
> I'd pay money to NOT use Jira.
>
> On Mon, Dec 10, 2018, 11:09 AM Dan Davis 
>> Tom, you are right about the UX issues, but full-text and inverted
>> indexing would help with the responsiveness as well.  Technically, I was
>> talking about djangoproject's TracSearch
>> .  That's closer to good UX
>> as well, because you can get there by progressive enhancement rather than
>> taking stuff away.
>>
>> You are al

Re: Widening participation (Thoughts from DjangoCon)

[Hanne Moa]

On 12/11/18 8:38 PM, Josh Smeaton wrote:
Jamesie: please see "Why not Gitlab?" [0]. While it might be better from 
a technical standpoint, it would not be better than GH Issues from an 
onboarding perspective.


[0]https://www.python.org/dev/peps/pep-0581/#why-not-gitlab


Note that they didn't even attempt moving everything to Github.


--
HM

--
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/56550a30-6b2d-3db6-0b35-0e6785e2af4d%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Hanne Moa]

On 12/12/18 12:34 AM, Jamesie Pic wrote:

Thanks Josh, love your link, seems like it dates from 2017 during the
period when GitLab UI was redesigned. But GitLab is still emerging as
a standard tool no matter what.


I'm currently attempting to move some issues from github to gitlab. The 
rant still stands. I've only managed to move a complete set of issues 
*once*, from trac to Bitbucket. IIRC there was an export-script which 
output I then hand-edited, *and* all contributors had users on bitbucket.



--
HM

--
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/11c6f178-fb5f-5280-3757-c836d4882759%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Jamesie Pic]

Thanks Josh, love your link, seems like it dates from 2017 during the
period when GitLab UI was redesigned. But GitLab is still emerging as
a standard tool no matter what.

-- 
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/CAC6Op19Das4BwaiFSo8pRK6s0pcbSp5ECSDH83aoVyEe6DD3tA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Abhinav tuteja]

Hey i do also code in django can we talk ?

On Fri, 26 Oct 2018 at 7:15 PM, Carlton Gibson 
wrote:

> 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
> 
> DSF list and the proposal to dissolve Django Core
> . (Can’t see the DSF list? Join
> the DSF
> 
> .)
> 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*
>  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 .
>
> 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

Re: Widening participation (Thoughts from DjangoCon)

[Josh Smeaton]

For what it's worth, I agree. I think we should consider using GitHub 
issues. I don't think there's anything in Trac, from a user perspective, 
that we couldn't really do with Issues. The main issue, I think, would be 
allowing non-committers (organisational members) to triage tickets and 
change the ticket status. 

But I don't have the time to plan or champion a change like that through 
these days, so while I'd like to see it happen, I'm not the person to push 
for it to happen.

Jamesie: please see "Why not Gitlab?" [0]. While it might be better from a 
technical standpoint, it would not be better than GH Issues from an 
onboarding perspective.

[0]https://www.python.org/dev/peps/pep-0581/#why-not-gitlab 

On Tuesday, 11 December 2018 23:20:21 UTC+11, Tom Forbes wrote:
>
> > The only reason Github issues would be a consideration is if the group 
> thought the onboarding experience (being where users already are with a 
> tool they're already familiar with) would have more value than sticking 
> with with the status quo which is strictly better from a feature 
> perspective than GH Issues
>
> I really think it's worth considering - I'm not convinced Trac is strictly 
> better from a feature perspective. Things like the dashboards are 
> interesting, sure, but what does it do that Github issues don't? And by 
> this I don't mean features that exist but we don't use, I mean our general 
> ticket workflow that 99% of contributors are exposed to. There are far 
> larger projects than Django currently using Github issues successfully and 
> they have a far more complex workflow including CLA's, high-granularity 
> tags, automatic reviewer selection, automatic closing, etc etc.
>
> The cost of a migration would not be cheap, but is it worth doing a formal 
> evaluation and consider it? The "why Github section" (
> https://www.python.org/dev/peps/pep-0581/#why-github) in that PEP lists 
> some good reasons that apply to us as well. The key one for me is lowering 
> the barrier to entry which I think we should be aiming towards. If we are 
> looking to expand the development group and get more people onboard we may 
> need to shake things up, as the status quo is problematic in that area.
>
> On 11 December 2018 at 12:04:32, Josh Smeaton (josh.s...@gmail.com 
> ) wrote:
>
> I don't think something like Jira would even be a consideration.  
>
> The only reason Github issues would be a consideration is if the group 
> thought the onboarding experience (being where users already are with a 
> tool they're already familiar with) would have more value than sticking 
> with with the status quo which is strictly better from a feature 
> perspective than GH Issues. Incrementally improving Trac can improve the 
> value prop for not changing, but I don't think anyone that actually uses 
> Trac would say it's worse from a feature perspective. Even if that value 
> judgement did land on GH issues side, there would still be a large 
> operational undertaking to make that transition. 
>
> Again, the PEP for doing this for CPython would be very similar for 
> Django, so please refer to https://www.python.org/dev/peps/pep-0581/ for 
> some examples of why and what operational concerns there can be (migration, 
> permissions, etc).
>
> On Tuesday, 11 December 2018 07:26:58 UTC+11, Ira Abbott wrote: 
>>
>> Apologies for the double post - my last one was not clear.  "just that" 
>> means that the payment is intended to indicate that it is worth a JIRA 
>> license to me to not use JIRA.
>>
>> This group does great things.  I am sure that the group can come up with 
>> some interesting ways to scale that will ultimately benefit the framework 
>> as a whole.
>>
>> On Monday, December 10, 2018 at 3:21:53 PM UTC-5, Ira Abbott wrote: 
>>>
>>> FWIW: Please consider my contribution of $84 (one bulk JIRA license for 
>>> one year) to be just that.
>>>
>>> On Monday, December 10, 2018 at 2:14:07 PM UTC-5, Zachary Garwood wrote: 

 I'd pay money to NOT use Jira.

 On Mon, Dec 10, 2018, 11:09 AM Dan Davis >>>
> Tom, you are right about the UX issues, but full-text and inverted 
> indexing would help with the responsiveness as well.  Technically, I was 
> talking about djangoproject's TracSearch 
> .  That's closer to good UX as 
> well, because you can get there by progressive enhancement rather than 
> taking stuff away.
>
> You are also right that switching to another system such as github 
> issues could be a better fix than customizing Trac.   But I find it 
> difficult to believe that Github issues grows up to cover as much 
> workflow 
> management as Trac issues or JIRA.   Maybe we need money to get JIRA.
>
>
> --
> 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 

Re: Widening participation (Thoughts from DjangoCon)

[Jamesie Pic]

Gitlab should be mentioned as a vastly superior alternative to trac +
GitHub + jenkins.

Le mar. 11 déc. 2018 à 14:01, Hanne Moa  a écrit :

> Whenever I've had to move from one issue-system to another, the main
> pain point has always been issue/comment ownership[*]. This is because
> many systems want a login-capable, verified user for every single
> person that have ever made an issue or comment. If there is no 1-to-1
> mapping, the issue/comment is often owned by the importing user, and
> the username/email of the original contributor is mangled into the
> issue/comment-text itself.
>
> This looks so nice for an issue with 50+ different contributors when
> wind up being owned by the same user. Robert explains to Robert that
> Robert's patch won't work with Roberts latest PR because Robert pulled
> the wrong commit that Robert made to update the dependencies that
> Robert discovered needed to be updated because Robert found a security
> flaw, with apologies to Robert. There's usually no way to search for
> the actual contributors either. It is as if importing to such
> issue-systems are an after thought. Starting out with a design where
> user and contributor are two different but potentially linked objects
> would have solved the problem *correctly*.
> 
>
> [*] There are no doubt problems other than this, it's just the one
> that bugs me the most. Especially since the solution so often is "Drop
> all history, start from scratch."
>
> --
> 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/CACQ%3DrreeXWcVCjxZGG18GDeeh98P_OxresAm9w_JrN0HSOQNhg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAC6Op19n-sfO2mLFGiXs0ohodCHK-%2BYEw9k7_n1r%3DJfq7VAFZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Hanne Moa]

Whenever I've had to move from one issue-system to another, the main
pain point has always been issue/comment ownership[*]. This is because
many systems want a login-capable, verified user for every single
person that have ever made an issue or comment. If there is no 1-to-1
mapping, the issue/comment is often owned by the importing user, and
the username/email of the original contributor is mangled into the
issue/comment-text itself.

This looks so nice for an issue with 50+ different contributors when
wind up being owned by the same user. Robert explains to Robert that
Robert's patch won't work with Roberts latest PR because Robert pulled
the wrong commit that Robert made to update the dependencies that
Robert discovered needed to be updated because Robert found a security
flaw, with apologies to Robert. There's usually no way to search for
the actual contributors either. It is as if importing to such
issue-systems are an after thought. Starting out with a design where
user and contributor are two different but potentially linked objects
would have solved the problem *correctly*.


[*] There are no doubt problems other than this, it's just the one
that bugs me the most. Especially since the solution so often is "Drop
all history, start from scratch."

-- 
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/CACQ%3DrreeXWcVCjxZGG18GDeeh98P_OxresAm9w_JrN0HSOQNhg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Tom Forbes]

> The only reason Github issues would be a consideration is if the group
thought the onboarding experience (being where users already are with a
tool they're already familiar with) would have more value than sticking
with with the status quo which is strictly better from a feature
perspective than GH Issues

I really think it's worth considering - I'm not convinced Trac is strictly
better from a feature perspective. Things like the dashboards are
interesting, sure, but what does it do that Github issues don't? And by
this I don't mean features that exist but we don't use, I mean our general
ticket workflow that 99% of contributors are exposed to. There are far
larger projects than Django currently using Github issues successfully and
they have a far more complex workflow including CLA's, high-granularity
tags, automatic reviewer selection, automatic closing, etc etc.

The cost of a migration would not be cheap, but is it worth doing a formal
evaluation and consider it? The "why Github section" (
https://www.python.org/dev/peps/pep-0581/#why-github) in that PEP lists
some good reasons that apply to us as well. The key one for me is lowering
the barrier to entry which I think we should be aiming towards. If we are
looking to expand the development group and get more people onboard we may
need to shake things up, as the status quo is problematic in that area.

On 11 December 2018 at 12:04:32, Josh Smeaton (josh.smea...@gmail.com)
wrote:

I don't think something like Jira would even be a consideration.

The only reason Github issues would be a consideration is if the group
thought the onboarding experience (being where users already are with a
tool they're already familiar with) would have more value than sticking
with with the status quo which is strictly better from a feature
perspective than GH Issues. Incrementally improving Trac can improve the
value prop for not changing, but I don't think anyone that actually uses
Trac would say it's worse from a feature perspective. Even if that value
judgement did land on GH issues side, there would still be a large
operational undertaking to make that transition.

Again, the PEP for doing this for CPython would be very similar for Django,
so please refer to https://www.python.org/dev/peps/pep-0581/ for some
examples of why and what operational concerns there can be (migration,
permissions, etc).

On Tuesday, 11 December 2018 07:26:58 UTC+11, Ira Abbott wrote:
>
> Apologies for the double post - my last one was not clear.  "just that"
> means that the payment is intended to indicate that it is worth a JIRA
> license to me to not use JIRA.
>
> This group does great things.  I am sure that the group can come up with
> some interesting ways to scale that will ultimately benefit the framework
> as a whole.
>
> On Monday, December 10, 2018 at 3:21:53 PM UTC-5, Ira Abbott wrote:
>>
>> FWIW: Please consider my contribution of $84 (one bulk JIRA license for
>> one year) to be just that.
>>
>> On Monday, December 10, 2018 at 2:14:07 PM UTC-5, Zachary Garwood wrote:
>>>
>>> I'd pay money to NOT use Jira.
>>>
>>> On Mon, Dec 10, 2018, 11:09 AM Dan Davis >>
 Tom, you are right about the UX issues, but full-text and inverted
 indexing would help with the responsiveness as well.  Technically, I was
 talking about djangoproject's TracSearch
 .  That's closer to good UX as
 well, because you can get there by progressive enhancement rather than
 taking stuff away.

 You are also right that switching to another system such as github
 issues could be a better fix than customizing Trac.   But I find it
 difficult to believe that Github issues grows up to cover as much workflow
 management as Trac issues or JIRA.   Maybe we need money to get JIRA.


 --
 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 post to this group, send email to django-d...@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/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%
 3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>> --
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 dja

Re: Widening participation (Thoughts from DjangoCon)

[Josh Smeaton]

I don't think something like Jira would even be a consideration. 

The only reason Github issues would be a consideration is if the group 
thought the onboarding experience (being where users already are with a 
tool they're already familiar with) would have more value than sticking 
with with the status quo which is strictly better from a feature 
perspective than GH Issues. Incrementally improving Trac can improve the 
value prop for not changing, but I don't think anyone that actually uses 
Trac would say it's worse from a feature perspective. Even if that value 
judgement did land on GH issues side, there would still be a large 
operational undertaking to make that transition. 

Again, the PEP for doing this for CPython would be very similar for Django, 
so please refer to https://www.python.org/dev/peps/pep-0581/ for some 
examples of why and what operational concerns there can be (migration, 
permissions, etc).

On Tuesday, 11 December 2018 07:26:58 UTC+11, Ira Abbott wrote:
>
> Apologies for the double post - my last one was not clear.  "just that" 
> means that the payment is intended to indicate that it is worth a JIRA 
> license to me to not use JIRA.
>
> This group does great things.  I am sure that the group can come up with 
> some interesting ways to scale that will ultimately benefit the framework 
> as a whole.
>
> On Monday, December 10, 2018 at 3:21:53 PM UTC-5, Ira Abbott wrote:
>>
>> FWIW: Please consider my contribution of $84 (one bulk JIRA license for 
>> one year) to be just that.
>>
>> On Monday, December 10, 2018 at 2:14:07 PM UTC-5, Zachary Garwood wrote:
>>>
>>> I'd pay money to NOT use Jira.
>>>
>>> On Mon, Dec 10, 2018, 11:09 AM Dan Davis >>
 Tom, you are right about the UX issues, but full-text and inverted 
 indexing would help with the responsiveness as well.  Technically, I was 
 talking about djangoproject's TracSearch 
 .  That's closer to good UX as 
 well, because you can get there by progressive enhancement rather than 
 taking stuff away.

 You are also right that switching to another system such as github 
 issues could be a better fix than customizing Trac.   But I find it 
 difficult to believe that Github issues grows up to cover as much workflow 
 management as Trac issues or JIRA.   Maybe we need money to get JIRA.


 -- 
 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 post to this group, send email to django-d...@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/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>

-- 
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/127550d4-b2dd-4ad7-8e6e-b56a66080194%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Ira Abbott]

Apologies for the double post - my last one was not clear.  "just that" 
means that the payment is intended to indicate that it is worth a JIRA 
license to me to not use JIRA.

This group does great things.  I am sure that the group can come up with 
some interesting ways to scale that will ultimately benefit the framework 
as a whole.

On Monday, December 10, 2018 at 3:21:53 PM UTC-5, Ira Abbott wrote:
>
> FWIW: Please consider my contribution of $84 (one bulk JIRA license for 
> one year) to be just that.
>
> On Monday, December 10, 2018 at 2:14:07 PM UTC-5, Zachary Garwood wrote:
>>
>> I'd pay money to NOT use Jira.
>>
>> On Mon, Dec 10, 2018, 11:09 AM Dan Davis >
>>> Tom, you are right about the UX issues, but full-text and inverted 
>>> indexing would help with the responsiveness as well.  Technically, I was 
>>> talking about djangoproject's TracSearch 
>>> .  That's closer to good UX as 
>>> well, because you can get there by progressive enhancement rather than 
>>> taking stuff away.
>>>
>>> You are also right that switching to another system such as github 
>>> issues could be a better fix than customizing Trac.   But I find it 
>>> difficult to believe that Github issues grows up to cover as much workflow 
>>> management as Trac issues or JIRA.   Maybe we need money to get JIRA.
>>>
>>>
>>> -- 
>>> 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 post to this group, send email to django-d...@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/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
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/7dad5740-60a2-4cfc-a1be-b913c318ff48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Ira Abbott]

FWIW: Please consider my contribution of $84 (one bulk JIRA license for one 
year) to be just that.

On Monday, December 10, 2018 at 2:14:07 PM UTC-5, Zachary Garwood wrote:
>
> I'd pay money to NOT use Jira.
>
> On Mon, Dec 10, 2018, 11:09 AM Dan Davis  
> wrote:
>
>> Tom, you are right about the UX issues, but full-text and inverted 
>> indexing would help with the responsiveness as well.  Technically, I was 
>> talking about djangoproject's TracSearch 
>> .  That's closer to good UX as 
>> well, because you can get there by progressive enhancement rather than 
>> taking stuff away.
>>
>> You are also right that switching to another system such as github issues 
>> could be a better fix than customizing Trac.   But I find it difficult to 
>> believe that Github issues grows up to cover as much workflow management as 
>> Trac issues or JIRA.   Maybe we need money to get JIRA.
>>
>>
>> -- 
>> 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 post to this group, send email to django-d...@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/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/0ff6066a-6425-40a2-8e15-74fd98e2f440%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Ira Abbott]

This project probably qualifies here:

https://www.atlassian.com/software/views/open-source-license-request


On Monday, December 10, 2018 at 2:05:40 PM UTC-5, Ira Abbott wrote:
>
> Hi,
>
> Just in case that JIRA crack was NOT sarcasm ...
>
> https://www.atlassian.com/software/jira/pricing  How many users would be 
> needed?  If going this way, I smell the need for a gateway / JIRA backend 
> for the community site and small number of actual JIRA users with the 
> creation coming from a single user with some sort of 'community-user' data 
> field patched in.  JIRA is certainly flexible and configurable this way and 
> capable of interface to other enterprise apps.  We would have to find out 
> how to make this work within their terms of service ...
>
> Otherwise, its probably "BYOL" for contributors at about <$7 / month.  
> i.e. possibly "$7/month for each month active", though I think they will 
> change for a constant number, which means managing floaters.  While new to 
> this community, I suspect that any other arrangement than these two is 
> prohibitive.  And even managing floaters for anyone not locked in by 
> commitment (contract) to the group adds risk to the group from the whatever 
> commitment exists with Atlassian for any fixed number.  This could 
> potentially bankrupt the group if not managed correctly.
>
> My other advice is to "KISS" when using JIRA.  All that configuration can 
> lead to a tendency for organizations to attempt to solve all of their 
> problems building workflows there.  This is VERY STICKY, hence the behemoth 
> that Atlassian has become and will continue to be for some time in to the 
> future.
>
> Finally, any major changes such as this are like an a manufacturing 
> organization changing ERP packages (been through several of those) - they 
> NEVER GO WELL, and inevitably, when the smoke clears users will long for 
> the old system despite its glaring deficiencies.
>
> I therefore will hold that improvements should be made to Trac in an 
> incremental Agile fashion rather than any conversion requiring a waterfall 
> rollout.  This is the part where Trac should be STICKY for the group, or 
> this will be disruptive.
>
> And besides, I like Python in general and don't to fall victim to 'pay to 
> play' to Atlassian / Oracle to develop open source software that, believe 
> me, refers everything Python as 'a bunch of scripts'.  I get enough of that 
> at work which is part of why I am here.
>
> Regards,
>
> Ira
>
> On Monday, December 10, 2018 at 12:10:05 PM UTC-5, Dan Davis wrote:
>>
>> Tom, you are right about the UX issues, but full-text and inverted 
>> indexing would help with the responsiveness as well.  Technically, I was 
>> talking about djangoproject's TracSearch 
>> .  That's closer to good UX as 
>> well, because you can get there by progressive enhancement rather than 
>> taking stuff away.
>>
>> You are also right that switching to another system such as github issues 
>> could be a better fix than customizing Trac.   But I find it difficult to 
>> believe that Github issues grows up to cover as much workflow management as 
>> Trac issues or JIRA.   Maybe we need money to get JIRA.
>>
>>
>>

-- 
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/a3427014-90ef-4219-9a11-7d7ba86547f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Zach Garwood]

I'd pay money to NOT use Jira.

On Mon, Dec 10, 2018, 11:09 AM Dan Davis  Tom, you are right about the UX issues, but full-text and inverted
> indexing would help with the responsiveness as well.  Technically, I was
> talking about djangoproject's TracSearch
> .  That's closer to good UX as
> well, because you can get there by progressive enhancement rather than
> taking stuff away.
>
> You are also right that switching to another system such as github issues
> could be a better fix than customizing Trac.   But I find it difficult to
> believe that Github issues grows up to cover as much workflow management as
> Trac issues or JIRA.   Maybe we need money to get JIRA.
>
>
> --
> 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/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAA-b4CjD0WY0fy2_QVoMkRGzZKAi%3DUE%3DA6N7oR0u-WECoKoJkQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Ira Abbott]

Hi,

Just in case that JIRA crack was NOT sarcasm ...

https://www.atlassian.com/software/jira/pricing  How many users would be 
needed?  If going this way, I smell the need for a gateway / JIRA backend 
for the community site and small number of actual JIRA users with the 
creation coming from a single user with some sort of 'community-user' data 
field patched in.  JIRA is certainly flexible and configurable this way and 
capable of interface to other enterprise apps.  We would have to find out 
how to make this work within their terms of service ...

Otherwise, its probably "BYOL" for contributors at about <$7 / month.  i.e. 
possibly "$7/month for each month active", though I think they will change 
for a constant number, which means managing floaters.  While new to this 
community, I suspect that any other arrangement than these two is 
prohibitive.  And even managing floaters for anyone not locked in by 
commitment (contract) to the group adds risk to the group from the whatever 
commitment exists with Atlassian for any fixed number.  This could 
potentially bankrupt the group if not managed correctly.

My other advice is to "KISS" when using JIRA.  All that configuration can 
lead to a tendency for organizations to attempt to solve all of their 
problems building workflows there.  This is VERY STICKY, hence the behemoth 
that Atlassian has become and will continue to be for some time in to the 
future.

Finally, any major changes such as this are like an a manufacturing 
organization changing ERP packages (been through several of those) - they 
NEVER GO WELL, and inevitably, when the smoke clears users will long for 
the old system despite its glaring deficiencies.

I therefore will hold that improvements should be made to Trac in an 
incremental Agile fashion rather than any conversion requiring a waterfall 
rollout.  This is the part where Trac should be STICKY for the group, or 
this will be disruptive.

And besides, I like Python in general and don't to fall victim to 'pay to 
play' to Atlassian / Oracle to develop open source software that, believe 
me, refers everything Python as 'a bunch of scripts'.  I get enough of that 
at work which is part of why I am here.

Regards,

Ira

On Monday, December 10, 2018 at 12:10:05 PM UTC-5, Dan Davis wrote:
>
> Tom, you are right about the UX issues, but full-text and inverted 
> indexing would help with the responsiveness as well.  Technically, I was 
> talking about djangoproject's TracSearch 
> .  That's closer to good UX as 
> well, because you can get there by progressive enhancement rather than 
> taking stuff away.
>
> You are also right that switching to another system such as github issues 
> could be a better fix than customizing Trac.   But I find it difficult to 
> believe that Github issues grows up to cover as much workflow management as 
> Trac issues or JIRA.   Maybe we need money to get JIRA.
>
>
>

-- 
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/c5b4316c-7381-46bb-aba9-535147bccc66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Dan Davis]

And there might be no need to develop code for this, only configuration:
https://github.com/dnephin/TracAdvancedSearchPlugin


On Mon, Dec 10, 2018 at 11:22 AM Dan Davis  wrote:

> I think that TracSearch could use improvement.   As an expert in
> Information Retrieval, I would be happy to help with this.   The particular
> suggestions I have:
>
>
>- Provide quick filters (e.g. facets) after a search is done based on
>ticket keywords, stage, and whether a result is a ticket, wiki, milestone,
>etc.
>- Use a Solr/Elasticsearch inverted index for better word
>segmentation, automated phrase and field boosting, etc.
>
> A search system such as TracSearch is biased towards "Recall", e.g. find
> all relevant tickets, rather than "Precision", e.g. show me only relevant
> results, and only the most relevant results.   The limits on word
> segmentation provided by RDBMS-backed full-text search often makes both
> recall and precision worse.
>
>
> On Mon, Dec 10, 2018 at 11:14 AM Dan Davis  wrote:
>
>> > I strongly dislike Trac in nearly every way. It's hard to search and
>> the filters are next to useless, and the categorisation features we use are
>> not very useful.
>> > I believe the better way to search Trac is to use google and site:
>> code.djangoproject.com which is a red flag itself.
>>
>> Is there a separate list for the infrastructure team where we could
>> continue this discussion?   I feel sure that using a better indexing plugin
>> for Trac could improve the problem.
>>
>>
>> On Sun, Oct 28, 2018 at 6:04 PM Josh Smeaton 
>> wrote:
>>
>>> I strongly dislike Trac in nearly every way. It's hard to search and the
>>> filters are next to useless, and the categorisation features we use are not
>>> very useful. I believe the better way to search Trac is to use google and
>>> site:code.djangoproject.com which is a red flag itself.
>>>
>>> On Saturday, 27 October 2018 11:09:38 UTC+11, Tom Forbes wrote:

 How much of this would you attribute to the current ticketing system
 itself, rather than tickets being tagged appropriately?

 I know when I started contributing I found trac to be pretty
 intimidating in terms of complexity, especially the search. I still prefer
 to use the 'Search Trac' field in the root code.djangoproject.com page
 than fiddle with the myriad of options and drop downs in the browse tickets
 section.

 If we think of getting new people onboard as a conversion funnel we
 need to stop dropoff as much as possible, and that extends to the UI of the
 ticket tracker as well I believe.

 Tom

 On Fri, 26 Oct 2018, 22:43 Ian Foote,  wrote:

> Hi Carlton,
>
> I've had similar thoughts sitting in the back of my mind for at least
> a couple of months, so thank you for sharing this. I agree that finding
> tickets is one of the big problems here, both for new contributors and for
> sprint leaders. At Pycon UK I took on the role of sprint leader along with
> Adam Johnson and directing people to appropriate tickets was a definite
> difficulty. I was also unaware of the django core mentorship list and will
> be joining that soon. I'm willing to spend some time mentoring a small
> number of people, life permitting.
>
> Ian
>
> On Fri, 26 Oct 2018 at 14:44, Carlton Gibson 
> wrote:
>
>> 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
>> 
>> DSF list and the proposal to dissolve Django Core
>> . (Can’t see the DSF list? Join
>> the DSF
>> 
>> .)
>> 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*
>> 
>> 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

Re: Widening participation (Thoughts from DjangoCon)

[Dan Davis]

I think that TracSearch could use improvement.   As an expert in
Information Retrieval, I would be happy to help with this.   The particular
suggestions I have:


   - Provide quick filters (e.g. facets) after a search is done based on
   ticket keywords, stage, and whether a result is a ticket, wiki, milestone,
   etc.
   - Use a Solr/Elasticsearch inverted index for better word segmentation,
   automated phrase and field boosting, etc.

A search system such as TracSearch is biased towards "Recall", e.g. find
all relevant tickets, rather than "Precision", e.g. show me only relevant
results, and only the most relevant results.   The limits on word
segmentation provided by RDBMS-backed full-text search often makes both
recall and precision worse.


On Mon, Dec 10, 2018 at 11:14 AM Dan Davis  wrote:

> > I strongly dislike Trac in nearly every way. It's hard to search and the
> filters are next to useless, and the categorisation features we use are not
> very useful.
> > I believe the better way to search Trac is to use google and site:
> code.djangoproject.com which is a red flag itself.
>
> Is there a separate list for the infrastructure team where we could
> continue this discussion?   I feel sure that using a better indexing plugin
> for Trac could improve the problem.
>
>
> On Sun, Oct 28, 2018 at 6:04 PM Josh Smeaton 
> wrote:
>
>> I strongly dislike Trac in nearly every way. It's hard to search and the
>> filters are next to useless, and the categorisation features we use are not
>> very useful. I believe the better way to search Trac is to use google and
>> site:code.djangoproject.com which is a red flag itself.
>>
>> On Saturday, 27 October 2018 11:09:38 UTC+11, Tom Forbes wrote:
>>>
>>> How much of this would you attribute to the current ticketing system
>>> itself, rather than tickets being tagged appropriately?
>>>
>>> I know when I started contributing I found trac to be pretty
>>> intimidating in terms of complexity, especially the search. I still prefer
>>> to use the 'Search Trac' field in the root code.djangoproject.com page
>>> than fiddle with the myriad of options and drop downs in the browse tickets
>>> section.
>>>
>>> If we think of getting new people onboard as a conversion funnel we need
>>> to stop dropoff as much as possible, and that extends to the UI of the
>>> ticket tracker as well I believe.
>>>
>>> Tom
>>>
>>> On Fri, 26 Oct 2018, 22:43 Ian Foote,  wrote:
>>>
 Hi Carlton,

 I've had similar thoughts sitting in the back of my mind for at least a
 couple of months, so thank you for sharing this. I agree that finding
 tickets is one of the big problems here, both for new contributors and for
 sprint leaders. At Pycon UK I took on the role of sprint leader along with
 Adam Johnson and directing people to appropriate tickets was a definite
 difficulty. I was also unaware of the django core mentorship list and will
 be joining that soon. I'm willing to spend some time mentoring a small
 number of people, life permitting.

 Ian

 On Fri, 26 Oct 2018 at 14:44, Carlton Gibson 
 wrote:

> 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
> 
> DSF list and the proposal to dissolve Django Core
> . (Can’t see the DSF list? Join
> the DSF
> 
> .)
> 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*
> 
> 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 
> .
>
> This must be

Re: Widening participation (Thoughts from DjangoCon)

[Dan Davis]

> I strongly dislike Trac in nearly every way. It's hard to search and the
filters are next to useless, and the categorisation features we use are not
very useful.
> I believe the better way to search Trac is to use google and site:
code.djangoproject.com which is a red flag itself.

Is there a separate list for the infrastructure team where we could
continue this discussion?   I feel sure that using a better indexing plugin
for Trac could improve the problem.


On Sun, Oct 28, 2018 at 6:04 PM Josh Smeaton  wrote:

> I strongly dislike Trac in nearly every way. It's hard to search and the
> filters are next to useless, and the categorisation features we use are not
> very useful. I believe the better way to search Trac is to use google and
> site:code.djangoproject.com which is a red flag itself.
>
> On Saturday, 27 October 2018 11:09:38 UTC+11, Tom Forbes wrote:
>>
>> How much of this would you attribute to the current ticketing system
>> itself, rather than tickets being tagged appropriately?
>>
>> I know when I started contributing I found trac to be pretty intimidating
>> in terms of complexity, especially the search. I still prefer to use the
>> 'Search Trac' field in the root code.djangoproject.com page than fiddle
>> with the myriad of options and drop downs in the browse tickets section.
>>
>> If we think of getting new people onboard as a conversion funnel we need
>> to stop dropoff as much as possible, and that extends to the UI of the
>> ticket tracker as well I believe.
>>
>> Tom
>>
>> On Fri, 26 Oct 2018, 22:43 Ian Foote,  wrote:
>>
>>> Hi Carlton,
>>>
>>> I've had similar thoughts sitting in the back of my mind for at least a
>>> couple of months, so thank you for sharing this. I agree that finding
>>> tickets is one of the big problems here, both for new contributors and for
>>> sprint leaders. At Pycon UK I took on the role of sprint leader along with
>>> Adam Johnson and directing people to appropriate tickets was a definite
>>> difficulty. I was also unaware of the django core mentorship list and will
>>> be joining that soon. I'm willing to spend some time mentoring a small
>>> number of people, life permitting.
>>>
>>> Ian
>>>
>>> On Fri, 26 Oct 2018 at 14:44, Carlton Gibson 
>>> wrote:
>>>
 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
 
 DSF list and the proposal to dissolve Django Core
 . (Can’t see the DSF list? Join
 the DSF
 
 .)
 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*
 
 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 .

 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 com

Re: Widening participation (Thoughts from DjangoCon)

[Ira Abbott]

Hi,

>From the perspective of someone who just joined the group, I am glad to see 
that I was not alone not immediately finding the correct path or 
participation.  I am, however grateful that the community appears to have 
the introspection and means of moving it forward.

Being new, I am curious about "the demographic".  Could you explain?  I 
will use this as an excuse to go slightly off topic, but bring it around.

I will freely share that while I suspect I may fit some portion (male?), I 
may be skewed toward the older end (could be wrong ...)

Hint: RPG meant "Rocket Propelled Grenade" before it meant "Role Playing 
Game", and when I started playing RPGs I did so with dice and dreams of 
programming enough BASIC on my Atari cartridge computer with keyboard and 
cassette tape backup to assist in the Dice role and table lookup.  Of 
course, everyone told me that would go nowhere ...  Therefore, I obtained a 
degree in Electrical Engineering and proceeded to develop hardware and 
software in a variety of forms and using a variety of tools to this day.  I 
currently work for Imagine Communications which uses django sparsely and 
not in anything I do directly.  In fact, python itself is a rather poor 
stepchild there, but that is another story.  I love python and django - I 
feel like that kid writing BASIC again.

So my "demographic" is "newb: old fart with a bit of chip on his shoulder 
because he really does have some reasonable industry bona fides" - I have 
coworkers who have and do participate in the defined television standards 
such as HD terrestrial broadcast ("Grand Alliance") and play key roles in 
the development of a variety of SMPTE standards (of which I am a member).

Anyhow, I'm game to play to catch up and improve on my skills and maybe 
give something back if I can.

This is why I joined to share the "let's not splat because two apps use 
different SITE_ID" bit which has been causing me dig in and figure out why 
some things just don't seem to go together as an excuse to test the 
waters.  I've been going to the source rather than googling more and more.  
I don't find it all that terribly daunting and inserting a few log 
statements seems to unravel most mysteries (thanks folks that work with 
logging).  

If you find me to be a suitable test subject, I will volunteer say "Squeek" 
(i.e. consider me "available" to be a guinea pig for experimentation 
purposes).

Regardless, I am set to see how the community reacts to an minor 
improvement suggestion intended to cause no harm and possibly make a few 
lives easier with a change of a small number of lines of code.

Thanks again to everyone who past and present who has worked to make this 
framework available.  It has provided endless hours of fascination, 
excitement, and, at times , frustration. You don't develop software without 
some of the later, its the level of the former that keeps me coming back. 
Cudos.

Regards,

Ira


On Friday, October 26, 2018 at 9:44:54 AM UTC-4, Carlton Gibson wrote:
>
> 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 
>  
> DSF list and the proposal to dissolve Django Core 
> . (Can’t see the DSF list? Join 
> the DSF 
> 
> .)
> 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* 
>  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 . 
>
> 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

Re: Widening participation (Thoughts from DjangoCon)

[Jason Johns]

This is prompted by James Bennet's article yesterday 
 which prompted a 
discussion with a coworker of mine.

I've been using django for a while now, am a mid-level at a company that 
uses django/DRF heavily, and am a regular lurker here because its a great 
way to keep up with the happenings of the project.  That said, this is from 
an outsiders perspective:


   1. The documentation of the framework is top notch, but the sections on 
   contributing and getting up to speed with the framework, how to run it 
   while developing on it, etc are sparse.  The codebase is fairly 
   intimidating when you read a ticket and then try to dig in.  Fortunately, 
   all breakage from my experimentation is private and not public :-).  I feel 
   having a much more thorough documentation/examples of ramping up and 
   getting started would do a great job in reducing some of that intimidation 
   factor.
   2. The fellows, Tim and Carlton, do a great job here in triaging tickets 
   and handling the day to day work of the project.  But I feel the bug 
   tracker is being a significant hindrance to contributors and possible 
   contributors, and when combined with a lack of intuitive methods to find 
   easy picking tickets makes it more difficult to get going from scratch.  I 
   imagine this is something that has been discussed before.
   3. I like the idea James proposed about mergers and releasers.  I would 
   also suggest that mergers be people who have significant experience in 
   specific parts of Django and handle merging of those tickets.  This is 
   similar to how the Linux kernel project is set up, with maintainers 
   responsible for specific segments of the code tree.  It would also be great 
   if these mergers had technical team-lead like skills that can be used to 
   shepherd both new and knowledgeable contributors onward and upward with 
   tickets, knowledge and support.

I personally am going to make more of an effort to get more involved here, 
but I think these three points above would help lower the mental resistance 
of someone that wants to enter the project.  I have to wonder, however, how 
well situated the experienced people here are for spending time getting new 
contributors up to speed.  Onboarding a new developer is a major time 
allocation at companies, much less open source projects that are being 
worked on in ocassional company time/spare time across the world.  What's 
the capacity available, and who is available for what kind of questions?  

-- 
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/6a80dbf4-dcc5-40dc-bca8-11cdcc6e7ab8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Widening participation (Thoughts from DjangoCon)

[Dan Davis]

Trac can be made easier to search with Apache Solr 
- 
https://www.pycon.it/conference/talks/full-text-search-for-trac-with-apache-solr

On Sunday, October 28, 2018 at 6:04:12 PM UTC-4, Josh Smeaton wrote:
>
> I strongly dislike Trac in nearly every way. It's hard to search and the 
> filters are next to useless, and the categorisation features we use are not 
> very useful. I believe the better way to search Trac is to use google and 
> site:code.djangoproject.com which is a red flag itself.
>
> On Saturday, 27 October 2018 11:09:38 UTC+11, Tom Forbes wrote:
>>
>> How much of this would you attribute to the current ticketing system 
>> itself, rather than tickets being tagged appropriately?
>>
>> I know when I started contributing I found trac to be pretty intimidating 
>> in terms of complexity, especially the search. I still prefer to use the 
>> 'Search Trac' field in the root code.djangoproject.com page than fiddle 
>> with the myriad of options and drop downs in the browse tickets section.
>>
>> If we think of getting new people onboard as a conversion funnel we need 
>> to stop dropoff as much as possible, and that extends to the UI of the 
>> ticket tracker as well I believe.
>>
>> Tom
>>
>> On Fri, 26 Oct 2018, 22:43 Ian Foote,  wrote:
>>
>>> Hi Carlton,
>>>
>>> I've had similar thoughts sitting in the back of my mind for at least a 
>>> couple of months, so thank you for sharing this. I agree that finding 
>>> tickets is one of the big problems here, both for new contributors and for 
>>> sprint leaders. At Pycon UK I took on the role of sprint leader along with 
>>> Adam Johnson and directing people to appropriate tickets was a definite 
>>> difficulty. I was also unaware of the django core mentorship list and will 
>>> be joining that soon. I'm willing to spend some time mentoring a small 
>>> number of people, life permitting.
>>>
>>> Ian
>>>
>>> On Fri, 26 Oct 2018 at 14:44, Carlton Gibson  
>>> wrote:
>>>
 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 
  
 DSF list and the proposal to dissolve Django Core 
 . (Can’t see the DSF list? Join 
 the DSF 
 
 .)
 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* 
  
 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 . 

 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

Re: Widening participation (Thoughts from DjangoCon)

[Josh Smeaton]

I strongly dislike Trac in nearly every way. It's hard to search and the 
filters are next to useless, and the categorisation features we use are not 
very useful. I believe the better way to search Trac is to use google and 
site:code.djangoproject.com which is a red flag itself.

On Saturday, 27 October 2018 11:09:38 UTC+11, Tom Forbes wrote:
>
> How much of this would you attribute to the current ticketing system 
> itself, rather than tickets being tagged appropriately?
>
> I know when I started contributing I found trac to be pretty intimidating 
> in terms of complexity, especially the search. I still prefer to use the 
> 'Search Trac' field in the root code.djangoproject.com page than fiddle 
> with the myriad of options and drop downs in the browse tickets section.
>
> If we think of getting new people onboard as a conversion funnel we need 
> to stop dropoff as much as possible, and that extends to the UI of the 
> ticket tracker as well I believe.
>
> Tom
>
> On Fri, 26 Oct 2018, 22:43 Ian Foote, > 
> wrote:
>
>> Hi Carlton,
>>
>> I've had similar thoughts sitting in the back of my mind for at least a 
>> couple of months, so thank you for sharing this. I agree that finding 
>> tickets is one of the big problems here, both for new contributors and for 
>> sprint leaders. At Pycon UK I took on the role of sprint leader along with 
>> Adam Johnson and directing people to appropriate tickets was a definite 
>> difficulty. I was also unaware of the django core mentorship list and will 
>> be joining that soon. I'm willing to spend some time mentoring a small 
>> number of people, life permitting.
>>
>> Ian
>>
>> On Fri, 26 Oct 2018 at 14:44, Carlton Gibson > > wrote:
>>
>>> 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 
>>>  
>>> DSF list and the proposal to dissolve Django Core 
>>> . (Can’t see the DSF list? Join 
>>> the DSF 
>>> 
>>> .)
>>> 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* 
>>>  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 . 
>>>
>>> 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.

Re: Widening participation (Thoughts from DjangoCon)

[Tom Forbes]

How much of this would you attribute to the current ticketing system
itself, rather than tickets being tagged appropriately?

I know when I started contributing I found trac to be pretty intimidating
in terms of complexity, especially the search. I still prefer to use the
'Search Trac' field in the root code.djangoproject.com page than fiddle
with the myriad of options and drop downs in the browse tickets section.

If we think of getting new people onboard as a conversion funnel we need to
stop dropoff as much as possible, and that extends to the UI of the ticket
tracker as well I believe.

Tom

On Fri, 26 Oct 2018, 22:43 Ian Foote,  wrote:

> Hi Carlton,
>
> I've had similar thoughts sitting in the back of my mind for at least a
> couple of months, so thank you for sharing this. I agree that finding
> tickets is one of the big problems here, both for new contributors and for
> sprint leaders. At Pycon UK I took on the role of sprint leader along with
> Adam Johnson and directing people to appropriate tickets was a definite
> difficulty. I was also unaware of the django core mentorship list and will
> be joining that soon. I'm willing to spend some time mentoring a small
> number of people, life permitting.
>
> Ian
>
> On Fri, 26 Oct 2018 at 14:44, Carlton Gibson 
> wrote:
>
>> 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
>> 
>> DSF list and the proposal to dissolve Django Core
>> . (Can’t see the DSF list? Join
>> the DSF
>> 
>> .)
>> 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*
>>  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 .
>>
>> 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 

Re: Widening participation (Thoughts from DjangoCon)

[Jeremy Dunck]

An alternative that might work well is to triage tickets to mentors, so
that a list of tickets with willing mentors is available.  It would feel
less judge-y than "easy pickings" and also broaden the pool of tickets that
could be worked by a newcomer.  Of course it hinges on a willing pool of
mentors and making the time needed to do the work.


On Fri, Oct 26, 2018 at 2:43 PM Ian Foote  wrote:

> Hi Carlton,
>
> I've had similar thoughts sitting in the back of my mind for at least a
> couple of months, so thank you for sharing this. I agree that finding
> tickets is one of the big problems here, both for new contributors and for
> sprint leaders. At Pycon UK I took on the role of sprint leader along with
> Adam Johnson and directing people to appropriate tickets was a definite
> difficulty. I was also unaware of the django core mentorship list and will
> be joining that soon. I'm willing to spend some time mentoring a small
> number of people, life permitting.
>
> Ian
>
> On Fri, 26 Oct 2018 at 14:44, Carlton Gibson 
> wrote:
>
>> 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
>> 
>> DSF list and the proposal to dissolve Django Core
>> . (Can’t see the DSF list? Join
>> the DSF
>> 
>> .)
>> 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*
>>  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 .
>>
>> 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
>> 

Re: Widening participation (Thoughts from DjangoCon)

[Ian Foote]

Hi Carlton,

I've had similar thoughts sitting in the back of my mind for at least a
couple of months, so thank you for sharing this. I agree that finding
tickets is one of the big problems here, both for new contributors and for
sprint leaders. At Pycon UK I took on the role of sprint leader along with
Adam Johnson and directing people to appropriate tickets was a definite
difficulty. I was also unaware of the django core mentorship list and will
be joining that soon. I'm willing to spend some time mentoring a small
number of people, life permitting.

Ian

On Fri, 26 Oct 2018 at 14:44, Carlton Gibson 
wrote:

> 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
> 
> DSF list and the proposal to dissolve Django Core
> . (Can’t see the DSF list? Join
> the DSF
> 
> .)
> 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*
>  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 .
>
> 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. B

Re: Widening participation (Thoughts from DjangoCon)

[Dan Davis]

Thanks.   Although I don't solve the demographic problem, I should respond
to the call for broader participation.  I should make myself put aside time
to contribute - and I should force my boss to let me ;)

On Fri, Oct 26, 2018 at 9:44 AM Carlton Gibson 
wrote:

> 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
> 
> DSF list and the proposal to dissolve Django Core
> . (Can’t see the DSF list? Join
> the DSF
> 
> .)
> 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*
>  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 .
>
> 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… —
>

Widening participation (Thoughts from DjangoCon)

[Carlton Gibson]

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 
 DSF 
list and the proposal to dissolve Django Core 
. (Can’t see the DSF list? Join the 
DSF 

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

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 w