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”
Frankly, I’m struggling to understand what would be the incentives to move to GitHub. Even if Trac may not be the super-duper bug tracker on earth, it serves us well and does the job.
With my free software advocate hat, I would be strongly opposed to moving from an open-source tool to a closed-source one without a BIG and compelling gain obtained by the move.
Besides the GDPR concerns, one of the biggest concerns that has been raised here is that another tool might not fit Django’s ticketing process which is fairly unique.
In my experience, when some common process is unique to a company or organisation, it means one of two things:
either it’s a gem and it needs to be safeguarded
it is not optimal and one should look at how others are dealing with that process
More often than not, it’s the later, regardless of how deeply the organisation is attached to said process
So I would say this would be a good time for introspection into our ticketing process. And I would say it’s worth looking at how others are doing it without TRAC because a lot of what I hear is “only TRAC fits our process”.
It’s already been mentioned that Python itself was able to move to github but Django is not Python. I would suggest looking at things closer to home like (but not limited to) laravel, fastapi (it now has about the same amount of stars as Django) or wagtail. To see how other projects more similar to Django do issues, triage, reports, etc.
In the self-hostable realm, there is gitlab itself. I don’t know of any notable project that uses gitea or codeberg but there are probably some (share links).
Maybe the conclusion after looking around will be that our ticketing process is the best in the open-source world and then, let’s do whatever we can to keep the trac alive! But if the way we handle tickets is not the absolute best in the world, discussing the features we use and that most others plateforms don’t have might not be the best place to spend our energy?
I’m inclined to agree. I and a few others looking into this have made some good progress in making an equivalent workflow in GitHub. It’s surprisingly not too coplex, though requires a bit of writing GitHub Actions. While doing this, one thing I noticed - quite a small thing but I think indicative of the idea that perhaps what we do now is not ideal - is that there are multiple controls that really have the same purpose.
The “Needs documentation”, “Needs tests”, and “Patch needs improvement” all essentially mean the same - the PR needs work. I’m not sure it really matters to be explicit about which it is, and I think we should generally strive to think of tests and docs as part of the code, not something special.
Another related thing is that we now have a PRs field, and a “Has patch” checkbox. Which apart from the almost zero number of patches that get submitted through Trac rather than GitHub, mean the same thing. If there is an open PR, then it has a patch by definition.
It seems to me like a lot of this work could just automatically “work” in GitHub without needing to go into an external tracker to keep it up to date.
Another thing that came up elsewhere, and probably deserves its own post: Often new features posted in Trac are closed because they might be contentious, and the process for that is to raise a forum discussion first. I can imagine this can be annoying to people. to have their ticket closed and told to post it elsewhere, after struggling to get through Trac and then being told they need an account on a totally different system. It feels like it almost makes sense to only allow (e.g.) T&R team, fellows, SC, maybe other trusted users to add features to Trac (or wherever) based on consensus on a forum post, and we’re much more explicit that all new features go through the forum first. It’s possible this could also add friction though, and quite often some people consider certain things bugs that we actually consider features, and so on, but maybe it’s better than what we have.
Having had a couple issues closed in this manner, I now feel uncomfortable attempting to open a new trac ticket (re-open the old one?) without prior authorization. But it also doesn’t feel like the forum is the right tool for triggering and tracking the evaluation work of “is this ready to be a trac ticket”.
Yeah, I think maybe when it seems appropriate to re-open the tracs, I should post a message on the wontfix trac tickets to have someone else make that evaluation.
Yes, currently a feature request basically requires 3 different accounts (trac, github, forum) which seems less than ideal.
If github was the choice, all this could happen in github itself and if something is “too much” to be opened directly on django itself, maybe direct people towards the DEP repo instead of the forum. I really have to look at how the forum became the place to raise such things when we have an issue tracker and a DEP repo. If it’s just a matter of visibility, I would assume automating a post when a DEP has a full draft or something would not be too complicated to achieve.
My understanding is that this discussion used to happen on the mailing list, which has mostly moved to the forum now. And DEPs didn’t exist back when things were more discussed in the mailing list.
I also feel that now that Django has gotten bigger, a larger set of changes can break things, so more things require discussion than in the past. And a bit of the conservative “never break things” mindset raises social barriers as much as the enforced barrier from closing a Trac ticket. For me, it helps that the forum has much nicer UX than Trac, so I’m usually more interested in posting here than there.
I don’t necessarily mind more discussion, it’s how things work. And while I mind the “never break things” mindset, I also recognize that’s fuzzy and changing as people develop in their thinking. Finding the right balance is the hard work, and that’s what we’re doing as a community.
The enforced barrier from closing a trac ticket without a clear understanding of the metric needed to open it again bothers me more. Having a design decision needed state serves a valuable purpose in that regard: it’s not rejected, we just don’t know what to do yet. I’ve been told that was removed because many tickets went there to die, and ended up having to be pruned later (which of course is difficult to get back to). When things get to that state, the forum often is the right place to discuss design decisions in depth: it is a nicer UI for general discussions.
A better way might be to watch for stalled design decision needed tickets for a certain amount of time, and auto-close them after a certain amount of time with a message encouraging the next person to open it up again to the design decision needed state if they also restart the discussion on the forum. If possible, it can be closed as stalled instead of wontfix to better reflect the lack of a resolution, rather than giving a impression of finality.
I think it should be easy for triagers to say “this is probably a valuable discussion, let me make it visible in the forum”. But even just having to write a summary of the ticket to connect the forum to the ticket can be a real burden to getting the right visibility for a ticket. A burden I don’t want to lay on triagers.
I do want it to be easy for anyone triaging to be able to make it easy for passing issue reporters to contribute an idea that may be worth surfacing to the rest of the community for discussion. Taking that little step to make sure a worthwhile discussion doesn’t stall because it was started at the wrong place is a great way to show incidental contributors that we value their contribution.
We can’t just automate a thread for every design decision needed ticket, because that’ll be far too many that nobody actually thinks are that important. But it might be useful to have some manual-trigger automation that could embed the current ticket summary into an original thread post, or otherwise make a better conversational bridge between the ticketing system and the forum.
Agreed. But would you still feel the same way about github, gitlab or another modern issue tracker?
There could very well be something I don’t see there but, AFAIC, I don’t see any feature the forum has when discussing features that github doesn’t have. On the other hand, I see small things that github does better (posting code, referencing anything to do with “code” like tickets, files, pull requests)
