The PR by @Sukera on a new issue template triggered a wider discussion about what GitHub issues are for, and how they should be used in the Julia language repo. On the aspect of feature requests, @viralbshah said the following (please correct me if I misrepresent your position, I just want to get the thread started):
In general, we do not invite feature requests through issues. […] Lots of feature requests are issues are open ended discussions. […] 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 should go to discourse.
Personally I thought it was very surprising, and a rather major unspoken policy (if true). But I don’t want to presume of other people’s opinions, so I’m asking: where does the community stand on this?
To be fair, the policy is not entirely unspoken - CONTRIBUTING.md does mention this explicitly, though what happens in practice on the issue tracker is a different story. There are lots of issues being opened (& seldom closed!) that are, in essence, feature requests. Just on the current page 1 of issues alone, I’d classify all of these as feature requests of some form or another:
(that’s 6/25) and there are bound to be lots more on following pages. So either the current policy is wrong and feature requests are supposed to land on the issue tracker, or the issue tracker is not being maintained up to the standards CONTRIBUTING.md sets for the repo. Either way is something that ought to be fixed, IMO.
What’s more confusing is that the existing issue template explicitly calls out feature requests as being desired on the issue tracker:
<!--
If you have a question please search or post to our Discourse site: https://discourse.julialang.org.
We use the GitHub issue tracker for bug reports and feature requests only.
If you're submitting a bug report, be sure to include as much relevant information as
possible, including:
1. The output of `versioninfo()`
2. How you installed Julia
3. A minimal working example (MWE), also known as a minimum reproducible example
If you're experiencing a problem with a particular package, open an issue on that
package's repository instead.
Thanks for contributing to the Julia project!
-->
So which is correct, the existing issue template or CONTRIBUTING.md? Which are people more likely to see & follow?
I would say that open-ended feature discussions, where there is a lot of uncertainty about whether the feature is desirable or what it should look like, may be better for discourse. But focused requests (e.g. #16032: Implement in-place circshift) seem better on github to me.
e.g. on github, feature requests can be more easily cross-referenced, can be marked with tags like “good first issue”, can be auto-closed by PRs, and so forth.
In my experience, the line between bug report and feature request is often quite blurry and biased. With some broad generalizations, users typically see gaps in functionality as usability bugs and report them as such (I’m quite guilty of this myself with other software I use; I’ve lost count of how many times my bug reports get reclassified as feature requests). Developers tend to see these things as feature requests — it’s quite often technically new functionality. But these reports tend to be quite focused and actionable, either way.
On the flip-side, though, when someone who isn’t a developer comes to you knowing they have a feature request, those are the things that tend to be more abstract, less actionable, and more discussion-based.
So messaging necessarily needs to tackle both perspectives.
That’s very true, but I think trying to seperate the developer view from the user view in terms of where a given topic should be discussed is a bit of a difficult problem to solve, especially in a way that leads to minimal overhead for a developer. For example, this issue:
might ordinarily be seen as missing functionality/a usability bug that should be easy to implement. As it turns out though, it’s anything but - there are quite a lot of specific considerations & decisions that need to be made. Should the original poster have known of them, and posted to discourse instead? Obviously, that’s absurd - they can’t necessarily know of the complications that may arise when trying to implement something, anything. Moving the discussion afterwards to discourse after it becomes clear that it’s not so simple also feels a bit bad - the information of who wrote what from the original topic is likely to be lost.
I think for a user who’d report a “usability bug” it’s often quite difficult to judge where things should go, and as such, making it easier for them as well as developers (by e.g. clearly using github labels to give developers the option to filter for self-selected bugs, and ignore explicit feature requests - these can be automatically applied from a template!) ought to be a boon.
I’m not really trying to separate these views; I’m describing my experience that there exists a wide gulf in the definitions and expectations folks have here, and that from the outside some missing functionality can feel like or even manifest as a bug (in any system).
So in that light, I was just thinking about the kinds of issues I’d generally expect (perhaps overly cynically) from a pair of buttons that say “Bug Report” and “Feature Request.”
Right! I wasn’t trying to imply that that was your stance, just that that’s what the current policy from CONTRIBUTING.md seemingly tries to achieve
That’s perfectly fair, and while I don’t think it’s possible to get a perfect seperation (false positives/negatives are bound to happen, as with my example above), I do think that relegating “feature requests” off of the issue tracker is likely to lead to more organizational overhead.
Github Discussions could be a solution there, as it allows us to fluidly convert to/from issues/discussions (albeit with the caveat that the two discussion formats are different - one is a single thread of replies, the other is a tree of conversations).
Regardless, the main concern is with what the stance is/should be, and what exactly we want to optimize for.
The main problem with Github Discussions, in my mind, is that it is basically a replacement for Discourse. I don’t want to have to keep track of yet another forum.
If someone opens an inappropriate issue on github (e.g. a help request, or a too-open-ended “feature” discussion), I would just close it and direct them to use discourse.
But then again, the set of people with a Julia Discourse account is much smaller than the set of people with a GitHub account. My fear is that if we ask feature requests to be made on Discourse, we will lose most of them cause users outside of our community won’t bother. And that seems worse than having longstanding open issues.
A number of projects on GitHub make use of labels such as feature request and needs discussion (often with some kind of automation) to help categorize such issues. Has this been attempted in the Julialang/Julia repo, and if not why not?
RE Discourse, I agree that trying to sequester such requests here is likely a losing battle (experience suggests people will keep posting issues). It may be easier to “spill over” longer discussions to Discourse once they’ve started on GitHub, with labelling and thread locking on the GH side as appropriate. Regardless of the approach, it might help to have a (sub)category dealing with such discussions (maybe under Internals, though that root category is likely too scary for most people to check without prompting)
One advantage of using github issues for feature requests is the possibility to organise and make them more visible through a voting board system.
I am a big fan of the solution used by python’s executablebooks community:
There is a clear list and users can directly indicate which features they are interested the most.
In context of recent heated discussions about priorities for Julia, this could be a way to better probe the community than discourse topics with hundreds of posts.
Saying no is hard. People can get offended, they want a justification, some will debate. I know I have. This surely takes a lot of time and energy from the julia maintainers.
I also find it hard to believe that there are “really good feature requests” out there that don’t make their way to github.
I do want to post some data here. We have 20,000 registered users on the Julia discourse. On Julia github we have 1,500 contributors - I do not know how to count the total number of users who have posted or commented on an issue, but I would guess it is a few thousand users (since we are at about 51,000 issues).
It’s not the people already in our community (and thus likely to be on discourse) @gdalle is talking about though, but those folks from other communities that maybe pick up Julia and notice that there’s some small thing that’s missing. Should they be directed to discourse too? Conversely, how should people who don’t have a discourse account but would like to help out discover features that they can actually work on - should they too have to scour through PRs & posts on discourse to figure out whether the feature they found here has already been implemented, but just not released?
My personal worry is that this transforms the issue tracker into some form of “elite club”, where only esteemed members get to “hang out”.
Especially such folks should (typically) go to discourse. Those kinds of questions are less likely to be reasonable feature requests than newbie confusions about the language or its ecosystem.
Notice how I explicitly wrote that they already picked up Julia, and that they want to contribute something. In other communities, it is usually custom to open an issue for discussion first. I’m not talking about “Hi I want X thank you bye!” style queries.
I don’t think it’s helpful to them to first having to open a thread here, and then link that back on a PR, instead of just referencing the issue (especially because of the organizational overhead on our end to then mark the thread on discourse as resolved). It just seems a bit backwards to want to reduce organizational overhead through a measure that objectively increases organizational overhead
Maybe I should be a bit more specific. Currently, we have one issue tracker for both language development, as well as stdlib development (bugs and features alike). When people say “We don’t want feature requests on the issue tracker”, are you talking about language features, stdlib features, or both? Or something else entirely, like specific methods for some function?
I entirely agree that a big language feature discussion should not happen in an issue. But that still leaves the other forms of features open.
Perhaps so with smaller projects and libraries, but as @jarijishowed it’s quite a mix. With larger projects, I’ve found that I always have to acquaint myself with the norms of every different community before being able to post appropriately.
Rust: pushes feature requests to discourse in their new-issue form, but uses the enhancement label for targeted feature-y issues
CPython: pushes feature requests to discourse, but allows using issues after a discourse discussion that shows support
Additionally:
Numpy: asks for both a discourse thread and an issue simultaneously
Scipy: uses issues
It’s a mix — and in my view, I think this is very reflective of the blurry lines and wide variety in feature requests. There’s a distinction between explicitly inviting feature requests as issues and using issues for some feature requests.
It seems the big takeaway from that list is that some kind of structured process is a good idea. Is there enough support on the Base side to experiment with (and adhere to, for the duration of the experiment) an approach along these lines?
