DjangoCon US development sprint ideas

[tim-schilling]

@matthiask, I'll be at DjangoCon US this year and it ends with development sprints. Do you think the toolbar would be a valid candidate for the sprints? It'd consist of people who may be new to OSS or new to the toolbar. The target issues should be more straightforward and I'm not sure we have a ton of them right now. I think it'd be fun to get some more folks interested / acclimated to the project.

Thoughts?

[matthiask]

@tim-schilling Sure! I think that's a great idea. django-debug-toolbar is a relevant project for the Django ecosystem and may motivate people to generally contribute to (somewhat) well-known bigger open source projects or even Django itself.

The issues we have are mostly not entry-level issues, that's true. But it will probably still be easier to contribute to DDT than to Django itself. So maybe it won't be for everyone... but people who want to contribute anything anywhere will maybe find it easier to contribute to other Jazzband projects or maybe to any other Django app they are using? For contributions to the toolbar they should probably be at least somewhat experienced users of the toolbar, otherwise they will probably find it hard, but I don't know.

I have fond memories of the Django under the hood conference in Amsterdam. I think it was there that I first felt that I was even able to contribute to Django (myself, not just as a bug reporter). I also had the occasion to complain to a former core developer about some changes which were made to Django in the past 🙃

I'll be on vacation at this time (school vacations and all that) but I have full trust in the Jazzband process, in your good judgement and also in my ability to not be caremad (I learned the word from Donald Stufft's blog, caremad.io and I think it's a great neologism). The toolbar isn't "mine", I'm just one of the shepherds right now...

[tim-schilling]

Thanks @matthiask! You raise a great point about not having many entry-level issues. I'll do some thinking on that. I suspect there are things we can improve or add, but we'll need to think about them. I'm going to keep this open as a way for us to add prospective ideas and vet them.

• Improve logging to help identify why a toolbar isn't showing up ( debug toolbar not showing only when you use Render or HttpResponse function  #1596)
• Make it easier to submit a "This doesn't work" issue by making the example app more user friendly. Include a github issue template that points the reporter to the example app to try to reproduce the issue there. (Postgresql Raw Query Tuple Parameter 500 error on explain statement #1482)
• Create a third party toolbar plugins (Feature Request: Trace every line of my code which gets executed #1460, use Postgres Explain Visualizer #1149, Can you integrate this postgresql query explainer #1042)
• Improve notice to not use the toolbar in a production environment (What are drawbacks of having debug toolbar in production settings ? #1435)
• Improve docs around not enabling the toolbar for testing ('djdt' is not a registered namespace #1405)
• Create a query duration threshold (3s) for automatically disabling prettifying SQL queries. (Some SQL queries make debug toolbar rendering very slow #1402) This would require passing the sql duration into reformat_sql.
• Monitor the instrumentation time and log a warning that the toolbar may be causing the delay to help developers identify slowness in the app ( Extremely long request time with StaticFilesPanel #1394, Extremely long request time when RedirectsPanel is disabled #1263)
• Provide a way to uncheck all checkboxes at once (Provide a way to uncheck all checkboxes at once #1238)
• Support a different language for DDT templates (Toolbar language selection #991)