Widening participation (Thoughts from DjangoCon)

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Widening participation (Thoughts from DjangoCon)

Carlton Gibson-3

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 with the on-ramp. Anything that smooths that is welcome. 

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

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

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


Kind Regards,

Carlton



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 can (say) filter tickets by component (and such) we’re were a way from this. 

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

And finally…

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

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

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

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


Kind Regards,

Carlton



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFzonYb72HZZRFc31C1%2BWWr755pVeQRDHgwhBj_BwR8Jm4heEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Widening participation (Thoughts from DjangoCon)

Ian Foote
In reply to this post by Carlton Gibson-3
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 <[hidden email]> 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 can (say) filter tickets by component (and such) we’re were a way from this. 

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

And finally…

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

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

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

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


Kind Regards,

Carlton



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFv-zf%2BvD7yg8-b6w8iG3J-NcE2q-oyfZLOtW3ZZhjo%3DTtLhxw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 can (say) filter tickets by component (and such) we’re were a way from this. 

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

And finally…

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

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

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

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


Kind Regards,

Carlton



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFv-zf%2BvD7yg8-b6w8iG3J-NcE2q-oyfZLOtW3ZZhjo%3DTtLhxw%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 [hidden email].
To post to this group, send email to [hidden email].
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/CAM0i3f6Md0rzjkPLPnMc4CVp%3DAHanxWZ%3D9ngGYqneSu4Nmejrg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Widening participation (Thoughts from DjangoCon)

Tom Forbes
In reply to this post by Ian Foote
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, <[hidden email]> 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 <[hidden email]> 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 can (say) filter tickets by component (and such) we’re were a way from this. 

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

And finally…

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

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

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

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


Kind Regards,

Carlton



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFv-zf%2BvD7yg8-b6w8iG3J-NcE2q-oyfZLOtW3ZZhjo%3DTtLhxw%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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFNZOJONgNVh0jH1p4jL4U8iBsdgXZ6LNw5Z0wTLKoZ2pEf5Uw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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 <a href="http://code.djangoproject.com" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fcode.djangoproject.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFaP1F0AlILoeI6uQV8rqu3oGIWfA&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fcode.djangoproject.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFaP1F0AlILoeI6uQV8rqu3oGIWfA&#39;;return true;">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, <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="7RhwjYMGCQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">i...@...> 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 <<a href="javascript:" rel="nofollow" target="_blank" gdf-obfuscated-mailto="7RhwjYMGCQAJ" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">carlton...@...> 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!") <a href="https://groups.google.com/d/topic/dsf-members/GWOzvsOAGUs/discussion" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/topic/dsf-members/GWOzvsOAGUs/discussion&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/topic/dsf-members/GWOzvsOAGUs/discussion&#39;;return true;">inspired by the discussion on the DSF list and <a href="https://github.com/django/deps/pull/47" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdeps%2Fpull%2F47\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGeT5VR_CUi1nvs-LKEXe5XmFsSwg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdeps%2Fpull%2F47\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGeT5VR_CUi1nvs-LKEXe5XmFsSwg&#39;;return true;">the proposal to dissolve Django Core(Can’t see the DSF list? <a href="https://docs.google.com/forms/d/e/1FAIpQLSd5lbWxAO-sylEEjHVKBNIpmHlhdJRf0_LCo8glnLUWd-Q2Sw/viewform" style="font-size:12px" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://docs.google.com/forms/d/e/1FAIpQLSd5lbWxAO-sylEEjHVKBNIpmHlhdJRf0_LCo8glnLUWd-Q2Sw/viewform&#39;;return true;" onclick="this.href=&#39;https://docs.google.com/forms/d/e/1FAIpQLSd5lbWxAO-sylEEjHVKBNIpmHlhdJRf0_LCo8glnLUWd-Q2Sw/viewform&#39;;return true;">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 <a href="https://docs.djangoproject.com/en/dev/internals/contributing/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2Fdev%2Finternals%2Fcontributing%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFrYEEUfSwSQKweDBRBqVQ-vLIHuQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2Fdev%2Finternals%2Fcontributing%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFrYEEUfSwSQKweDBRBqVQ-vLIHuQ&#39;;return true;">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 <a href="https://groups.google.com/forum/#!forum/django-core-mentorship" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/forum/#!forum/django-core-mentorship&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/forum/#!forum/django-core-mentorship&#39;;return true;">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 with the on-ramp. Anything that smooths that is welcome. 

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

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

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


