-
-
Notifications
You must be signed in to change notification settings - Fork 7.8k
Add more specific GitHub issue templates #18161
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
Conversation
I also moved the ISSUE_TEMPLATE.md to ISSUE_TEMPLATE/bug_report.md so that both feature requests and bug report templates will show up after clicking the new issue button
Thanks for opening this!
|
@story645 are you asking for all these categories to be implimented? Whats the next step here? |
No, just the Bug and New Feature is great! I'm just putting this here cause we already agreed on it on a call and it's kind of a pain to pull up. |
* Add an option so that when [...] [...] will happen | ||
--> | ||
|
||
### Additional context |
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.
### Additional context | |
### Additional context and prior art |
--- | ||
|
||
<!-- | ||
Welcome! Thanks for thinking of a way to improve Matplotlib. If this solves a problem for you, then it probably solves that problem for lots of people! So the whole community will benefit from this request. |
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.
please fix the line breaks....
I'd just shorten to Thanks for thinking of a way to improve Matplotlib.
and leave off the rest.
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.
please fix the line breaks....
Do you mean inside the paragraph or do you mean how the text is positioned relative to to the comment lines?
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.
Just we wrap most lines at 79 characters. Of course not as big a deal with a markdown file, but...
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.
got it. Would you be open to avoiding that rule in the issue templates? As they are prose rather than code I think it makes more sense for the github issue editor/browser to handle the reflow/wrapping. For example the line wrapping at 79 characters in the current issue template feels unnatural to me:
There are a few other places in the feature request template where I went over 79 lines, and the existing bug_report template seems to have inconsistent enforcement of this.
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 don't feel strongly about this, but others do. I think unless there is a good reason (i.e. it'll make horrible line continuations) we stick to 79 characters.
I added a template for each of @story645's suggestions. I used the |
Thanks! Maintenance is probably the best fit for those sorts of things. |
I don't want to bikeshed this PR to death, but to me "Enhancement" != "maintenance". You don't enhance your car by changing its oil, but it is maintenance. I'd say add the new label, but I'm content to be told how wrong I am. 😉 |
Ryan these are for clean ups & enhancements, which I think folks have been tagging maintenance? There's a seperate issue template for new features and we just discussed on the call how we don't want a standalone enhancement tag cause nobody knew what it was for. |
I would not include the "Enhancement.md" at all. We already have "Bug or issue" and "New Feature", and its hard to think of an "enhancement" request not covered under one of those two templates. |
From the July 20th meeting notes replace "enhancement" with "new feature"
& this would be for stuff tagged https://github.com/matplotlib/matplotlib/issues?q=is%3Aissue+is%3Aopen+label%3Amaintenance |
I'm confused about what you are trying to say @story645. Are you arguing for keeping |
keeping it as a template for maintenance type issues |
Which recent issues do you wish the user had used the proposed "Maintenance" template for? Because I don't see the benefit from the user's point of view. |
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.
minor nitpicks but can also be handled by anybody else when they tweak the templates.
Co-Authored-By: hannah <story645@users.noreply.github.com>
Can we also add something like "I don't know what I want" that redirects to Discourse? |
@QuLogic some other projects make a "question/support/other" type template that explicitly says something like the issue tracker isn't for this sort of thing so we're most likely going to close this issue and you should use one of our other channels instead. Here's the scikit-learn version: |
So in summary the conclusion is to have the following:
Is that a fair assement? If yes, shall I set the label for enhancement to |
I think we might have crossed wires a bit. We don't have an For performance and small improvements, we can lump that together with cleanup and label it And to answer another question, Enhancement != Maintenance, but the difference here is a matter of scope. If it's an Enhancement that requires a What's new entry (maybe also for API notes too), then the Enhancement is a New feature. If it's an Enhancement that makes the library 'better' (for some definition of 'better'), but isn't user-visible, we'll call it Maintenance. |
In terms of concrete to-do:
|
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.
Not sure if labels are case-sensitive.
case sensitivity. Also put discourse link before SO to prioritize it.
I belive that the line at the top would have stopped github from picking this up as a valid template.
not only that but there was an extra line at the top of the file that I believe would have caused github to not pick up the template. I think they all should be good now |
# This template is based on the scikit-learn template | ||
# https://github.com/scikit-learn/scikit-learn/blob/8e61534f1087703f476414d8dbd3688282f8eebf/.github/ISSUE_TEMPLATE/usage_question.md |
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.
Going back and forth on whether this needs to be in here...
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 won't show up when someone makes a new issue as it is a comment in the yaml frontmatter rather than in the markdown body. See example here: https://github.com/ianhi/git-expt/issues/new?labels=Question&template=test.md and the source file https://raw.githubusercontent.com/ianhi/git-expt/master/.github/ISSUE_TEMPLATE/test.md
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 the clarification.
Thank you @ianhi for knocking something off my to do list 😉! |
Thanks @story645 for helping get it through! I really appreciate having nice templates when I open an issue |
PR Summary
Closes: #18160
New Feature
label.The feature request template is an almost exact copy of the jupyterlab template but I wrote the jupyterlab version so I think it's fine to just copy it w/o attribution.
ping @story645
PR Checklist