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.

1 Like

@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

This feature request has been open for almost 6 years. Would love to see this one get some attention. @melori.arellano.

At the time of making this post 166 thumbs up on this request. So the community surely wants this.

I feel like the process could be impoved if it has X amount of thumbs up and X amount of time has passed that comments could be made. I.E (Going to add this one to Q1 of 2024 for a Spike, Not possible due to limitation in design, etc…) Leaving the community without context for so long stinks.


Hey @myleshoule, thank you for your feedback!

We aim for the process to work as you described. We are trying our best to stay on top of these highly demanded requests and we definitely want to give context and updates to the community.

As for that request in particular it’s been challenging to address due to architectural limitations. Nevertheless, we’ve been working on a new frontend architecture for dashboards and this is one of the features that will make it as part of the first iteration of improvements. We’re aiming to release this in the next couple of months. We will keep the issue updated.