I think there are two steps to be taken. The first step is to define a suitable template to collect all the important information in the header of issues and PRs that we are used to from the Trac ticket box.
In terms of dependencies between PRs, this will map what we are used to. The second step according to discussion 4477 will go beyond that. So this has a lower priority. But it will be nice to have!
As for the first step, I would suggest having templates that mimic the Trac ticket box for example:
$ cat .github/ISSUE_TEMPLATE/trac_ticket_like_issue.md --- name: Issue according to Trac ticket about: This template provides a similar structure to a Trac ticket title: "[Short Description] " labels: 'p:major' milestone: 'sage-9.8' assignees: '' --- # Checklist for creating a Trac ticket-like issue - [ ] I have read [README.md](https://github.com/sagemath/sage/blob/develop/README.md) - [ ] I have read [the Troubleshooting section in the Installation Guide](https://doc.sagemath.org/html/en/installation/troubles.html) - [ ] I have checked that this will not be a duplicate - [ ] I have chosen a label from the <details><summary>Type list</summary><ul><li>t:bug</li><li>t:enhancement</li><li>t:task</li></ul></details> - [ ] I have chosen a label from the <details><summary>Priority list</summary><ul><li>p:blocker</li><li>p:critical</li><li>p:major</li><li>p:minor</li><li>p:trivial</li></ul></details> - [ ] I have chosen a label from the <details><summary>Component list</summary><ul><li>c:algebra</li><li>c:algebraic geometry</li><li>c:...</li></ul></details> # Information that used to be in the Trac ticket box ||________________________________________________||________________________________________________| |-|-|-|-| |Authors||Reviewers|| |Keywords||Report upstream|| |Dependencies||Stopgaps|| # Description of the issue
This would also help with the change of habits. But it seems that this cannot be done only through appropriate templates. As far as I’ve seen, there’s no way to have radio buttons or select lists with GitHub markdown, even with plain HTML. Therefore, we would also need to implement corresponding GitHub actions (see also my comment on issue 8 in the trac-to-github repo). These would be needed to synchronize between corresponding Trac and GitHub features, too.
If there is interest to have such a template I can volunteer to produce a first draft (but maybe this will take a while since I have only short time-slots and I’m inexperienced with these GitHub tools).
Probably better to use labels, since we see issues change from blocker to not and then back again, so having different templates would be cumbersome.
I agree! In general the predefined structure of templates is not guaranteed to be preserved through the live of an issue / PR as we are used to with the Trac ticket box. Everyone with write access can destroy it. Surely this will demand a higher level of discipline among developers.
A broader question is, which parts of the trac interface do we want to keep, and which parts can we dispense with? Also, where is the right place to have this discussion?
I don’t know. Maybe a Trac ticket, since this must be clarified before we migrate?
More generally, I see little benefit in trying to stay close to the format of trac tickets.
I didn’t think of having this as the default template. Just an optional template for former Trac users who are less familiar with GitHub (like me). But as I’ve now seen, templates and issue forms aren’t the right tools for an interface, and it’s probably harder to do than I expected. Perhaps it would be sufficient to have a reference to the migration documentation in all the templates we offer, at least for the initial period after the migration has taken place.