Kind Regards,

Carlton



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" rel="nofollow" target="_blank" gdf-obfuscated-mailto="7RhwjYMGCQAJ" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-develop...@googlegroups.com.
To post to this group, send email to <a href="javascript:" rel="nofollow" target="_blank" gdf-obfuscated-mailto="7RhwjYMGCQAJ" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 <a href="javascript:" rel="nofollow" target="_blank" gdf-obfuscated-mailto="7RhwjYMGCQAJ" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-develop...@googlegroups.com.
To post to this group, send email to <a href="javascript:" rel="nofollow" target="_blank" gdf-obfuscated-mailto="7RhwjYMGCQAJ" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CAFv-zf%2BvD7yg8-b6w8iG3J-NcE2q-oyfZLOtW3ZZhjo%3DTtLhxw%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAFv-zf%2BvD7yg8-b6w8iG3J-NcE2q-oyfZLOtW3ZZhjo%3DTtLhxw%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAFv-zf%2BvD7yg8-b6w8iG3J-NcE2q-oyfZLOtW3ZZhjo%3DTtLhxw%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CAFv-zf%2BvD7yg8-b6w8iG3J-NcE2q-oyfZLOtW3ZZhjo%3DTtLhxw%40mail.gmail.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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/c9a069c8-44b3-4feb-a873-6ac4f8afaac9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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:<a href="http://code.djangoproject.com" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fcode.djangoproject.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFaP1F0AlILoeI6uQV8rqu3oGIWfA&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fcode.djangoproject.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFaP1F0AlILoeI6uQV8rqu3oGIWfA&#39;;return true;">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 <a href="http://code.djangoproject.com" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fcode.djangoproject.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFaP1F0AlILoeI6uQV8rqu3oGIWfA&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fcode.djangoproject.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFaP1F0AlILoeI6uQV8rqu3oGIWfA&#39;;return true;">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, <[hidden email]> 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 <[hidden email]> 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!") <a href="https://groups.google.com/d/topic/dsf-members/GWOzvsOAGUs/discussion" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/topic/dsf-members/GWOzvsOAGUs/discussion&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/topic/dsf-members/GWOzvsOAGUs/discussion&#39;;return true;">inspired by the discussion on the DSF list and <a href="https://github.com/django/deps/pull/47" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdeps%2Fpull%2F47\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGeT5VR_CUi1nvs-LKEXe5XmFsSwg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdeps%2Fpull%2F47\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGeT5VR_CUi1nvs-LKEXe5XmFsSwg&#39;;return true;">the proposal to dissolve Django Core(Can’t see the DSF list? <a href="https://docs.google.com/forms/d/e/1FAIpQLSd5lbWxAO-sylEEjHVKBNIpmHlhdJRf0_LCo8glnLUWd-Q2Sw/viewform" style="font-size:12px" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://docs.google.com/forms/d/e/1FAIpQLSd5lbWxAO-sylEEjHVKBNIpmHlhdJRf0_LCo8glnLUWd-Q2Sw/viewform&#39;;return true;" onclick="this.href=&#39;https://docs.google.com/forms/d/e/1FAIpQLSd5lbWxAO-sylEEjHVKBNIpmHlhdJRf0_LCo8glnLUWd-Q2Sw/viewform&#39;;return true;">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 <a href="https://docs.djangoproject.com/en/dev/internals/contributing/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2Fdev%2Finternals%2Fcontributing%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFrYEEUfSwSQKweDBRBqVQ-vLIHuQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2Fdev%2Finternals%2Fcontributing%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFrYEEUfSwSQKweDBRBqVQ-vLIHuQ&#39;;return true;">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 <a href="https://groups.google.com/forum/#!forum/django-core-mentorship" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/forum/#!forum/django-core-mentorship&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/forum/#!forum/django-core-mentorship&#39;;return true;">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 with the on-ramp. Anything that smooths that is welcome. 

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

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

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


