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
John H Palmieri wrote:
> I like the idea of mimicking the trac setup, but moving away from trac
> also lets us reconsider parts of the trac interface. I personally do
> not find the "Priority" label very helpful, other than whether it's a
> blocker or not. What do others think?
I agree about the
I think it's okay to not make things mandatory. For labels, I propose a
simple approach first: "Blocker" or not, "Bug" or not. (Currently, the
"Task" type isn't used much, so the major distinction is between "Defect"
and "Enhancement". Changing to "Bug" or not captures this.) I like the
There are two essential disadvantages of the issue form:
1. It is not available for PR.
2. The given structure is completely flattened after the issue has been
created. In particular, the entries of the dropdown menus of the issue
header are not visible (i.e. dropdown boxes are flattened to the
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
You can have advanced more advanced controls like checkboxes or
dropdownboxes in issue forms, see
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-githubs-form-schema#dropdown.
Some of this is used in
I like the idea of mimicking the trac setup, but moving away from trac also
lets us reconsider parts of the trac interface. I personally do not find
the "Priority" label very helpful, other than whether it's a blocker or
not. What do others think? We could just ask people to label "Blocker" if
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
