Trac migration informational DEP - Feedback required

[alexgmin]

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:

1. Support for “reports”
2. Support for extra metadata fields
3. 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?

[timgraham]

• 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:

• To go along with community triage, as far as I know, it’s impossible to assign a GitHub issue to someone not a member of the repo’s organization.

• Trac supplies data to https://dashboard.djangoproject.com/.

• 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:

[carltongibson]

All I can really do is quote my comment from the other thread:

@carltongibson

The history. It’s absolutely impossible to work on Django without it. A hard criterion on any option is that we can’t loose that. And it can’t become impossible to filter/search. (This last is a problem with GitHub issues. DRF, for example, a large project that I’ve worked on at length, is much harder to find related issues on, despite probably having only a tenth or less of the history.)

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.