chore: replace issue templates with forms #11772
Conversation
|
Oh and instead of automatically adding a "Needs Repro" tag on creation, my proposal includes adding reproductions as a requirement. I feel dropping this tag would help reduce visual noise in the issue tracker, since as long as the tags are not managed they don't really serve a purpose. And making reproductions mandatory might increase the likelihood of the submitter actually providing one - saving us having to ask for it. This should also make moderation easier; issues where reproductions are omitted could simply be closed with a standard reply referencing the requirement. |
Codecov Report
@@ Coverage Diff @@
## master #11772 +/- ##
==========================================
- Coverage 69.01% 69.00% -0.01%
==========================================
Files 312 312
Lines 16339 16339
Branches 4736 4736
==========================================
- Hits 11276 11275 -1
- Misses 5035 5036 +1
Partials 28 28
Continue to review full report at Codecov.
|
|
Yes please, this is something I've wanted to do for some time! 🎉 Is there some editor I could preview how this'd render, or do I need to stick it in some HEAD and try it out? EDIT:
My reading comprehension needs some work apparently 🙈 |
|
I didn't know that was a thing. This is amazing, thanks for working on this. |
Hehe! Yeah, feel free to create some issues and play around with it. The files there should match this PR. Unfortunately the preview capabilities around this feature is still very limited; it has to be in the main branch of a public repo. Also makes it a little cumbersome to work on; as you have to commit to preview changes. 🙈 |
I'm extremely grateful for this ❤️
Very much so! I still think linking to SO is good (to not seem like we're the "only" ones asking for this), but clearly stating we want a reproduction to pull down rather than snippets would be awesome. Happy to have a page on the website describing this 👍 |
There was a problem hiding this comment.
Awesome!
I'd personally change the order to
- reproduction
- expected behavior
- actual behavior (used to be called describe the bug)
because I think it reads nicely, and people are likely to be clearer about expected vs actual. Otherwise I believe they'll put a lot of info into 'describe the bug' that really belongs into additional context
That makes me very happy to hear! And right back at ya'll, for everything! 🤗 My hope is that if I'm able to take some load off with peripheral tasks such as triage and light code-review chores (e.g. changelog reminders 🙈), you get to focus more of your time and energy where it has the largest impact. 💥 And it doubles as a good excuse for diving into and slowly but surely building up my understanding of the codebase/internals 🙃
Roger that 👍 - I'll get a draft going for this as a separate PR then.
Thanks for your feedback! I added another layout based on this next to the original one for comparison, where I also lifted the "Additional context" field to group them together. Original: https://github.com/sigveio/jest-issue-templates/issues/new?template=bug.yml Could "Actual behavior" be unclear for some? (e.g. non-native English speakers) |
|
Yeah what you did there seems good to me, I prefer the alt now, idk about @SimenB
I know that Germans for instance like to think actual means "aktuell" (current), but that seems like a non-problem since it still makes sense in this context |
|
I now also moved the "Version" field up to the very top in the "alt" version; as I'm thinking this might prompt more users to check whether the bug has already been fixed before going further. |
I prefer the alt as well 👍 |
sigveio
force-pushed
the
new-issue-templates
branch
from
12a3661
to
4a5469a
Compare
|
Let's do it 👍 Can always iterate further. Thanks a bunch @sigveio! |
|
And bam 💥 - first issue (#11781) posted with the new format already! Looks good! 😁 @SimenB I notice the label isn't auto-assigned to the form for There's two possible fixes:
The benefit of number 2 is that it looks prettier in URLs and search:
(If I were to be picky... I'd consider moving the icons to the end of the labels also. Because they have weird spacing when text is following.) |
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Summary
I propose to replace the issue templates with the new fancy issue forms GitHub now supports. ✨
Why? More relevant information/guidance can be displayed, and fields can require input.
You can demo them here (feel free to play around and create issues):
https://github.com/sigveio/jest-issue-templates/issues/new/choose
I opted to remove the "Regression Report" altogether, since I feel it would provide limited additional value to the new bug report form. Many users experience various issues when upgrading major versions, and whether they currently use a bug report or a regression report seems rather arbitrary. Suggesting they get confused on what to use.
The "Questions / Help" one is just an info page similar to how it is today, but without input fields... and with an added guard against submitting. Hopefully this leads to less users simply ignoring it and posting their question anyway.
Motivation
Lately I've been trying my best to give a hand with the issue tracker. But there are a lot of unnecessary bug reports, and it can be tricky to answer in a way that does not upset the person making them. If you give too much help, you potentially encourage more people to attempt using the issue tracker as a help forum. And if you reply with "Saved Replies" merely referring to other resources it can also feel dismissive and cold.
Hopefully providing slightly improved structure and information at an earlier stage could help "nip it in the bud" and mitigate that. And also give us something better to refer users to when needed.
What else can we do?
Expanding the Jest documentation with a page on reporting bugs could be useful. With an overview of some essential things to consider before doing so, and Jest-relevant information on creating good and relevant reproductions. I feel the StackOverflow guide that we tend to link to on this, is a little bit too specific to posting to that platform. For example asking them to "Use individual code blocks for each file or snippet" - while we'd rather have a ready to run GitHub repository.
I'd be happy to draft something, if you agree.