Widening participation (Thoughts from DjangoCon)
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*
.
This must be about the best-kept secret in the Django world: it’s gets ≈0
traffic, but I told everybody at DjangoCon about it, and that they should
use it.
If you are not on django-core-mentorship, and you’re willing to help
prospective contributors, please sign-up. I’m hoping we can drive some
traffic to it.
Maybe there’s call for something more formal, but at least until DCM is
actually being used, that seems (to me) like something we can postpone.
Finding Tickets
The next thing was that there’s not enough guidance on what to work on.
The guidance is to look for *Easy Pickings*. There are ≈1300 accepted open
tickets in TRAC. 13 of these are marked *Easy Pickings*.
That’s not enough. I think we’re too tight with it (or need another grade).
There are *many* tickets which aren’t super hard: I put it that, most of
our community solve harder problems every day *using Django* than most
tickets require.
Yes, they still require time, love, energy, etc — and maybe some mentoring
— but it’s not primary research, in the main.
I talked to people who had (at the conference) got the test suite running
and such, but been overawed by the (for want of a better phrase) *sheer
face* of issue tracker.
We would do well to invite people better here. (I don’t have instant
solutions.)
Sprints
I’m not historically a Django-sprinter. (I have too many children for that
TBH, but they’re getting older…)
I always thought it was for a hard-core to work on hard issues.
Shows what I know… 🙂
It was strongly impressed upon me that the real benefit of sprints is being
able to give new contributors the support they need to make their first (or
second or…) contribution.
In particular, groups such as Pyladies can organise a sprint event with the
specific goal of helping members of the community get across the barriers
to contributing. This can reach numbers that otherwise simply aren’t
possible. (So wow. Basically.)
Sprints & Mentoring
Obviously having mentors at sprints is a key component.
But even if you (or I) can’t attend a sprint, maybe we can (sometimes) be
available at the right time to contribute remotely. Maybe, in fact, remote
mentors are a key resource in more remote parts of the Django-sphere.
It turns out just being on e.g. Twitter can be enough here.
If we’re all on django-core-mentorship, maybe sprint organisers could post
notice of an upcoming sprint.
Sprints & Finding Tickets
It turns out it’s equally hard for a sprint organiser to work out what
tasks to give sprinters.
At DjangoCon (some) people have a topic and asks others to join them. But,
maybe if you’re short of experts and so on, that’s not necessarily a model
that allows that scales out in other contexts.
It was put to me that, if we had something like curated project boards
(think Trello or GitHub projects) with groups of tickets… perhaps some
easier, some harder… Perhaps with a *curating mentor*, even if remote… —
*THEN* it becomes much easier for a small groups to organise a sprint,
whatever their group may look like, wherever they may be.
It struck me that, whilst we can (say) filter tickets by component (and
such) we’re were a way from this.
(Again, I don’t have instant solutions — but I suspect there’s an 80:20
available somewhere here…)
And finally…
Beyond all that, we clearly have a problem w
Re: Widening participation (Thoughts from DjangoCon)
Thanks. Although I don't solve the demographic problem, I should respond
to the call for broader participation. I should make myself put aside time
to contribute - and I should force my boss to let me ;)
On Fri, Oct 26, 2018 at 9:44 AM Carlton Gibson
wrote:
> Hi All.
>
> OK, so last week I was at DjangoCon US in San Diego. (Thank you if you
> organised that! Hi! if we met and chatted.)
> I gave a talk ("Your web framework needs you!") inspired by the
> discussion on the
>
> DSF list and the proposal to dissolve Django Core
> . (Can’t see the DSF list? Join
> the DSF
>
> .)
> I was asking for more participation in general, and participation that is
> more representative of the wider Django community in particular.
>
> There was lots of good input from many people, including (but not, at all,
> limited to) representatives of groups such Pyladies, DjangoGirls, and so
> on.
>
>
> The recurring themes seem to me to fit into three categories:
>
>1. The importance of *mentoring*.
>2. The difficulty of *finding tickets*.
>3. The importance of *sprints*.
>
> The rest here is a summary of that. Hopefully it’s useful.
>
> Mentoring
>
> For whatever reasons, the exiting *Contributing How-To*
> .
>
> 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… —
>
Re: Widening participation (Thoughts from DjangoCon)
Hi Carlton,
I've had similar thoughts sitting in the back of my mind for at least a
couple of months, so thank you for sharing this. I agree that finding
tickets is one of the big problems here, both for new contributors and for
sprint leaders. At Pycon UK I took on the role of sprint leader along with
Adam Johnson and directing people to appropriate tickets was a definite
difficulty. I was also unaware of the django core mentorship list and will
be joining that soon. I'm willing to spend some time mentoring a small
number of people, life permitting.
Ian
On Fri, 26 Oct 2018 at 14:44, Carlton Gibson
wrote:
> Hi All.
>
> OK, so last week I was at DjangoCon US in San Diego. (Thank you if you
> organised that! Hi! if we met and chatted.)
> I gave a talk ("Your web framework needs you!") inspired by the
> discussion on the
>
> DSF list and the proposal to dissolve Django Core
> . (Can’t see the DSF list? Join
> the DSF
>
> .)
> I was asking for more participation in general, and participation that is
> more representative of the wider Django community in particular.
>
> There was lots of good input from many people, including (but not, at all,
> limited to) representatives of groups such Pyladies, DjangoGirls, and so
> on.
>
>
> The recurring themes seem to me to fit into three categories:
>
>1. The importance of *mentoring*.
>2. The difficulty of *finding tickets*.
>3. The importance of *sprints*.
>
> The rest here is a summary of that. Hopefully it’s useful.
>
> Mentoring
>
> For whatever reasons, the exiting *Contributing How-To*
> .
>
> This must be about the best-kept secret in the Django world: it’s gets ≈0
> traffic, but I told everybody at DjangoCon about it, and that they should
> use it.
>
> If you are not on django-core-mentorship, and you’re willing to help
> prospective contributors, please sign-up. I’m hoping we can drive some
> traffic to it.
>
> Maybe there’s call for something more formal, but at least until DCM is
> actually being used, that seems (to me) like something we can postpone.
>
> Finding Tickets
>
> The next thing was that there’s not enough guidance on what to work on.
>
> The guidance is to look for *Easy Pickings*. There are ≈1300 accepted
> open tickets in TRAC. 13 of these are marked *Easy Pickings*.
>
> That’s not enough. I think we’re too tight with it (or need another
> grade).
>
> There are *many* tickets which aren’t super hard: I put it that, most of
> our community solve harder problems every day *using Django* than most
> tickets require.
>
> Yes, they still require time, love, energy, etc — and maybe some mentoring
> — but it’s not primary research, in the main.
>
> I talked to people who had (at the conference) got the test suite running
> and such, but been overawed by the (for want of a better phrase) *sheer
> face* of issue tracker.
>
> We would do well to invite people better here. (I don’t have instant
> solutions.)
>
> Sprints
>
> I’m not historically a Django-sprinter. (I have too many children for that
> TBH, but they’re getting older…)
>
> I always thought it was for a hard-core to work on hard issues.
>
> Shows what I know… 🙂
>
> It was strongly impressed upon me that the real benefit of sprints is
> being able to give new contributors the support they need to make their
> first (or second or…) contribution.
>
> In particular, groups such as Pyladies can organise a sprint event with
> the specific goal of helping members of the community get across the
> barriers to contributing. This can reach numbers that otherwise simply
> aren’t possible. (So wow. Basically.)
>
> Sprints & Mentoring
>
> Obviously having mentors at sprints is a key component.
>
> But even if you (or I) can’t attend a sprint, maybe we can (sometimes) be
> available at the right time to contribute remotely. Maybe, in fact, remote
> mentors are a key resource in more remote parts of the Django-sphere.
>
> It turns out just being on e.g. Twitter can be enough here.
>
> If we’re all on django-core-mentorship, maybe sprint organisers could post
> notice of an upcoming sprint.
>
> Sprints & Finding Tickets
>
> It turns out it’s equally hard for a sprint organiser to work out what
> tasks to give sprinters.
>
> At DjangoCon (some) people have a topic and asks others to join them. B
Re: QuerySet.iterator together with prefetch_related because of chunk_size
I tend to agree with Tobi. Prefetching silently not working on iterator can be quite confusing, unless you have a good understanding of both APIs. It might be possible to do what you're asking, but it'd mean that django is now actually caching the result when it explicitly says it isn't - even if the result is a much smaller moving cache. Prefetching chunk_size results per chunk is unlikely to make a material difference to memory usage. Users are usually concerned about the entire result set of the primary table. I don't know if you can change the API to make these suggested changes without also impacting how we iterate over result sets - but I'd be interested in seeing a proof of concept at the very least. On Monday, 15 October 2018 20:41:13 UTC+11, tobias@truffls.com wrote: > > Thank you for your feedback. I would like to answer some statements to > either convince you or make it more clear, where my idea stems from: > > The fundamental reason why iterator() cannot be used with >> prefetch_related() is that the latter requires a set of model instance to >> be materialized to work appropriately which chunk_size doesn't control at >> all. >> In other words chunk_size only controls how many rows should be fetched >> from the database cursor and kept into memory at a time. Even when this >> parameter is used, iterator() will only materialize a single model instance >> per yield. >> > > It should be easily possible to change the involved code of ModelIterable > to materialize the retrieved rows in batches. After materializing the batch > / chunk, it could do the prefetching. > > >> Given that iterator() always ignored prefetch related lookups instead of >> erroring out when they were specified make me feel like turning such a >> feature on by default could be problematic as it could balloon the memory >> usage which is the main reason why iterator is useful anyway. >> > > I would argue, that users who thoughtlessly applied prefetching together > with iterator now actually get, what they thought of: less DB query round > trips traded against a little more memory usage. > > Best, > Tobi > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e7a36092-0743-41dc-998e-eee11fa1180b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Widening participation (Thoughts from DjangoCon)
An alternative that might work well is to triage tickets to mentors, so
that a list of tickets with willing mentors is available. It would feel
less judge-y than "easy pickings" and also broaden the pool of tickets that
could be worked by a newcomer. Of course it hinges on a willing pool of
mentors and making the time needed to do the work.
On Fri, Oct 26, 2018 at 2:43 PM Ian Foote wrote:
> Hi Carlton,
>
> I've had similar thoughts sitting in the back of my mind for at least a
> couple of months, so thank you for sharing this. I agree that finding
> tickets is one of the big problems here, both for new contributors and for
> sprint leaders. At Pycon UK I took on the role of sprint leader along with
> Adam Johnson and directing people to appropriate tickets was a definite
> difficulty. I was also unaware of the django core mentorship list and will
> be joining that soon. I'm willing to spend some time mentoring a small
> number of people, life permitting.
>
> Ian
>
> On Fri, 26 Oct 2018 at 14:44, Carlton Gibson
> wrote:
>
>> Hi All.
>>
>> OK, so last week I was at DjangoCon US in San Diego. (Thank you if you
>> organised that! Hi! if we met and chatted.)
>> I gave a talk ("Your web framework needs you!") inspired by the
>> discussion on the
>>
>> DSF list and the proposal to dissolve Django Core
>> . (Can’t see the DSF list? Join
>> the DSF
>>
>> .)
>> I was asking for more participation in general, and participation that is
>> more representative of the wider Django community in particular.
>>
>> There was lots of good input from many people, including (but not, at
>> all, limited to) representatives of groups such Pyladies, DjangoGirls, and
>> so on.
>>
>>
>> The recurring themes seem to me to fit into three categories:
>>
>>1. The importance of *mentoring*.
>>2. The difficulty of *finding tickets*.
>>3. The importance of *sprints*.
>>
>> The rest here is a summary of that. Hopefully it’s useful.
>>
>> Mentoring
>>
>> For whatever reasons, the exiting *Contributing How-To*
>> .
>>
>> This must be about the best-kept secret in the Django world: it’s gets ≈0
>> traffic, but I told everybody at DjangoCon about it, and that they should
>> use it.
>>
>> If you are not on django-core-mentorship, and you’re willing to help
>> prospective contributors, please sign-up. I’m hoping we can drive some
>> traffic to it.
>>
>> Maybe there’s call for something more formal, but at least until DCM is
>> actually being used, that seems (to me) like something we can postpone.
>>
>> Finding Tickets
>>
>> The next thing was that there’s not enough guidance on what to work on.
>>
>> The guidance is to look for *Easy Pickings*. There are ≈1300 accepted
>> open tickets in TRAC. 13 of these are marked *Easy Pickings*.
>>
>> That’s not enough. I think we’re too tight with it (or need another
>> grade).
>>
>> There are *many* tickets which aren’t super hard: I put it that, most of
>> our community solve harder problems every day *using Django* than most
>> tickets require.
>>
>> Yes, they still require time, love, energy, etc — and maybe some
>> mentoring — but it’s not primary research, in the main.
>>
>> I talked to people who had (at the conference) got the test suite running
>> and such, but been overawed by the (for want of a better phrase) *sheer
>> face* of issue tracker.
>>
>> We would do well to invite people better here. (I don’t have instant
>> solutions.)
>>
>> Sprints
>>
>> I’m not historically a Django-sprinter. (I have too many children for
>> that TBH, but they’re getting older…)
>>
>> I always thought it was for a hard-core to work on hard issues.
>>
>> Shows what I know… 🙂
>>
>> It was strongly impressed upon me that the real benefit of sprints is
>> being able to give new contributors the support they need to make their
>> first (or second or…) contribution.
>>
>> In particular, groups such as Pyladies can organise a sprint event with
>> the specific goal of helping members of the community get across the
>> barriers to contributing. This can reach numbers that otherwise simply
>> aren’t possible. (So wow. Basically.)
>>
>> Sprints & Mentoring
>>
>> Obviously having mentors at sprints is a key component.
>>
>> But even if you (or I) can’t attend a sprint, maybe we can (sometimes) be
>>
Re: Widening participation (Thoughts from DjangoCon)
How much of this would you attribute to the current ticketing system
itself, rather than tickets being tagged appropriately?
I know when I started contributing I found trac to be pretty intimidating
in terms of complexity, especially the search. I still prefer to use the
'Search Trac' field in the root code.djangoproject.com page than fiddle
with the myriad of options and drop downs in the browse tickets section.
If we think of getting new people onboard as a conversion funnel we need to
stop dropoff as much as possible, and that extends to the UI of the ticket
tracker as well I believe.
Tom
On Fri, 26 Oct 2018, 22:43 Ian Foote, wrote:
> Hi Carlton,
>
> I've had similar thoughts sitting in the back of my mind for at least a
> couple of months, so thank you for sharing this. I agree that finding
> tickets is one of the big problems here, both for new contributors and for
> sprint leaders. At Pycon UK I took on the role of sprint leader along with
> Adam Johnson and directing people to appropriate tickets was a definite
> difficulty. I was also unaware of the django core mentorship list and will
> be joining that soon. I'm willing to spend some time mentoring a small
> number of people, life permitting.
>
> Ian
>
> On Fri, 26 Oct 2018 at 14:44, Carlton Gibson
> wrote:
>
>> Hi All.
>>
>> OK, so last week I was at DjangoCon US in San Diego. (Thank you if you
>> organised that! Hi! if we met and chatted.)
>> I gave a talk ("Your web framework needs you!") inspired by the
>> discussion on the
>>
>> DSF list and the proposal to dissolve Django Core
>> . (Can’t see the DSF list? Join
>> the DSF
>>
>> .)
>> I was asking for more participation in general, and participation that is
>> more representative of the wider Django community in particular.
>>
>> There was lots of good input from many people, including (but not, at
>> all, limited to) representatives of groups such Pyladies, DjangoGirls, and
>> so on.
>>
>>
>> The recurring themes seem to me to fit into three categories:
>>
>>1. The importance of *mentoring*.
>>2. The difficulty of *finding tickets*.
>>3. The importance of *sprints*.
>>
>> The rest here is a summary of that. Hopefully it’s useful.
>>
>> Mentoring
>>
>> For whatever reasons, the exiting *Contributing How-To*
>> .
>>
>> This must be about the best-kept secret in the Django world: it’s gets ≈0
>> traffic, but I told everybody at DjangoCon about it, and that they should
>> use it.
>>
>> If you are not on django-core-mentorship, and you’re willing to help
>> prospective contributors, please sign-up. I’m hoping we can drive some
>> traffic to it.
>>
>> Maybe there’s call for something more formal, but at least until DCM is
>> actually being used, that seems (to me) like something we can postpone.
>>
>> Finding Tickets
>>
>> The next thing was that there’s not enough guidance on what to work on.
>>
>> The guidance is to look for *Easy Pickings*. There are ≈1300 accepted
>> open tickets in TRAC. 13 of these are marked *Easy Pickings*.
>>
>> That’s not enough. I think we’re too tight with it (or need another
>> grade).
>>
>> There are *many* tickets which aren’t super hard: I put it that, most of
>> our community solve harder problems every day *using Django* than most
>> tickets require.
>>
>> Yes, they still require time, love, energy, etc — and maybe some
>> mentoring — but it’s not primary research, in the main.
>>
>> I talked to people who had (at the conference) got the test suite running
>> and such, but been overawed by the (for want of a better phrase) *sheer
>> face* of issue tracker.
>>
>> We would do well to invite people better here. (I don’t have instant
>> solutions.)
>>
>> Sprints
>>
>> I’m not historically a Django-sprinter. (I have too many children for
>> that TBH, but they’re getting older…)
>>
>> I always thought it was for a hard-core to work on hard issues.
>>
>> Shows what I know… 🙂
>>
>> It was strongly impressed upon me that the real benefit of sprints is
>> being able to give new contributors the support they need to make their
>> first (or second or…) contribution.
>>
>> In particular, groups such as Pyladies can organise a sprint event with
>> the specific goal of helping members of the community get across the
>> barriers to contributing. This
Re: QuerySet.iterator together with prefetch_related because of chunk_size
Josh, I agree that silently not working is problematic but it has been this way since prefetch_related() was introduced. Something to keep in mind as well is that silently turning it on would also perform P * C extra queries where P is the number of prefetches requested through prefetch_related() and C the number of chunks the results contains. This is non negligible IMO. What I'd be in favor off is raising an exception on prefetch_related(*prefetches).iterator() in the next release at least to allow users using this pattern to adjust their code and then ship the optimization with all the warnings related to the interactions between prefetch_related(*prefetches) and iterator(chunk_size) in the next one. I'm not completely completely against skipping the exception release phase entirely given there might be users out there accessing attributes expected to be prefetched on iterated instances and inadvertently performing tons of queries but the exception phase just feels safer given iterator() is usually used in memory constrained contexts. Simon Le vendredi 26 octobre 2018 19:27:55 UTC-4, Josh Smeaton a écrit : > > I tend to agree with Tobi. Prefetching silently not working on iterator > can be quite confusing, unless you have a good understanding of both APIs. > It might be possible to do what you're asking, but it'd mean that django is > now actually caching the result when it explicitly says it isn't - even if > the result is a much smaller moving cache. Prefetching chunk_size results > per chunk is unlikely to make a material difference to memory usage. Users > are usually concerned about the entire result set of the primary table. > > I don't know if you can change the API to make these suggested changes > without also impacting how we iterate over result sets - but I'd be > interested in seeing a proof of concept at the very least. > > > > On Monday, 15 October 2018 20:41:13 UTC+11, tobias@truffls.com wrote: >> >> Thank you for your feedback. I would like to answer some statements to >> either convince you or make it more clear, where my idea stems from: >> >> The fundamental reason why iterator() cannot be used with >>> prefetch_related() is that the latter requires a set of model instance to >>> be materialized to work appropriately which chunk_size doesn't control at >>> all. >>> In other words chunk_size only controls how many rows should be fetched >>> from the database cursor and kept into memory at a time. Even when this >>> parameter is used, iterator() will only materialize a single model instance >>> per yield. >>> >> >> It should be easily possible to change the involved code of ModelIterable >> to materialize the retrieved rows in batches. After materializing the batch >> / chunk, it could do the prefetching. >> >> >>> Given that iterator() always ignored prefetch related lookups instead of >>> erroring out when they were specified make me feel like turning such a >>> feature on by default could be problematic as it could balloon the memory >>> usage which is the main reason why iterator is useful anyway. >>> >> >> I would argue, that users who thoughtlessly applied prefetching together >> with iterator now actually get, what they thought of: less DB query round >> trips traded against a little more memory usage. >> >> Best, >> Tobi >> > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2389b18a-ea33-40eb-b5b0-929ab02a468a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Ticket/Issue Tracker
A few years ago I realized I really liked the UI of Trello.com, so I tried
creating a trello-style view of django tickets:
https://djello.collinand.org/ (beware, I'm not a designer :)
It's basically just 100 lines of JS and a little CSS. It's still my go to
for finding tickets.
I thought I'd share that as an idea for how to improve find-ability.
-- Forwarded message -
From: Tom Forbes
Date: Fri, Oct 26, 2018 at 8:09 PM
Subject: Re: Widening participation (Thoughts from DjangoCon)
How much of this would you attribute to the current ticketing system
itself, rather than tickets being tagged appropriately?
I know when I started contributing I found trac to be pretty intimidating
in terms of complexity, especially the search. I still prefer to use the
'Search Trac' field in the root code.djangoproject.com page than fiddle
with the myriad of options and drop downs in the browse tickets section.
If we think of getting new people onboard as a conversion funnel we need to
stop dropoff as much as possible, and that extends to the UI of the ticket
tracker as well I believe.
Tom
On Fri, 26 Oct 2018, 22:43 Ian Foote wrote:
> Hi Carlton,
>
> I've had similar thoughts sitting in the back of my mind for at least a
> couple of months, so thank you for sharing this. I agree that finding
> tickets is one of the big problems here, both for new contributors and for
> sprint leaders. At Pycon UK I took on the role of sprint leader along with
> Adam Johnson and directing people to appropriate tickets was a definite
> difficulty. I was also unaware of the django core mentorship list and will
> be joining that soon. I'm willing to spend some time mentoring a small
> number of people, life permitting.
>
> Ian
>
> On Fri, 26 Oct 2018 at 14:44, Carlton Gibson wrote:
>
>> Hi All.
>>
>> OK, so last week I was at DjangoCon US in San Diego. (Thank you if you
>> organised that! Hi! if we met and chatted.)
>> I gave a talk ("Your web framework needs you!") inspired by the
>> discussion on the
>> DSF
>> list and the proposal to dissolve Django Core
>> . (Can’t see the DSF list? Join
>> the DSF
>>
>> .)
>> I was asking for more participation in general, and participation that is
>> more representative of the wider Django community in particular.
>>
>> There was lots of good input from many people, including (but not, at
>> all, limited to) representatives of groups such Pyladies, DjangoGirls, and
>> so on.
>>
>>
>> The recurring themes seem to me to fit into three categories:
>>
>>1. The importance of *mentoring*.
>>2. The difficulty of *finding tickets*.
>>3. The importance of *sprints*.
>>
>> The rest here is a summary of that. Hopefully it’s useful.
>>
>> 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.)
>>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/3b85c677-9244-46f4-b526-bf919bd74057%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
