QGIS AI Contribution Ban: Check Your Voice Draft in 2026
A merged code policy, an open text proposal, and the questions to ask before submitting a spoken draft.
October 12, 2026
QGIS's AI contribution ban covers AI-assisted code in its main repository. A separate proposal would also limit AI use in written interactions. That proposal was still open on October 12, 2026. If you use voice dictation to draft a bug report, don't assume transcription or AI editing is exempt. Read the current policy and ask how it handles the specific processing you use.
The timing needs clearing up. Today's Hacker News discussion[7] made the decision seem new, but the code-policy change was merged on October 7[1]. October 12 is when the discussion reached a wider audience, not when QGIS first adopted the rule.
I read the proposal because "AI-assisted" now covers tools that do very different jobs. A coding agent might create a patch. A speech recognizer might turn someone's explanation into text. A rewrite tool might then change that explanation without making the changes clear. Those differences matter to people who speak their reports instead of typing them.
Read the merged rule before interpreting the headline
The current policy file[2] bans code contributions to the main QGIS repository made with LLMs, AI, or agents. It warns that violations could lead to reverted code and restrictions on contributor rights. The broad policy does not state a speech-to-text exemption.
In the proposal discussion[1], contributors describe pressure on review capacity and debate how widely the restriction should apply. The author presents the change as an initial restrictive position, with possible exceptions to discuss later. This adds context, but contributors still can't create their own exceptions.
Today's explainx.ai article[3] gets the main concern right: maintainers have limited time. Its sourcing caveat matters too. The writer says they couldn't access the rendered final diff. I checked the raw policy file and GitHub's merge record myself, so the scope described here comes from the project's own text.
Two follow-ups were still open when checked. QEP 429[4] proposes an exception for trusted contributors. QEP 430[5] proposes extending the policy to AI-generated written content. Neither proposal has created an approved exception or finalized the policy for written text.
The merged text and the proposed expansion need separate descriptions. Saying QGIS banned all AI-assisted writing treats a proposed expansion as final. Saying voice typing is definitely allowed makes the opposite mistake. The records I checked don't settle the issue.
A useful bug report can stay close to what you saw
Imagine a fictional mapping problem. You select a layer, change its filter, and the canvas turns blank. Reopening the project restores it. You want to describe what happened while the details are still fresh, perhaps because typing is uncomfortable or explaining the steps aloud feels easier.
Start with a private draft. Describe the sequence as you remember it, including anything you're unsure about. Then compare it with the application's actual state. Copy the program's exact version number. Paste error messages from their original source. Copying is the reliable way to preserve a stack trace character for character.
Here's an example report fragment: "After I changed the filter, the map went blank. Reopening the saved project brought it back. I haven't checked whether this also happens in a new project."
That last sentence is worth keeping. A cleanup tool could turn an uncertain observation into a confident diagnosis. "The filter corrupts the project" sounds certain, but the example doesn't prove that. You reported a visible symptom and a recovery step. The cause is still unknown.
Before submitting, check these details against your draft:
- The steps needed to repeat the issue, including the starting state.
- The result you expected and what you actually saw.
- Exact version details and the copied error text, kept separate from your interpretation.
- Anything you haven't tested yet, stated clearly.
Keep the example small enough for someone else to inspect. If the project file contains private information, think carefully before attaching it. Create a shareable sample that still reproduces the problem, and follow the project's reporting instructions. These suggestions only cover writing. They don't give permission to submit AI-assisted material to QGIS.
Cleanup can change who supplied the explanation
A spoken draft may go through several steps. Speech recognition turns the audio into text. Cleanup fixes punctuation and removes repetition. A generative editor can add missing reasoning, suggest a cause, or write a solution. All of these steps can run from the same microphone button.
Before you record, check the settings. Does the tool keep your exact words? Can you see the unedited transcript? Is automatic rewriting turned on? If the product doesn't show what changed, make a separate draft and compare the result with what you meant to say.
I build DictaFlow[8], so I have a commercial interest here. Its hold-to-talk workflow can help you capture an explanation in the app you're using. But that doesn't exempt its output from a project's contribution rules. If a repository has a restrictive policy, check the exact transcription and refinement process with its maintainers before using it in a submission. Switching tools or turning off a feature doesn't prove compliance.
Keep code identifiers unchanged whenever possible. Dictate the surrounding explanation, then insert the filename or command from the source. Capitalization may matter in a path. Changing "sometimes" to "always" could mislead someone trying to reproduce the failure.
Review capacity is a writing constraint too
The problem goes beyond QGIS. In a June 25 report for the Australian Computer Society's Information Age[6], Tom Williams spoke with maintainers about the rise in AI-generated contributions. Lucy Liu calls code review the bottleneck. The report also includes maintainers who use AI to help manage their workload. It shows why the debate is growing, but it doesn't show that every project should follow QGIS's approach.
An unanswered question belongs in the description if you still need to investigate it. If you can't explain why a patch changes a particular branch, generated prose gives them one more thing to check. Investigate the branch before continuing, or submit only the observation through any channel the project allows.
For voice users, the goal is to contribute in a useful way without making extra work for the people reviewing the result. Ask a specific question: Does this project allow speech transcription of my own words with these cleanup settings? Name the tool and explain what it does. Don't ask a maintainer to approve a vague label like "AI productivity."
QGIS's follow-up proposals may change the answer. Until then, keep the current policy and your actual tool settings next to the draft. Check both before clicking Submit.
Sources
[1] QEP 428 merge and discussion
[3] October 12 explainx.ai coverage
[4] QEP 429 trusted-contributor proposal
[5] QEP 430 written-content proposal
[6] Information Age maintainer interviews