Kind Regards,

Carlton



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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-develop...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CAFv-zf%2BvD7yg8-b6w8iG3J-NcE2q-oyfZLOtW3ZZhjo%3DTtLhxw%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAFv-zf%2BvD7yg8-b6w8iG3J-NcE2q-oyfZLOtW3ZZhjo%3DTtLhxw%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAFv-zf%2BvD7yg8-b6w8iG3J-NcE2q-oyfZLOtW3ZZhjo%3DTtLhxw%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CAFv-zf%2BvD7yg8-b6w8iG3J-NcE2q-oyfZLOtW3ZZhjo%3DTtLhxw%40mail.gmail.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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/5eb4bad7-82a7-485a-a669-08c8e9119101%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: Widening participation (Thoughts from DjangoCon)

Ira Abbott
In reply to this post by Carlton Gibson-3
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!") <a href="https://groups.google.com/d/topic/dsf-members/GWOzvsOAGUs/discussion" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/topic/dsf-members/GWOzvsOAGUs/discussion&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/topic/dsf-members/GWOzvsOAGUs/discussion&#39;;return true;">inspired by the discussion on the DSF list and <a href="https://github.com/django/deps/pull/47" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdeps%2Fpull%2F47\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGeT5VR_CUi1nvs-LKEXe5XmFsSwg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fdjango%2Fdeps%2Fpull%2F47\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGeT5VR_CUi1nvs-LKEXe5XmFsSwg&#39;;return true;">the proposal to dissolve Django Core(Can’t see the DSF list? <a href="https://docs.google.com/forms/d/e/1FAIpQLSd5lbWxAO-sylEEjHVKBNIpmHlhdJRf0_LCo8glnLUWd-Q2Sw/viewform" style="font-size:12px" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://docs.google.com/forms/d/e/1FAIpQLSd5lbWxAO-sylEEjHVKBNIpmHlhdJRf0_LCo8glnLUWd-Q2Sw/viewform&#39;;return true;" onclick="this.href=&#39;https://docs.google.com/forms/d/e/1FAIpQLSd5lbWxAO-sylEEjHVKBNIpmHlhdJRf0_LCo8glnLUWd-Q2Sw/viewform&#39;;return true;">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 <a href="https://docs.djangoproject.com/en/dev/internals/contributing/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2Fdev%2Finternals%2Fcontributing%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFrYEEUfSwSQKweDBRBqVQ-vLIHuQ&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2Fdev%2Finternals%2Fcontributing%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFrYEEUfSwSQKweDBRBqVQ-vLIHuQ&#39;;return true;">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 <a href="https://groups.google.com/forum/#!forum/django-core-mentorship" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/forum/#!forum/django-core-mentorship&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/forum/#!forum/django-core-mentorship&#39;;return true;">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 with the on-ramp. Anything that smooths that is welcome. 

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

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

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


Kind Regards,

Carlton



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
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/223fcf75-5db9-4027-bfe2-f3161b7afe97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Widening participation (Thoughts from DjangoCon)

Dan Davis
In reply to this post by 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.

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 <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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 can (say) filter tickets by component (and such) we’re were a way from this. 

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

And finally…

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

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

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

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


Kind Regards,

