Feedback

Feedback collects product requests from the admin UI, public portal, and embedded widget. Each item stays connected to its author, votes, comments, subscribers, roadmap placement, and release when available.

Review and Triage

Use the site Feedback section to filter by product status and approval status. Select multiple items to open the floating action bar. Choose Status, Assignee, Roadmap, Approval, or Visibility, select one value, then click Apply to all selected. The same value applies to every item captured when the modal opened; Cancel makes no batch changes. Released, Unassigned, and roadmap None are available. Roadmap assignment requires selection from one site; the other actions support selections across sites. Successful changes update only the affected cards, preserving filters, scroll position, and the open editor. If some updates fail, the modal shows the remaining count and Apply retries only those items.

Each item supports:

• Status: Open, Under review, Planned, In progress, Released, or Closed
• Approval: Pending, Approved, or Rejected
• Public or private visibility
• Assignment, tags, pinning, votes, comments, and subscriptions
• Linking to a roadmap list and a changelog release

Replies and AI Assistance

Reply as a team member, reply on behalf of a customer, or ask Managani to suggest grounded replies. AI analysis can summarize and classify new feedback, identify missing information, and use configured knowledge sources for response context.

Import and Public Participation

Team managers can import existing feedback. Public portal visitors can add one browser-scoped emoji reaction anonymously. Signed widget users can submit requests, upload supported attachments, vote, subscribe, comment, and review their own feedback history. Public visibility and approval remain under team control.

Continue with Roadmap to organize approved requests or Changelog when work ships.

A Practical Review Workflow

Read the customer's underlying problem before choosing a status. A request for a particular button may describe a broader workflow issue. Ask for the missing context in a reply, then use tags and assignment to keep the request with the teammate best placed to investigate it.

Review approval and visibility separately from development status. A request can be planned internally without being ready for public discussion. Before exposing an item through the portal, remove private details and confirm that its wording makes sense to other customers.

When the team commits to work, connect the request to a roadmap list instead of maintaining a second description elsewhere. Once shipped, attach the relevant release so the customer can follow the complete progression. For imported requests, check authorship, status, and public visibility on a small sample before reviewing the rest of the imported backlog.

GitHub Issues

A project connected to GitHub receives one feedback record per issue, including its author, source link, original creation date, and discussion history. Pull requests are excluded. Historical imports do not send customer notifications, create automatic changelog drafts, or generate AI replies.

Connecting a repository does not export the existing published changelog archive or untouched feedback that was already released or closed. New publications after connection can announce linked issues. If a new publication needs its own GitHub issue, Managani keeps that mapping as a changelog-only record: it does not appear in Feedback, Roadmap, their counts, or public feedback search. Existing issue mappings and discussion history remain available through the changelog.

An issue containing a named Roadmap: or Feedback: link to an existing card on this project's portal joins that card instead of appearing as a second card. Managani verifies the portal address, project, and record ID; matching titles alone never combine records. The original card keeps its description and roadmap placement, and its changelog stays separate. Additional GitHub issue links appear in its details and open in new tabs. Existing imported duplicates are reconciled on the next full sync, retaining their discussion, attachments, votes, subscriptions, and reactions. Status updates reach the linked GitHub tasks; task-specific checklist text stays on GitHub.

Title, description, and development status sync both ways. GitHub closure as completed becomes Released; not planned, duplicate, or unspecified closure becomes Closed. Reopening becomes Open. Ordinary GitHub edits preserve intermediate Managani statuses such as Planned or In progress. Setting Managani feedback to Released closes GitHub as completed; Closed closes it as not planned.

Public local feedback creates an issue. Making private local feedback public creates or updates its issue. Newly imported public repository issues initially appear as public/approved feedback; newly imported private repository issues initially stay private. After import, feedback visibility is editable independently in Managani, including batch actions. Existing cards retain their chosen visibility when linked or exported, and later GitHub syncs or repository privacy changes preserve that choice. Changing Managani visibility does not change GitHub repository privacy.

The repository selector retains the project's connected repository when reopened. Private repositories are available when both your GitHub account and the app installation have access. GitHub may reject writes even when repository reads succeed; Managani displays the failing operation and GitHub's reason. Primary and secondary rate limits pause sync before retrying. A rejected creation can retry normally; an ambiguous network or server failure is checked for the original issue or comment first so retries do not create duplicates.

Human discussion replies, edits, and deletion sync to the same GitHub comments. Outbound comments identify the original Managani author while GitHub attributes the write to the app. Explicit internal notes and automatic AI replies remain local. Existing private-only comments are not published to a public GitHub repository. Changing feedback visibility does not change existing comment visibility, and GitHub sync preserves each comment's privacy. New imported comments start private when either the repository or feedback is private; otherwise they start public. Private imported comments do not send customer notifications. Public portal and changelog discussions require public, approved feedback and public comments.

Changes update the affected item without reloading its surrounding view. If GitHub rejects a write, the local edit remains saved and the integration reports the failure. Retrying sync reconciles stable issue/comment IDs; deleted records retain tombstones so old responses cannot restore them.