Feature Voting Board Rules: Copyable Template

Name the audience and scope first. A board for improvements to an existing reporting product needs a different boundary from an open discussion of possible new businesses. Describe the tasks you want to hear about. Ask contributors for the problem, the result they need, and their current workaround, with one distinct need per request.

Decide how the owner will respond when two requests appear similar. The word 'export' might describe downloading one report or scheduling a monthly delivery. Compare the task, audience, and needed outcome before combining them. Keep different needs visible even when they share a proposed solution; explain a merge when they genuinely match.

Define the review process separately from delivery. You can commit to checking new submissions on a chosen day without committing to ship them. A public status should reflect actual work: investigating a need is different from planning implementation. Use the labels your board really supports, and remove any review promise your team cannot meet.

Keep the published notice short enough to read before submitting. Replace every bracket, remove irrelevant lines, and check that the support destination works. Put it in your existing help page, onboarding material, or board description where supported. Do not assume your voting tool provides a dedicated rules panel or a pinned notice.

Make participation useful without presenting the board as a representative survey. A displayed vote total shows activity on the board; it does not establish unique paying accounts or a percentage of all customers. A highly visible request may attract more attention than one a smaller audience needs. Explain that consequences, product goals, feasibility, and supporting evidence also enter the decision.

A moderator reply should explain the decision in terms the contributor can check. When combining requests, identify the shared task and provide the continuing destination. If the underlying needs differ, keep both records and state why. A matching keyword is not a sufficient reason to merge.

In Feedbackly, the owner can merge active requests within the same board. The merge moves comments and consolidates votes using the stored voting identifiers; the result is not necessarily the sum of both displayed counts. Do not promise to preserve a summed total or describe it as a verified count of people or companies. Check the resulting request and explanation after a merge.

When someone asks why the most popular request has not shipped, acknowledge the demand and describe the current decision. Share a useful next step, such as clarifying the affected workflow or reviewing a dependency. If there is no delivery commitment, say so plainly. Keep private commercial context in the internal decision record.

In this fictional reporting product, 'save my export settings' has 18 displayed votes and 'schedule a monthly export' has six. A reviewer initially groups both under exports. Reading the comments reveals two tasks: an analyst repeatedly chooses the same columns, while an administrator needs a file delivered when nobody is signed in. Neither total establishes the number of affected customer accounts.

The owner keeps the requests separate, asks each group for a concrete workflow example, and records the evidence internally. A third request asks for the same reusable column selection as the first. After confirming that match, the owner combines it with the continuing request and explains where the discussion moved. They verify the resulting count rather than publishing the sum of the old totals.

At the next review, the team chooses to investigate reusable settings and defers scheduling pending a clearer delivery requirement. The public explanation names the next investigation, not an implementation date. The rules make that decision understandable without claiming that the vote winner automatically becomes planned work.

Before launch, have someone read the rules and submit a public-safe sample problem. Can they tell which existing request matches, where to put a private support issue, and what an under-review status means? Test as a participant as well as the board owner. A readable policy is only useful when the surrounding workflow supports it.

Revisit the notice when your review cadence or decision process changes. Update the wording before repeating a commitment you can no longer meet. Use the tool-evaluation checklist for software permissions and package checks, the board template for setup, and the weekly review guide for internal follow-through. Those documents support the rules without turning the public notice into a full operating manual.