Widening participation (Thoughts from DjangoCon)

[Carlton Gibson]

Hi All. 

OK, so last week I was at DjangoCon US in San Diego. (Thank you if you organised that! Hi! if we met and chatted.) 
I gave a talk ("Your web framework needs you!") inspired by the discussion on the DSF list and the proposal to dissolve Django Core. (Can’t see the DSF list? Join the DSF.)
I was asking for more participation in general, and participation that is more representative of the wider Django community in particular.

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

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

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

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

Mentoring

For whatever reasons, the exiting Contributing How-To doesn’t lead to contributions from a demographic that matches the wider Django Community. 

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

Django Core Mentorship

We don’t have an official mentoring programme but we do have the django-core-mentorship list. 

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

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

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

Finding Tickets

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

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

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

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

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

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

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

Sprints

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

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

Shows what I know… 🙂

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

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

Sprints & Mentoring

Obviously having mentors at sprints is a key component. 

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

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

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

Sprints & Finding Tickets

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

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

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

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

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

And finally…

Beyond all that, we clearly have a problem 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

[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 ;)

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

[Ian Foote]

Hi Carlton,

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

Ian

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

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.

[Tom Forbes]

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

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

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

Tom

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.

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

[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

[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?  

[Ira Abbott]

Hi,

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

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

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

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

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

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

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

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

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

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

Regards,

Ira

[Dan Davis]

> I strongly dislike Trac in nearly every way. It's hard to search and the filters are next to useless, and the categorisation features we use are not very useful.

> I believe the better way to search Trac is to use google and site:code.djangoproject.com which is a red flag itself.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c9a069c8-44b3-4feb-a873-6ac4f8afaac9%40googlegroups.com.

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

[Dan Davis]

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

https://github.com/dnephin/TracAdvancedSearchPlugin

[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:

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFzonYa0Ap4YZ5zAn8E8%2BWMYvbKssky66MFu%2BuRth4FHui%2Bm%3Dw%40mail.gmail.com.

[Tom Forbes]

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

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

[Dan Davis]

Tom, you are right about the UX issues, but full-text and inverted indexing would help with the responsiveness as well.  Technically, I was talking about djangoproject's TracSearch.  That's closer to good UX as well, because you can get there by progressive enhancement rather than taking stuff away.

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

[Ira Abbott]

Hi,

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

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

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

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

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

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

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

Regards,

Ira

[Zach Garwood]

I'd pay money to NOT use Jira.

On Mon, Dec 10, 2018, 11:09 AM Dan Davis <dans...@gmail.com wrote:

Tom, you are right about the UX issues, but full-text and inverted indexing would help with the responsiveness as well.  Technically, I was talking about djangoproject's TracSearch.  That's closer to good UX as well, because you can get there by progressive enhancement rather than taking stuff away.

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

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com.

[Ira Abbott]

This project probably qualifies here:

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

[Ira Abbott]

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

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

[Josh Smeaton]

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

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

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

[Tom Forbes]

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

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

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

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/127550d4-b2dd-4ad7-8e6e-b56a66080194%40googlegroups.com.

[Hanne Moa]

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

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

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

[Jamesie Pic]

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

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACQ%3DrreeXWcVCjxZGG18GDeeh98P_OxresAm9w_JrN0HSOQNhg%40mail.gmail.com.

[Josh Smeaton]

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

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

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

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

[Abhinav tuteja]

Hey i do also code in django can we talk ?

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0a8e344d-04bc-41b5-864c-f3f36c1b3eed%40googlegroups.com.

[Jamesie Pic]

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

[Hanne Moa]

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


--
HM

[Hanne Moa]

On 12/11/18 8:38 PM, Josh Smeaton wrote:
> Jamesie: please see "Why not Gitlab?" [0]. While it might be better from
> a technical standpoint, it would not be better than GH Issues from an
> onboarding perspective.
>
> [0]https://www.python.org/dev/peps/pep-0581/#why-not-gitlab

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


--
HM

[Tom Forbes]

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

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

On Tue, 11 Dec 2018, 19:38 Josh Smeaton <josh.s...@gmail.com wrote:

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

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

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

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

On Tuesday, 11 December 2018 23:20:21 UTC+11, Tom Forbes wrote:

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

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

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

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

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

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

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

On Tuesday, 11 December 2018 07:26:58 UTC+11, Ira Abbott wrote:

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

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

On Monday, December 10, 2018 at 3:21:53 PM UTC-5, Ira Abbott wrote:

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

On Monday, December 10, 2018 at 2:14:07 PM UTC-5, Zachary Garwood wrote:

I'd pay money to NOT use Jira.

On Mon, Dec 10, 2018, 11:09 AM Dan Davis <dans...@gmail.com wrote:

Tom, you are right about the UX issues, but full-text and inverted indexing would help with the responsiveness as well.  Technically, I was talking about djangoproject's TracSearch.  That's closer to good UX as well, because you can get there by progressive enhancement rather than taking stuff away.

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

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFzonYZ%3DwRCX3HpfYCj0G2i3UrcQmVCDj%3Da%2BOb7zeqtvQm-pxg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/127550d4-b2dd-4ad7-8e6e-b56a66080194%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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/393625cf-3edb-41f3-b208-2b3f22cabd49%40googlegroups.com.

[Carlton Gibson]

Thanks for the discussion all. 

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

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

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

* Dashboards, like http://dashboard.djangoproject.com/ are cool and useful. We should expand usage of those. 

* Filtering by component is an obvious candidate for this. 

   * It's much less scary that way

   * e.g. you can totally ignore the ORM tickets 🙂

   * e.g. There's ONLY (cough) 175 tickets for the admin — that's more addressable. 

* Better use of "Easy Pickings" and/or a "Not Phenomenally Difficult" flag would give more texture. 

* Ultimately (whatever system we use) I think having experienced contributors who know a bit of the issue tracker and can flag or point out issues that would be suitable would be effective. 

    * "I'm retired from contributing to Django, but this ticket wouldn't be too difficult, and maybe I could offer a pointer or two to someone who wanted to take it on."

I'd like to push on these avenues (and similar) before we take on the massive project of changing systems. 

(Ultimately I think we'd change system and find ourselves in exactly the same boat.) 

Kind Regards,

Carlton