A useful GitHub issue is easiest to write while the failure is still on screen. The exact sequence is fresh. The odd console line is visible. You remember which workaround failed and what changed after the last release.
Then the issue editor opens, and the report shrinks to: “Login is broken on Safari.”
Voice typing helps with this particular loss. It does not make a vague observation precise by itself. It gives you a faster way to preserve the evidence, sequence, and limits you already know before they are compressed into a title and one sentence.
GitHub issues can track bugs, enhancements, tasks, and other project information. Their bodies use GitHub Flavored Markdown, including headings, task lists, links, and fenced code blocks. That makes an issue more than a message. It is a small working record that another person should be able to inspect, reproduce, and close.
Speak the changing facts, not the stable template
Most teams already know the headings they want:
- Summary
- Steps to reproduce
- Expected result
- Actual result
- Environment
- Acceptance criteria
Typing those labels is not the expensive part. The expensive part is reconstructing what happened under each one.
A practical split is to keep a Markdown issue template in the repository, then dictate the variable evidence into it. GitHub supports Markdown templates and issue forms, so the stable questions can already be present when the editor opens. Your voice supplies the facts that changed today: the fourth click, the browser version, the stale token, the screen that appeared instead, and the test that should pass when the bug is fixed.
This division also prevents speech from becoming a long, unstructured report. The template holds the shape. The recording fills the gaps.
Reproduction steps need sequence and stopping points
A report such as “the upload sometimes fails” leaves the reader with several unknowns. Which file? Which route? Before or after authentication? Does retrying help? What is visible when it fails?
Speak the steps in order and mark the point where observed behaviour diverges:
- Start from a known state.
- Name the action you take.
- State what appears after each important action.
- Stop at the first wrong result.
- Add whether the failure repeats.
For example:
Start with a signed-in account that has no profile image. Open Settings, choose a PNG larger than five megabytes, and press Save once. The progress bar reaches one hundred percent, then the page returns to the previous avatar without an error message. Reloading does not show the new image. Repeating with a smaller PNG succeeds.
That paragraph contains a comparison case, a visible result, and a repeatability check. Those details are often removed when the same report is typed under time pressure.
Separate observation from explanation
A GitHub issue becomes harder to investigate when an assumption is written as if it were evidence.
“The cache invalidation is broken” may be correct, but it is a diagnosis. “The second request returns the old avatar URL after the upload endpoint returns 200” is an observation. The second statement gives a maintainer something to verify even if the eventual cause is elsewhere.
While dictating, use explicit boundaries:
- “I observed…” for visible behaviour.
- “I expected…” for the contract you relied on.
- “My current guess…” for a hypothesis.
- “I have not verified…” for an open question.
Speech makes it easy to include a theory because you are explaining the problem as you understand it. Naming the theory as a theory keeps the issue useful when that explanation turns out to be wrong.
Type exact tokens and dictate what they prove
Voice is strong for chronology and reasoning. It is weaker when every character matters.
Use the keyboard for:
- commit hashes and issue numbers
- file paths and identifiers
- URLs with query parameters
- shell commands and regular expressions
- stack traces and log excerpts
- version strings that differ by one digit
Paste logs and code inside fenced code blocks rather than reading them aloud. GitHub renders fenced blocks and can apply syntax highlighting when a language identifier is included. A short excerpt is usually more useful than a spoken paraphrase because spacing, punctuation, and line order may carry the evidence.
Then dictate the sentence around the exact token: where the log came from, which action produced it, and which line matters. The keyboard preserves the artifact. Voice preserves its meaning.
Acceptance criteria turn the report into a finish line
An issue can describe the failure accurately and still be difficult to close. “Fix avatar upload” does not say whether success means showing an error, accepting larger files, retrying the request, or updating the image immediately.
Add acceptance criteria that can be checked after the change. GitHub task lists use Markdown checkboxes, so the criteria can remain visible as work progresses.
For the upload example:
- A supported image shows the new avatar without a manual reload.
- An unsupported file size produces a visible error.
- A failed upload does not replace the existing avatar.
- The regression test covers the failing size boundary.
Dictating these criteria is often easier than writing them because you can answer a direct question: “What would I need to see before I agree this is fixed?” The checklist should describe outcomes, not prescribe an implementation unless the implementation itself is the requirement.
Clean keeps the report faithful; Raw keeps the whole take
TalkTalkType records while you hold Option-Space and returns the result to the field that had focus. In a GitHub issue editor, that lets the repository context, template, and existing comments stay visible while you speak.
Clean performs faithful light cleanup. It keeps every spoken word, their order, your register, and the brevity you intended. It removes only unambiguous hesitation fillers and returns one line. It does not silently convert the report into a different bug template or invent missing facts.
Raw skips cleanup and preserves the complete transcript, including false starts. It is useful when you plan to edit heavily or when an unusual proper name may be altered by any cleanup step.
Neither mode makes exact technical text safe to dictate. Read the draft before submitting, then replace uncertain versions, names, paths, and numbers with copied values. Dictation that works in any app on Mac explains how focused-field delivery and clipboard fallback work across editors.
Do not dictate secrets into a convenient field
A bug report can sit in a public repository, a private company repository, or a project that may become public later. Treat the destination as part of the data boundary.
Do not speak API keys, session cookies, access tokens, private customer data, or production credentials. Redact pasted logs as well. Voice typing reduces the effort of entering information; it does not change who can read the resulting issue.
TalkTalkType does not keep audio, raw transcripts, or cleaned text as a server-side history, but the final text is submitted to GitHub when you create the issue. Private dictation on Mac follows the recording and transcript through the earlier stages of that path.
Start with the issue you would otherwise postpone
Open the repository’s issue template while the bug is still reproducible. Type the title and exact identifiers. Then dictate one take containing the starting state, ordered actions, first wrong result, repeatability, expected behaviour, and current uncertainty.
Read it once. Paste the smallest useful log excerpt. Add a checklist that defines done.
The goal is an issue that preserves enough of the moment for someone else to act after the moment has gone, not a longer one.