As part of the informational DEP that is being written for the Trac migration, we are currently looking for information on what features of Trac that people use that for example don’t exist or are not as easily available in Github Issues or other options that may be considered.
This includes power users, for example most people won’t use the timeline, but a subset, like the Fellows or the triage team will.
These are the items that we currently have:
Support for “reports”
Support for extra metadata fields
Ability for community triage
1 and 2 may be covered by Github Projects, but we would need more information, like what fields or reports do we need or are being used.
For example there are many reports in Reports – Django, which ones are you using?
In my experience, almost all metadata fields are used rigorously. The process is documented in detail.
Related to the ticket flags, I wrote some code that adds a yellow box underneath the description of each open ticket “According to the ticket’s flags, the next step(s) to move this issue forward are:” to help guide newcomers regarding the triage process:
I highly value searching the tracker using Google’s site:code.djangoproject.com filter.
When committing a patch, a comment is automatically added to the ticket which makes it easy to see its resolution, as well as if the patch was backported to another branch.
The GitHub issue tracker adds a comment to an issue every time a commit with the issue number is pushed with the ticket number which makes things quite ugly when force-pushing to amend a PR. Example:
All I can really do is quote my comment from the other thread:
It’s the precise filtering that the extra fields enable. GitHub’s labelling is grossly underpowered by comparison. It’s the day to day use of Trac which shows its power.
The timeline and reports are all features I use regularly, and more so when Fellow.
I have answers for some things, but not everything. And of course the solutions might not be considered ideal by everyone. But here are my thoughts.
We could probably add a GitHub Action that adds this as a comment to the PR (and keeps this up to date). Similar to the welcome message we have on PRs, with a bit more complexity. I do think it has a bit less visibility than what we have now, but I also think Trac has less visibility for most users in general.
This is not strictly true. It’s also possible to assign someone that has made a comment on the issue. I’m not sure if there are other exceptions. But someone could comment on the ticket “I would like to claim this” and could then be assigned.
Though I find myself not using this as much because GitHub’s search is both less cumbersome and more powerful than Trac’s.
I’m not sure about backports specifically (maybe?) but it’s possible to link PRs to issues, either automatically using the ticket number in the title or in certain way in the PR body, or by a couple of clicks. This closes the issue atomatically as done, which may or may not be what we want if doing e.g. backports.
Certainly this is annoying but I wouldn’t personally consider it a blocker to moving?
To ping @carltongibson since I can only “reply” to one message.
Yes, this is useful. There are options though. Python seems to do well by using namespaced labels, e.g. topic-importlib, type-bug and so on. We could copy this. For types specifically, configurable types are currently in beta, so you can set up feature, bug, optimisation/cleanup, and any others we have now.
If we wanted to double down and also use GitHub issues, we can add any custom fields we want here, e.g. Component with a list of allowed values for easy filtering (easier than Trac but that’s just IMO). But using labels would also work if we didn’t want to also use projects.
Yep, understood. GitHub projects again offers some reports and charts and so. I’ve not used them extensively but they can be customised a bit. Would be interesting to see if this is enough. If not, I suppose we could also write something to generate these reports. But sounds like work. Perhaps would be good to investigate if what GH projects can give us is “good enough”.
No doubt we could migrate to another ticket tracker if we had no other choice, but it would be a tremendous amount of work and disruption, and I believe Trac serves us just fine. I would rather not spend my time arguing for the status quo. However, if the informational DEP is written under the premise that we should move away from Trac, then I guess I will have to write a counterpoint.
There is a long 2011 thread on the old django-core mailing list titled “Let’s move to GitHub” where this was discussed at length. Adrian summarized:
It’s clear that most people are onboard with the idea of moving from Subversion to Git, but the big outstanding question is the ticket system and, specifically, how our triage process fits into it. Personally I think our development process could use a good splash of ice-cold water, and I’m oh-so-tempted by the idea of “declaring ticket bankruptcy” and starting from scratch. But I realize it would be a huge risk to abandon Trac, even if it remained in a read-only state.
I certainly would have agreed with that in 2011. However, it hasn’t been 2011 for some time and I believe the landscape has changed a lot in that time.
The DEP is in very early stages, so it’s not clear how it will look just yet. One thing I think is clear is that we don’t want to provide a whole host of options, that will just lead to analysis paralysis. Just the best option versus the status quo. And I’m happy to have your and anyone else’s input on why the status quo is still better close to 15 years later, and happy to include that.
Perhaps in the DEP, it would be interesting to add perspectives from newer Django contributors, who might be coming from other projects that don’t use Trac, or from those haven’t been using Trac for as long.
Regarding community triaging, I think it is still possible to do with GitHub issues with some automation/bots. Maybe it still not the same level of community triaging with Trac, but it is possible to have a large group of Triagers on GitHub repo and to have lots of automation surrounding it.
Well, to understand the last issues with moving to a new tracker (Jira)
I took some (unstructured) notes.
move to a new tracker
“I felt like lost using trac; it is kind of messy. I just don’t feel comfortable with it”
“FWIW I actually like Jira (much more than Trac) and find it a lot easier to use”
“I see so many open source project using Jira that [it] is just natural. Search is easy, categorise is easy, look through the all issues and task is quick”
“There is a plug-in to migrate all the data to Jira”
“My number 1 gripe with Trac is that search SUCKS”
“I really do think Trac is awful though, just wanted to be clear about that”
(Taiga.io) has integration with GitHub (tickets, login)
“All bug trackers are bad, we should stick with the bad one we are used to”
“Would require a lot of work and effort to switch”
“I get to use Jira on a daily basis and find it cumbersome and confusing”
“Jira is ‘I love it’ or ‘I hate it’”
“Jira is too complex. Devs may end up understanding it, but users will have a harder time, […]”
“Moving from a FLOSS tool to a proprietary solution really gives mixed signals. It’d confuse me why a team who clearly appreciates open-sourceness would make such a move with so many great alternatives out there”
“All [my company switching to JIRA] did from my perspective is add 47 layers of complexity on top of a massively confusing UI”
“[Jira] is a great tool, but it is extremely heavyweight, […] it will be an alienating, frustrating experience for all involved”
“I’ve had to use [Jira] on a number of projects, and I’ve never had a good experience with it”
“Having used [Jira] in projects in the past, I’ve found is bizarrely slow, and tedious”
“To search Trac, use ‘site:code.djangoproject.com your query’ in a Google search box. Works great in my experience”
(Taiga.io) has no integration with Django Project login
“Related to our workflow is permissions. This is one of the biggest reasons why Github Issues doesn’t work for us. We need to be able to give access to anyone to update issues. This doesn’t just mean adding comments - it means progressing a ticket along the workflow, adding flags (or whatever categorisation mechanism exists), even closing issues”
