Improve the GitHub issue forms #108881
Improve the GitHub issue forms #108881
Conversation
|
Possibly we could also get rid of the "Error messages" field in the "crash report" issue template -- thoughts? Reporters can probably just incorporate that information into the main field giving a description of the crash. |
.github/ISSUE_TEMPLATE/feature.yml
Outdated
There was a problem hiding this comment.
I think for features having the link to previous discussions at the top is useful, as it's only a single line
There was a problem hiding this comment.
The feature-request template is the one I'm most torn about when it comes to the ordering of fields. We used to get a high volume of "feature requests" asking for significant changes to Python's syntax or other major new features. I think asking people to show that they've discussed their idea somewhere else before, and having that as the first question in the template, has helped significantly reduce the volume of these feature requests. Moving it down below the main issue description significantly increases the chance that these newbies will just ignore the question (or won't even see it), I think.
However, @serhiy-storchaka pointed out that the current issue form means that link previews to feature requests on e.g. Discourse now render quite badly -- you can only see the boilerplate in the link preview: https://discuss.python.org/t/generalize-replace-function/28511/19 is an example. There's the same problem with the #github-issues channel in the core dev Discord: the feature-request previews are now overwhelmingly dominated by the boilerplate-y fields.
There was a problem hiding this comment.
It looks like Discourse cuts off at ~80 characters -- just the heading of "# Feature or enhancement" is a third of that limit, so I'm less convinced by the "Discourse link preview" argument (& it might even be a configurable setting in the Discourse back-end).
I don't tend to use aggregators though, so my view is limited by that perspective.
| description: > | ||
| Give a clear and concise description of what happened. | ||
| Include a [minimal, reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) if possible. | ||
| [Copy and paste code where possible rather than using screenshots](https://meta.stackoverflow.com/a/285557/13990016), |
There was a problem hiding this comment.
Some parts of this answer are Stack Overflow-specific, but the vast majority isn't, and it's an exceptionally good explanation for why pasting screenshots of code is bad
This comment was marked as resolved.
This comment was marked as resolved.
This addresses feedback on the core dev Discord, that it's too hard to read the rendered versions of issues on the tracker now, due to the fact that the "boilerplate-y" fields such as the Python versions tested on are at the top of the template, and these have to be skimmed past before you get to the core bug description itself.
The changes are:
python -VV. In some situations this is useful, but most of the time it's not, and this field is adding noise to every rendered issue report. In situations where we actually need this information, we can just ask the reporter for it. I've kept this field in the "crash report" template, though, for two reasons: firstly, this information is more likely to be useful for crash reports; and secondly, we get many fewer crash reports than we do bug reports, so the concern about adding excessive amounts of noise to the issue tracker has much less weight.As before, these are already merged into the
mainbranch on my CPython fork, so you can try out making issues at https://github.com/AlexWaygood/cpython/issues/new/choose to get a feel for what it's like.Examples of rendered issues:
concurrent.futuresAlexWaygood/cpython#22