A new issue template #50881
A new issue template #50881
Conversation
|
Ah shoot, I should have done the |
|
Perhaps the |
|
That's a good idea, thank you! I've changed the template to ask for the installation method. |
[ci skip]
|
I like how these other projects link to their discussion forum explicitly, to redirect users that just want to ask a question. Added! We may want to link to the community link collection https://julialang.org/community/, if we don't want to give discourse preferential treatment. |
Totally fine to just link directly to discourse. |
|
Personally, I really dislike these type of intrusive templates (that has UI elements like text boxes). If it is just text it is easy to Ctrl+A backspace to remove everything since in 90% of the time the queries are not relevant to the issue that is being opened. |
I don't mind templates - but I don't like really busy ones (when I am filing issues elsewhere). In any case, at the bottom, github shows a link to go directly to a blank issue. |
Yes, every time I use a template like this I have to keep fixing formatting errors afterward, fill in useless information that the template enforces, or have to write things in an unnatural way. As for the issue template here, having two input text boxes with "What happened?" and "What did you expect to happen?" is often not how you best describe the problem. And it sometimes leads to silly things like "Blah computes the wrong value" + "I expected it to compute the right value". |
Do you feel the one in this PR is too busy? Where could it be slimmed down? What should be dropped from the template? Please be as specific with your feedback as possible, to make it easier on me to incorporate into the PR.
Right, but asking about the expected behavior explicitly is purposeful - it frames the bug report in terms of asking the user what they actually did expect to happen, which can help with formulating a better report by incentivising the user to create a mental model about what their expectations were & how things work. That's some work maintainers then don't have to do in a Q&A style questioning. There is of course potential for doubling of information, if someone puts the "I expected x to happen" part in the "I took these steps" portion of the template, but no template is going to catch people putting in stuff in the wrong order 🤷 |
|
As specific feedback, I think the "What did you expect to happen" should not be a mandatory field. In general, we do not invite feature requests through issues (the exception being very specific design discussions around language features). I wonder what others have to say about that. |
|
Where, if any place, should feature requests be redirected to instead? |
discourse. |
|
Should that be a specific category on discourse? After all, it's not uncommon at all at the moment to have an issue for adding a specific method to existing functionality and have that be tracked on here. This would represent quite a significant shift in how small-ish PRs for newcomers to the repo are discovered & tracked. Additionally, this will have the sideeffect of having to maintain two labeling schemes for different parts of the repo, once here and once on discourse, as well as having to take care to link PRs & discourse posts (and perhaps post some message on discourse to indicate that the feature has already been implemented). So just that I'm understanding it correctly - that's the goal? |
I'm very surprised to hear that Discourse is considered the best venue for feature requests. From what I can tell, it would be a significant shift from the way most open source software works. Of course longtime community members do float their ideas on Discourse first, but I'm not sure we can expect that from everyone. Care to elaborate @ViralBShah ? |
|
Most open source software actually worked on mailing lists - github is only a recent phenomenon, if you think about it. Issues are about filing problems, bugs etc. which have actionable items to fix. Lots of feature requests are issues are open ended discussions. In smaller projects, you can use the issue tracker to track open feature requests, but it gets quite overwhelming when there are hundreds and thousands of these. This is why Github also launched Github discussions - to separate from issue tracking. The goal really is to "address the issue" and close for an issue, whereas discussions can stay open ended and there is no expectation to close them. Feature requests range from - a missing method to complete something (closer to an issue and actionable) - to I want to compile binaries from my Julia code, or I want a different type system or I want better plotting (open ended feature requests). Those discussions are not appropriate to be had in an issue tracker and in the past have led to considerable noise on the issue tracker. The lines are blurred, and naturally you can find exceptions. |
|
Now I'm just confused. Should feature requests go to discourse, a mailing list, or github discussions? What is the clear direction this PR should go in?
But you can & are expected to resolve/close discussions just the same..
What should the policy be? Should this PR be a discussion instead, since there clearly isn't consensus/a consistent view how the issue tracker is managed/used? |
|
I believe I clearly responded earlier that in my view feature requests should go to discourse. To the question that @gdalle asked, I explained how different open source projects do things, and that issue trackers are not necessarily the only right way to discuss feature requests. For me, the clear way forward is:
At that point, we can merge and see how it is received. I do believe it is a worthwhile experiment to try out and then decide if we like it or not. Separately, for Feature Requests, we can have a separate PR if we can adequately explain what constitutes a feature request that would make sense to file here - that captures the spirit of narrow and actionable, rather than broad and open ended, which should be discussed on discourse. |
|
Gotcha - your reply just read to me as if mailing lists or github discussions were also on the table, after @gdalle asked. To be honest, I can't really see a path forward for this PR from my side if we're just going to drop feature requests entirely. Not even having a mention of it is certainly going to be confusing for users; quite a lot of new issues are "feature requests", asking for new methods etc. |
|
You are mixing two things in this PR - an improvement to issue reporting which is mostly ok, and also codifying a change in the way we do things today around feature requests. My suggestion was to split into two parts for that reason so that the first part can be merged. However, from my perspective, there isn't a great urgency, and we can wait until more folks chime in. |
|
I really don't think having a template for "feature request" is codifying a change in how the issue tracker is currently used though. Just on the current page 1 of issues alone, I'd classify all of these as feature requests of some form or another:
So that's 6/25 (at least, these were just the ones I felt confident in classifying as feature request), and some of the later pages of issues surely have more. Now if those all shouldn't be on the issue tracker because they're feature requests - ok, but booting those kinds of issues off of the issue tracker is a very big change in what is actually being submitted & tracked on here. I'm not trying to change any process here - I'm trying to figure out what the current process even is in practice, so that it can be made easier for users unfamiliar with the project to jump in & help out. |
|
If I may, the "way we do things around feature requests" (at least Viral's version of it) was not clear at all for me, and I suppose the same would hold for many community members. If it really is a general rule not to put feature requests on GitHub, or if core Julia devs want it to be, then it's the first time I'm hearing of it. Would this warrant a (Discourse) discussion, where more folks can chime in? |
Implements #50861
This is based on the Issue forms feature by Github. You can try it out on my fork of the repo; if you want to experiment with this yourself, note that you have to make changes on the
master/main branch of your repo, since that is the only place github will look for these templates.Note that this still preserves the ability to create a blank issue, right below the "Bug" and "Feature Request" buttons.
I also ironically don't know what to label this PR as - we don't have a "repo" or "meta" or "issue tracker" label..