Carlton



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFv-zf%2BvD7yg8-b6w8iG3J-NcE2q-oyfZLOtW3ZZhjo%3DTtLhxw%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 [hidden email].
To post to this group, send email to [hidden email].
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/c9a069c8-44b3-4feb-a873-6ac4f8afaac9%40googlegroups.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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFzonYa_7zYco5-EdHLcNEsVm2GL0trYF2680kiS3bTD7DA15Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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 can (say) filter tickets by component (and such) we’re were a way from this. 

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

And finally…

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

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

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

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


Kind Regards,

Carlton



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFv-zf%2BvD7yg8-b6w8iG3J-NcE2q-oyfZLOtW3ZZhjo%3DTtLhxw%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 [hidden email].
To post to this group, send email to [hidden email].
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/c9a069c8-44b3-4feb-a873-6ac4f8afaac9%40googlegroups.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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFzonYZC7BPG5xOm%3DbdczxCsvaYXSR8eW9-T1f2oeuDFY2J%3Ddg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Widening participation (Thoughts from DjangoCon)

Dan Davis
And there might be no need to develop code for this, only configuration:


On Mon, Dec 10, 2018 at 11:22 AM Dan Davis <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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 can (say) filter tickets by component (and such) we’re were a way from this. 

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

And finally…

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

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

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

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


Kind Regards,

Carlton



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFv-zf%2BvD7yg8-b6w8iG3J-NcE2q-oyfZLOtW3ZZhjo%3DTtLhxw%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 [hidden email].
To post to this group, send email to [hidden email].
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/c9a069c8-44b3-4feb-a873-6ac4f8afaac9%40googlegroups.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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFzonYa0Ap4YZ5zAn8E8%2BWMYvbKssky66MFu%2BuRth4FHui%2Bm%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Widening participation (Thoughts from DjangoCon)

