- Being able to quickly delete security reports mistakenly entered on the public tracker
1 Like
If we’re evaluating alternative (or current) Django ticketing systems, I’d want the checklist to include:
- Write ticket descriptions and comments in Markdown by default. (Ideally GFM.)
That’s what Django’s forum, PR reviews, and new features discussions all use, and contributors are more likely to know Markdown than TracWiki syntax. (Incidentally, there’s an open Trac enhancement request for Markdown in tickets.)
Also…
- Minimize the number of separate accounts needed to contribute to Django. (E.g., login with GitHub, at least as an option.)
- Paste images or screen recordings into tickets.
- Support for reactions like
to avoid noisy comments like +1. - Ability to hide comments like “can you assign this to me?” (Or better yet, some way to redirect users trying to post them to the contributor instructions.)
- Reasonable browser performance on lengthy ticket discussions, without requiring readers to click to reveal important parts of the thread that the platform arbitrarily collapsed as a performance hack. (
ಠ_ಠ)
2 Likes
Short question here: Is it possible to get a SQL dump of the current issues in order to set up Trac locally?
1 Like
- Decent uptime, which is not the case of GitHub and I don’t think that will improve in the short term
- Ability to create private issues and set a group of users to have access to it
1 Like
If Trac is replaced, would the new solution need a wiki? It looks like Trac’s wiki has a lot of content, but may not used as much as it was several years ago. Much of the content may be good but outdated. I wonder if it’d be wise to decrease our reliance on this feature in general. Relevant content could be moved to a GitHub wiki if that is desirable.
I am unsure about a need to replace the wiki functionality. I think we could find homes for the content on the wiki either on the djangoproject.com weblog (e.g. gsoc ideas - we already have a GSoC blog post) and/or the django/django repo (e.g. CI config).
Relevant content could be moved to a GitHub wiki if that is desirable.
I was on the fence about pros/cons about moving more things to GitHub until this week. However, after seeing a second contributor having their account suspended for unknown reasons, I’m leaning towards the view of moving off GitHub completely at this point.
4 Likes
I can’t say I really love GitHub wikis. I think we could have a read only archive (somewhere…) of what’s there. The parts that are still updated (roadmap?) should probably go on the website proper so they’re more discoverable and we have a bit more control over the presentation and semantics.
2 Likes
I think it’s worth keeping in mind developing our own solution. While there are advantages to using something off the shelf, all of those sound like they’re going to involve some amount of compromise.
If some maintenance and hosting burden is the cost of having an issue tracker that fades into the background, that’s worth it. Plus taking this on ourselves eliminates practically ALL the problems and pitfalls raised to date.
As to this expending resources that could be better used progressing Django itself, there is another way to view it. Imagine a potentially untapped group of people (such as myself) who want to support Django, but are still building the confidence to work on the framework code itself. A supporting project like this would be a great way to tangibly contribute while learning how things work behind the scenes.
1 Like
To some extent this is a really nice idea. Just build a modern “trac2” based on Django with a group of individuals, which could also function as a testing ground for new Django features. It has the risk that at first there are lots of enthousiast people contributing code and that it fizzles out and becomes a maintenance burden and then we are stuck with custom stuff (but built on the framework we know and love).
so I am not sure it is the best option, and I’d say it preferably needs a group of a bunch of people that have time and at least two pretty experienced people for guidance. But I always find these ideas tempting and specifically the “testing ground” angle is interesting to me
1 Like
FYI my earlier statement is incorrect (whoops, spoke too soon 
):
̶T̶a̶i̶g̶a̶ ̶i̶s̶ ̶m̶a̶i̶n̶t̶a̶i̶n̶e̶d̶.̶.̶.̶b̶u̶t̶ ̶n̶o̶t̶ ̶i̶n̶ ̶a̶c̶t̶i̶v̶e̶ ̶d̶e̶v̶e̶l̶o̶p̶m̶e̶n̶t̶
Taiga is currently maintained and developed. An amendment to my earlier description of the two is: Kaleidos handed off TaigaNext to Biru (who renamed Tenzu) but also handed off Taiga (Taiga 6 at the time) to a separate group, Taiga Cloud Services. One of the Taiga folks clarified that “Both [Taiga and Tenzu] will be maintained, developed, and continued as two completely different projects, and we [at Taiga] have no affiliation with Tenzu.”
[I’m not weighing in on its suitability/unsuitability for a Trac replacement here, but mainly I wanted to correct the misinformation.]
As a bonus aside, I also ran across a directory of public projects using Taiga - at a glance, it looks like a lot of smaller projects, but I didn’t really look through it in detail. Clicking into some took me a while to load though.