Issue #482 is your API migration plan. The two customers most affected by it will never see it — they don't have repo access, and GitHub has no way to grant them just that one issue. Your PM might be able to open it. The exec who needs to sign off definitely can't.
So you do what everyone does: copy the content into a Google Doc, email it out, and manually merge the feedback back. Now the proposal lives in two places, the feedback lives in three channels (Doc comments, email replies, a Slack thread someone started), and nobody can see what anyone actually thinks.
This is a solved problem. It just requires a different tool.
The access problem
GitHub's permission model is all-or-nothing at the repo level. You can invite someone as a collaborator and they see everything — every issue, every PR, every file. Or they see nothing.
There's no "let this person read issue #482 and answer three questions about it." There's no scoped, read-only, single-issue access for external stakeholders.
This matters more than most teams realize. Technical decisions don't happen in a vacuum. The people affected by your proposal include:
- Customers who use the API you're changing
- Partner teams at other companies who integrate with your service
- Executives who need to sign off on scope or budget
- Contractors or agencies working on adjacent projects
- Advisory board members or investors with relevant domain expertise
None of these people should have access to your entire repo. But all of them might have input that changes your decision.
What teams do today
The Google Doc. Copy the proposal, paste it into a doc, share the link. Feedback comes in as comments. You manually copy anything useful back to the issue. Two sources of truth, and neither is complete.
The email. Paste the relevant sections into an email, ask for thoughts. Replies are scattered across inboxes. Some people reply-all, some don't. Threading breaks down after three replies.
The Notion page. Similar to the Google Doc approach but with Notion's collaboration features. Slightly better for structured content, still disconnected from where the work lives.
The meeting. Schedule a call, walk through the proposal live, take notes. Works for small groups but doesn't scale. The people with the best feedback are often the ones who can't make the meeting.
The PDF. Export, attach, send. Feedback comes back in email, marked-up PDFs, or verbal comments. Worst of all worlds.
All of these solve the access problem. None of them solve the feedback problem. You still get unstructured comments that you have to manually synthesize — the same disease GitHub issue threads have, exported to a new host — and there's still no way to ask specific questions and see specific answers.
What you actually need
- A shareable view of the proposal that doesn't require GitHub access or any account at all
- Scoped access — each link works for a specific set of people, and can be revoked independently
- Structured questions embedded in the content, so reviewers engage with specific asks rather than leaving general comments
- Responses collected in one place, organized by question, not by person or by time
- A connection back to the source — feedback should flow back to the GitHub issue, not live in a separate tool
How Inkling handles this
This is the use case we built Inkling around.
You paste a GitHub issue URL. Inkling pulls in the content and lets you add questions inline — right next to the sections they relate to. Then you create shareable links, each scoped to a set of email addresses.
Your engineering team gets one link. Your PM gets another. Your customers get a third. Each link is tracked separately. You can require email verification or leave it open — the default is no verification, so there's zero friction for the reviewer.
The reviewer clicks the link, reads the proposal, and answers the questions. No account, no GitHub access, no signing up for anything. They see a clean document with questions embedded in the flow of reading.
Responses come back structured. You can see what all three groups said about each question. When you're ready, a summary gets posted back to the GitHub issue thread.
The proposal stays in GitHub. The feedback comes from anywhere. (For the full workflow of turning an issue into a reviewable proposal, see GitHub issues as Inkling proposals.)