Proposal: replacing UserVoice with GitLab issues for feature requests

Dear ParaView community,

For years, we have had the ParaView User Voice for tracking popular feature requests for ParaView. The site is difficult to administer, it is not often checked, and there has recently been a surge of spam where feature requests should go. We would like to improve on this.

As a replacement, one idea is to use GitLab for feature requests. GitLab has several strengths that can mimic and even improve upon the UserVoice site:

  • GitLab issues offer thumbs up/thumbs down icons to indicate popularity for an issue.
  • When looking at a list of issues, you can sort them by popularity. With existing issues, that looks like the below image:

  • GitLab supports searching by tags. If we tag feature request issues with a particular tag, then listing them alone and sorting them by popularity mimics the UserVoice site capabilities. We already have triage:feature label, but might want a non-triage version of that.
  • New issues can be created from a link and pre-filled with a feature request template specified in the URL. The “Request a Feature” link at could thus be changed to a URL that initializes a feature request issue template that labels the new issue a feature and whatever other boilerplate is useful.
  • When a new feature is added, linking back to the original request and closing it is easy.
  • ParaView developers use GitLab all the time - as such, we will be more aware of highly requested features

We should be able to import the existing UserVoice issues into GitLab without much trouble, but I’m not sure about importing the vote tallies for each issue.

Thoughts? Concerns?

First, let me say I’m good with whatever direction we go.

However, I keep leaning towards discourse. I lean for three reasons that I can succinctly think of, none of which are overwhelming.

  • Discourse is for users. It’s where they naturally tend to go. Discourse is designed to be a clean interface for users. For instance, if a user wants to see what has been recommended before, said user can just go to, or search, a sub group. I think we should go where users are, rather than follow any specific tool feature.
  • GitLab has a lot of motion on it, thus recommendations will quickly disappear from the first (and second) page. Thus, as a general rule, users won’t see what other users have recommended. (Yes, they can use labels, but these are not intuitive the first time you go on site.). Does ANYONE remember what is on page 13 of GitLab? I don’t…
  • Last, frequently what users recommend gets rewritten anyway. This generally happens moving from UserVoice to GitLab, or from Discourse to GitLab. If we start in GitLab, some features will need to be rewritten anyway. Thus, I am not sure the benefit.

Anyway, my $0.02.

Oh, I forgot. GitLab has a weird bug (unless it has been fixed) that makes searches very effective within the BODY of issues, but misses searching through the TITLES. Again, it is a developer tool, not a user tool.

Alan, you make some good points. I think most of the useful features in GitLab have counterparts in Discourse, and I’m glad we’re having the discussion of the merits of both. It hasn’t escaped my notice we are doing so on Discourse :slight_smile:

My main things are a way to category requests and indicate popularity. Discourse does have categories, which are nice and easy to use, and you can “Like” posts to indicate popularity. The likes figure into the ordering of “top” topics, so popular features should be listed first

The biggest problem with Discourse posts is that once a feature is implemented, there isn’t a way to “close” them and remove them from the list of top requests. Maybe archiving the topic or making it unlisted would achieve that.

I’m confused. When I click on the wrench at the top of this topic, it gives me options to “Close Topic” and “Delete Topic”. Delete sounds pretty severe, Archiving or unlisting would keep it around, I assume, but not visible?

I’d vote for something on Discourse but haven’t thought much of how easy it is to actually implement it here rather than on Gitlab.

But yes for just replacing UserVoice. I went there recently but was pointed there by a topic on Discourse. Other than that I don’t think I’ve been there in the 3 years.

1 Like

I tend to go there about once a year, and cherry pick ideas. But, it would be much nicer to have the ideas in a more robust, healthy discussion space than out in the back desert…

1 Like

Any other input on GitLab vs. Discourse?

It honestly doesn’t matter to me, though I do think Discourse is more user-friendly for non-developers.

I’d go for it this way:

  1. Add a section for user ideas within this discourse
  2. User add new ideas but require admin validations (like tips and tricks)
  3. Other users can “vote” on ideas by liking them.
  4. Once an idea reaches a treshold (10?), initial poster open an issue (or tag a dev to open an issue) on gitlab, adding bidirectional links.
  5. Gitlab issue is picked for devlopment by a funding project or a dedicated dev
  6. MR created and merged, gitlab issue closed, discourse topic “resolved” with a link to the MR
1 Like

One last step - Discourse posts can be made “unlisted” which means they will not appear in the list of topics in a category. Discourse admins can apparently still see them, but they are marked with a crossed-out eyeball, so that should make it easy to skip over implemented features in the list.

1 Like

To follow up, I created a “Feature Requests” category currently only visible to moderators. @wascott, when you are ready, do you want to populate it from the existing user voice entries? Maybe cut off requests below 10 votes or so?


Will do, next week. This week I’m in Colorado without good internet.

I took a quick look, many of these ideas are either outdated or already implented in ParaView.
Let me know if you want me to do a pass on them and add comments to them in order to flag these.

Thanks Mathieu. If you want to move the uservoice suggestions, that would be great. I’m still trying ti dig out resolving your closed bugs from the hackathon.

All the user voice request with more than 22 votes have been created in the new category except:

I will tackle the rest later.

All the user voice request with more than 10 votes have been created in the new category except:

IMHO the next steps are:

  • Close uservoice for contribution and vote but keep as read only
  • Open the feature request category to the general public
  • Make a announcement in announcement category (and in blog?)

Let me know if I can help.

Looks good, Mathieu. I’ll ask the publications team to change the link on from User Voice to this category - once they do, I’ll flip on visibility.

I think an announcement on Discourse is warranted. Blog post - maybe?

The category is now open and linked from

Anyone can create a feature request, but new topics require moderator approval.

1 Like