We have some very important users, actually they are our dealers. Their votes are much more valuable and professional comparing to usual users. So, we need a possibility to look, who voted for the feature in order to interpret voting results correctly.

Understandably, a user won't look past the first page of feature requests, hence, the probability is high that a duplicate/similar request will be posted. Merging a request to an existing one, will allow the user to be notified about 1) the merge 2) status updates on the other (prior) request. Thanks

Would like explicit support for WP multisite; or at least install on a sub domain; currently use WP Ultimo and it would be good to extend functionality to the sub sites.

Right now notifications are sent to the admin email address for the site itself. I'd like the ability to set a different email address for admin notifications from SFR so I can route the emails into my feature requests list in HelpScout. Bonus points for a Reply To: option that contains the user's email address, […]

When creating a new request, I would like users to fill out as much as possible themselves. Specifically, I want them to choose between "Bugfix", "Integration", "New Feature" - as the request starts in "pending" status, we will review and amend the category when needed.

Would be great to have a per_page="X" option in the [simple-feature-requests] shortcode. Would prefer to display all requests rather than have pagination.

Hey 🙂 Would be cool to have an option in the shortcode to show recently completed requests, with their completed date. Would give prospective customers a good sense of the pace of development.

To allow for customization of the feature requests pages, they would benefit greatly from having their own taxonomy. For example, we have a taxonomy for Downloads and for Documentation you can see here: https://imgur.com/a/FEHYXbj It would be really helpful for customization/extensibility if feature requests had their own taxonomy.

Users are sent emails that the status has changed for "Pending." Because this is the status that it acquires upon creation, the emails are confusing/misleading. e.g. email body text: Hello [username] We thought you'd like to know the status of [issue_name] has changed to Pending

Currently the feature requests are hard-coded to show the user's username, as opposed to what they'd like to display their name publicly as.