Tom Forbes
I believe the problem is much deeper than "the search is not great" (which it isn't). It's a combination of a lot of factors including the UX and the responsiveness of Trac.

Making the search results more accurate is a good initiative but hamstrung by the myriad of buttons, options, drop-downs and input fields Trac presents. Remember, this is about getting new developers onboard. 

This UI puts people off:



This doesn't:

<img src="file:///Users/tom/Library/Group Containers/2E337YPCZY.airmail/Library/Application Support/it.bloop.airmail2/Airmail/General/Local/1544459245176422144/Attachments/Screenshot 2018-12-10 at 16.31.14.png">


And I think that's part of the problem. The ticket system is a critical part of onboarding new developers, it's the gateway to interact with all of Django. Familiarity and usability are key.

On 10 December 2018 at 16:25:36, Dan Davis ([hidden email]) wrote:

And there might be no need to develop code for this, only configuration:


On Mon, Dec 10, 2018 at 11:22 AM Dan Davis <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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 can (say) filter tickets by component (and such) we’re were a way from this. 

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

And finally…

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

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

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

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


Kind Regards,

Carlton



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFv-zf%2BvD7yg8-b6w8iG3J-NcE2q-oyfZLOtW3ZZhjo%3DTtLhxw%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 [hidden email].
To post to this group, send email to [hidden email].
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/c9a069c8-44b3-4feb-a873-6ac4f8afaac9%40googlegroups.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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFzonYa0Ap4YZ5zAn8E8%2BWMYvbKssky66MFu%2BuRth4FHui%2Bm%3Dw%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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFNZOJN8k0VE_qQL_mJORBTXcCn0_V7DpFaYg4-4i6UGDPYJsw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Widening participation (Thoughts from DjangoCon)

Tom Forbes
Not sure why the second image didn't show up:



It's a picture of Github's issue filtering interface. 

On 10 December 2018 at 16:35:21, Tom Forbes ([hidden email]) wrote:

I believe the problem is much deeper than "the search is not great" (which it isn't). It's a combination of a lot of factors including the UX and the responsiveness of Trac.

Making the search results more accurate is a good initiative but hamstrung by the myriad of buttons, options, drop-downs and input fields Trac presents. Remember, this is about getting new developers onboard. 

This UI puts people off:



This doesn't:


And I think that's part of the problem. The ticket system is a critical part of onboarding new developers, it's the gateway to interact with all of Django. Familiarity and usability are key.

On 10 December 2018 at 16:25:36, Dan Davis ([hidden email]) wrote:

And there might be no need to develop code for this, only configuration:


On Mon, Dec 10, 2018 at 11:22 AM Dan Davis <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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, <[hidden email]> 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 <[hidden email]> 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 can (say) filter tickets by component (and such) we’re were a way from this. 

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

And finally…

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

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

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

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


Kind Regards,

Carlton



--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFv-zf%2BvD7yg8-b6w8iG3J-NcE2q-oyfZLOtW3ZZhjo%3DTtLhxw%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 [hidden email].
To post to this group, send email to [hidden email].
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/c9a069c8-44b3-4feb-a873-6ac4f8afaac9%40googlegroups.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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFzonYa0Ap4YZ5zAn8E8%2BWMYvbKssky66MFu%2BuRth4FHui%2Bm%3Dw%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 [hidden email].
To post to this group, send email to [hidden email].
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/CAFNZOJMdaCdzRdZjAN9dVfYP__hCH7%2BDo%3DDQyNToMU-dBa6SCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Widening participation (Thoughts from DjangoCon)

Dan Davis
In reply to this post by Tom Forbes
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 [hidden email].
To post to this group, send email to [hidden email].
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.

Screenshot 2018-12-10 at 16.33.00.png (242K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email] 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 [hidden email].
To post to this group, send email to [hidden email].
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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: Widening participation (Thoughts from DjangoCon)

Ira Abbott
In reply to this post by Dan Davis
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 <a href="https://code.djangoproject.com/search" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fsearch\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEMT2dAoAV36WqzqDevAktfbiNK1A&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fsearch\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEMT2dAoAV36WqzqDevAktfbiNK1A&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

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

<a href="https://www.atlassian.com/software/jira/pricing" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.atlassian.com%2Fsoftware%2Fjira%2Fpricing\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGNp96Cx1H4RFAcj14AbGmqHLQzeA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.atlassian.com%2Fsoftware%2Fjira%2Fpricing\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGNp96Cx1H4RFAcj14AbGmqHLQzeA&#39;;return true;">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 <a href="https://code.djangoproject.com/search" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fsearch\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEMT2dAoAV36WqzqDevAktfbiNK1A&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fsearch\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEMT2dAoAV36WqzqDevAktfbiNK1A&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

Re: Widening participation (Thoughts from DjangoCon)

Ira Abbott
In reply to this post by Zach Garwood
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 <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="vGPQjyWwBAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">dans...@... 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 <a href="https://code.djangoproject.com/search" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fsearch\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEMT2dAoAV36WqzqDevAktfbiNK1A&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fsearch\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEMT2dAoAV36WqzqDevAktfbiNK1A&#39;;return true;">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 <a href="javascript:" rel="nofollow" target="_blank" gdf-obfuscated-mailto="vGPQjyWwBAAJ" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-develop...@googlegroups.com.
To post to this group, send email to <a href="javascript:" rel="nofollow" target="_blank" gdf-obfuscated-mailto="vGPQjyWwBAAJ" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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.
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email] 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 <a href="https://code.djangoproject.com/search" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fsearch\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEMT2dAoAV36WqzqDevAktfbiNK1A&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fsearch\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEMT2dAoAV36WqzqDevAktfbiNK1A&#39;;return true;">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 [hidden email].
Visit this group at <a href="https://groups.google.com/group/django-developers" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/django-developers&#39;;return true;">https://groups.google.com/group/django-developers.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com?utm_medium=email&amp;utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">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 [hidden email].
To post to this group, send email to [hidden email].
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.
12