Clean up Django tracker by a bot

[amk9978]

Wasn't sure where to ask but feel like here's the best place. I'm wondering why there are too many tickets that are not updated even though their GitHub is merged, some need improvement but are not ticked, or something similar. We can have a simple bot to update tickets and sync them with their GitHub issue status. At least for now, there are so many stale tickets that need clean up, update, de-assignment, etc.

[bmispelon]

Hi and thanks for contacting us, this is definitely the right place for this.

The ticket tracker tool we use (Trac) is normally set up to automatically close tickets when a commit is merged (based on the fixed #XXXXX in the commit message). Do you have links to a few examples where tickets stayed open even though their corresponding pull request was merged?

[amk9978]

@bmispelon
"Tickets that their PR are merged but still open" wasn't my point. There are so many other tickets that need maintenance. One scenario is that their "need to improvement" should be ticked after leaving comments while their PR is not merged. Another can be the de-assignment of stale tickets without recent activity. Btw, when there's a PR related to a ticket, their "has a patch" should be ticked, I suppose.
As a contributor I need:

1. Get to open accepted tickets that have no owner to work on (Some tickets have PRs but no owners)
2. Get to stale accepted tickets that need improvement/test/doc but their owners have left them, so, I can finish them up

Many tickets need to be cleaned up to meet the above needs, right?

[bmispelon]

Hi again, and thanks for following up.

Your original question was "why" and the short answer is that Django's issue system Trac comes from a time when github (or even git) didn't exist. A lot of effort has gone into trying to integrate Trac and Github, but I can agree that the experience is not perfect and can surely be improved.

A tighter integration between Github and Trac would be welcome, but I don't think it's as easy as you say (the current solution involves calling the github api via javascript from the Trac pages). Still, it's possible I could be wrong, so if you have some proposals I'd be happy to review them.

I also wanted to mention that closing or de-assigning stale tickets is likely not going to happen because the risk of false-positives is too high and in my opinion not worth it. Keep in mind that we welcome triaging contributions: anyone can change flags on tickets on Trac so if you see one where "has patch" is missing, we'd be very thankful if you updated it.

I hope that answers at least some of your questions. If you have more then feel free to ask here, on the forum, or on the #contributor-discussion on the Discord server.
Meanwhile I'm going to close this issue, but feel free to reopen it if you feel you have more to add.

Have a great day 🚀

[amk9978]

I can start a thread on the Django forum to see how much contributors (especially nonboard members or non-principal ones) feel at ease about finding the right ticket to kick off work and how much this clean-up is needed. Plus, there are several scenarios in which tickets need to be cleaned up and some of them like detecting patches that "need improvement" or setting the owner need integration with GitHub, but not detecting stale ones, for instance. Moreover, this bot can interact with Trac and doesn't necessarily need to be a part of Trac to be written in JS. Lastly, the Django community can define some definitions for stale and de-assignment circumstances.
Having some flags in the comment section of a PR (a possible solution) and syncing the ticket page with it doesn't seem hard.

[claudep]

@bmispelon wrote:

I also wanted to mention that closing or de-assigning stale tickets is likely not going to happen because the risk of false-positives is too high and in my opinion not worth it.

Just want to to kick in and voice my support for this assertion, having been bitten in the past by bots handling tickets automatically in a not-so-good manner. In my opinion, ticket triaging should mostly remain a human task.

[amk9978]

@claudep
Can you elaborate on that?
Detecting stale tickets without any PR can easily get done. Those unmerged PRs can be checked by the last activity (comment or commit). Setting the owner if the ticket has a PR is so simple. Finally, the setting needs improvement/doc/test can be handled by specific flags in the comment section which is set by the code reviewer and can be undone by the author, just like what should happen on the ticket forum, but unfortunately, we've seen many times that the reviewer doesn't set these flags on the forum after review.

[claudep]

In theory, all that seems simple. In practice, you have tickets with several PRs, you have old PRs with a comment saying that the owner will have time to finish in some weeks, etc. etc. Anyway, you can always ask for other opinions on the forum. Personally, I'm not for automating such tasks.