Feedback thread: Talk to us about the Feature Request process

We’ve migrated feature requests back to github discussions, the new process is . . .

  • Feature requests can be opened using the feature request issue template in github
  • We have a dedicated team of Grafanistas that will be watching for new feature requests and will tag them with the feature request label
  • When a feature request has a lot of activity in the form of unique reactions or comments, we will follow up in the issue to gather any additional information we need and move it to the squad that works on that part of Grafana

Tell us about your experience with the new process. If we missed something, tell us here!

1 Like

The discussions that have been converted to issues lost their upvote count.

For example Feature Request: Flux language - Visual Query Builder · grafana/grafana · Discussion #43848 · GitHub had 69 thumbs up and 39 upvotes, after being converted into Feature Request: InfluxDB, Flux language - Visual Query Builder · Issue #73432 · grafana/grafana · GitHub there are only 6 thumbs up at the moment.

Not a big deal, just pointing it out. Don’t know if those numbers carry any real significance anyway, hopefully they do serve as some form of indicator for how popular certain feature requests are, eventually impacting prioritization.

Hey @hterik, thanks for bringing this up. This is one of the downsides of the migration. Nevertheless, the discussion will be linked to the issue so we can always look back at the engagement in the discussion to assess its popularity. To make sure we look into them, we’re manually moving all discussions with high engagement directly to the teams so they don’t get lost.

We’ll be curating the existing feature requests that are already in github discussions. The requests that already have enough upvotes will be moved back into github issues and you can follow them there.

And the ones that didn’t get enough upvotes? Recently created discussions might be very valid but have not had enough time to get a meaningful number of votes yet.

What is the threshold for “enough”?

Also, could you share what went wrong with using Discussions for feature requests and why it was moved there in the first place? A lessons learned here would be invaluable for other open source projects as well, if you can spare the time.

@giovannitirloni we found that there were some limitations to discussions and that they didn’t get the attention we hoped they would because they were outside of the dev team’s projects.


  • Can’t link duplicate discussions
  • Poor integration with projects
  • Can’t convert a discussion into an issue. So if you use the “Create issue from discussion” button, only the initial discussion comment is copied over. Then the old discussion has to be manually closed.

And the ones that didn’t get enough upvotes? Recently created discussions might be very valid but have not had enough time to get a meaningful number of votes yet.

We’re planning to move recent (post April 2023) discussions into issues manually to allow them to collect more feedback and upvotes.

What is the threshold for “enough”?

We were intentionally ambiguous when defining the threshold. Our community squad will regularly review feature requests. We’re still fine-tuning the process to determine what “enough” interest in a feature looks like. The use case, benefit to our community, level of interest, and technical changes are all considerations.

1 Like