Send Website Feedback to GitHub Issues

Sending website feedback to GitHub Issues removes the handoff between a reporter-facing form and engineering triage. BugDrop creates the issue directly, adds structured environment context, and stores an optional screenshot in the selected repository.

Use this guide when: GitHub is the required destination and you need to design the issue body, labels, permissions, and triage flow. This is not the broad website feedback widget category guide.

Try a report in the demo or review the installation contract.

What reaches GitHub

Every submission includes the reporter's title, description, and one built-in category: Bug, Feature, or Question. BugDrop also records browser, operating system, viewport, language, and current URL in a System Info section. When configured and provided, submitter name and email are included in the issue body.

Screenshots are optional by default. When a screenshot is attached, BugDrop stores the PNG under .bugdrop/screenshots/ on the dedicated bugdrop-screenshots branch and links it from the issue. The app needs Issues read/write permission to create the report and Contents read/write permission for screenshot storage.

Design the issue for triage

The widget can reduce missing context, but teams still need a small operating contract:

1. Category ownership: decide who reviews Bug, Feature, and Question submissions.
2. Label mapping: use the hosted defaults or configure self-hosted category labels. Do not trust page-provided raw labels as an authorization boundary.
3. Repository choice: send reports to the repository where someone is accountable for triage.
4. Response expectation: define whether reporters receive follow-up outside GitHub, especially when they do not have repository access.
5. Screenshot handling: keep the screenshot branch out of privileged workflows and define cleanup expectations.

GitHub then supplies the normal engineering tools: assignees, comments, projects, milestones, links to pull requests, and closure. BugDrop does not mirror status to a separate reporter portal.

Example: mobile layout report

A visitor sees a plan card overlap the purchase button on a narrow screen. They submit the expected result and the visible problem, then select the affected area for a screenshot. The issue records the route and viewport automatically, while the screenshot shows the layout state.

The developer now has evidence to reproduce the bug at the reported viewport. They should still confirm the behavior locally and avoid treating browser metadata as a diagnosis. After the fix, the pull request and issue remain connected in GitHub without copying the report out of another dashboard.

Public and private repository considerations

Reporters do not need GitHub accounts to submit through the widget. Issue visibility is still controlled by the repository. For private repositories, only authorized collaborators can open the resulting GitHub URL; configure whether the success screen should expose that link to the reporter.

The hosted endpoint accepts unauthenticated submissions and uses rate limits. For a private internal workflow that requires host-app identity or stronger abuse controls, review the self-hosted authentication and edge-protection options rather than assuming repository privacy authenticates the form.

Validate the destination workflow

Use a test repository or staging label and submit one report of each category. Confirm:

• the issue is created in the intended repository;
• system fields reflect the reporting browser and URL;
• configured labels exist and apply as expected;
• screenshot links work and the storage branch does not trigger CI;
• private issue-link behavior matches the audience;
• the security and retention model is acceptable.

Continue with configuration and security. For a developer-oriented alternative with recordings and logs rather than direct issue creation, review the Jam comparison.