-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue templates plus #2681
Issue templates plus #2681
Conversation
@@ -0,0 +1,26 @@ | |||
--- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm not sure about this, I'm thinking it might be confusing for users, the more options, the more thought that will have to go into this (i.e. more friction), and therefore reduced number of reports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that too many options is a bad thing as well, but I've found that some issues just can't be boxed into either "fix bug" or "build feature", because they are about improving things that are working fine, just could be made better – perfected. That may for instance include refactors or UI cleanup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for addressing the feedback! This would be my only outstanding issue with the PR.
I still have this feeling that this will detract more than help. If a user wants to report an imperfection issue, they'll choose one of the categories and we can tag it later. My concern is that deciding between enhancement and imperfection is not clear-cut (as for instance deciding between enhancement and bug report). Basically I'm trying to follow a Don't make me think principle.
Having said that, if you still think it's the right call feel free to merge as is, worst case scenario we can remove it in a few weeks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not actually supposed to be a choice between "enhancement" and "imperfection", but between "feature" or "imperfection". So it's more clear-cut (though I agree maybe not 100%) – both are enhancements, but one is about adding a feature to PostHog, the other about improving an existing feature. I feel like at times with the current simplistic distinction between "feature" and "bug" we are making you think, because for example a refactor idea isn't an actual feature, so does "Feature request" apply to it? – it definitely can be considered perfecting the software though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I'm not actually sold on the specific wording "imperfection" myself though… I'll give this some more thought later, but for now merging without Imperfection report.
Rewritten abouts and reworked the Environment section. |
Changes
Slightly reformatted existing issue templates and added ~two~~ just one – holding off on Imperfection report – new ones:
- Imperfection report - for things that could be improved, possibly are slightly annoying or detrimental, but don't really qualify neither as a feature nor a bug (e.g. UX that could be simplified)