Contributing and AI Policy
Contributing to ripgrep means taking responsibility for the code, issue, or pull request you publish. The project welcomes AI-assisted coding, but it holds contributions to a high bar and expects contributors to understand their work.
This page explains the expectations before opening an issue or pull request, the limits on AI assistance, and the information needed for a useful bug report or feature request.
Sources: AI_POLICY.md:1-7, CONTRIBUTING.md:3-8
Core concepts
Contributor responsibility
A contributor is the human responsible for understanding and publishing the work, even when AI helped produce code.
Sources: AI_POLICY.md:3-7
AI-assisted contribution
AI-assisted contribution means using AI or LLMs as coding tools; that use is welcome only when it remains under meaningful human understanding and control.
Sources: AI_POLICY.md:3-6, AI_POLICY.md:20-23
Maintainer communication
Maintainer communication includes issue descriptions, pull request bodies, and replies to maintainer questions; these comments must express the contributor’s own understanding and voice.
Sources: AI_POLICY.md:8-18
Reproducible bug report
A reproducible bug report gives maintainers enough version, environment, command, input, actual output, and expected output to investigate the problem.
Sources: .github/ISSUE_TEMPLATE/bug_report.yml:23-29, .github/ISSUE_TEMPLATE/bug_report.yml:43-59, .github/ISSUE_TEMPLATE/bug_report.yml:61-99
Before opening an issue or pull request
Before filing a bug, first review the common issues listed by the bug template and confirm that the problem is different from them. The template explicitly asks the reporter to confirm this with the I have a different issue. checkbox.
For a bug report, gather the version from rg --version, the installation method, and the operating system name and version. These fields are required because the template treats them as part of the minimum report context.
Describe the bug at a high level, then give concrete reproduction steps. When possible, include both the search patterns and the corpus being searched; the template warns that maintainers are unlikely to fix a problem they cannot reproduce.
Show the command and actual output, including the --debug flag in the invocation. Small output belongs in code fences, while large output can be placed in a gist. The --debug flag is intended to show why ripgrep skipped particular files, so it gives maintainers investigation evidence rather than only a symptom.
Finally, state what you expected ripgrep to do. The template requires an expected-behavior description separately from the actual behavior.
For a feature request, describe the desired behavior, explain the motivation, and provide examples of how ripgrep would be used if the feature existed. The template also suggests imagining the ideal documentation in ripgrep’s man page when the request is difficult to phrase.
If the request concerns adding or changing default file types, open a pull request instead of using a feature request issue.
| Report element | What to provide | Why it matters |
|---|---|---|
ripgrep-version | The output of rg --version | Identifies the version under discussion. |
install-method | How ripgrep was installed, such as Cargo, APT, or Homebrew | Distinguishes ripgrep behavior from downstream packaging. |
operating-system | The operating system name and version | Establishes the environment. |
description | A high-level description of the bug | States the problem clearly. |
steps-to-reproduce | Commands, patterns, and preferably a small corpus | Lets maintainers reproduce the behavior. |
actual-behavior | The command, output, and --debug output | Shows what happened and supplies diagnostic context. |
expected-behavior | What ripgrep should have done | Defines the intended result. |
These fields correspond to the required bug-template inputs and its reproduction guidance.
Sources: .github/ISSUE_TEMPLATE/bug_report.yml:5-20, .github/ISSUE_TEMPLATE/bug_report.yml:23-49, .github/ISSUE_TEMPLATE/bug_report.yml:51-71, .github/ISSUE_TEMPLATE/bug_report.yml:74-91, crates/core/flags/defs.rs:1548-1557, .github/ISSUE_TEMPLATE/bug_report.yml:94-101, .github/ISSUE_TEMPLATE/feature_request.md:10-17, .github/ISSUE_TEMPLATE/feature_request.md:19-20, .github/ISSUE_TEMPLATE/bug_report.yml:23-29, .github/ISSUE_TEMPLATE/bug_report.yml:31-71
Rules for AI-assisted work
AI use for coding is allowed, but the contributor remains responsible for the code they publish, while maintainers remain responsible for code included in a release. This division is why using an AI tool does not remove the need for review, understanding, or accountability.
Do not use AI to generate comments when communicating with maintainers. Comments believed to be AI-written may be hidden without notice.
When opening an issue, describe the problem in your own words. When opening a pull request, explain the proposed changes in your own words in both the pull request body and responses to questions. Do not copy AI responses when replying to maintainer questions.
The project requires a human in the loop who understands the AI-produced work. Autonomous agents are not allowed for contributing, and pull requests that appear to violate this rule may be closed, possibly without notice.
If you include context from an AI interaction, put it in a quote block and disclose it as AI-sourced context. Add human commentary explaining its relevance and implications, and do not share long snippets.
AI may help a non-native English speaker edit comments or translate them, but the contributor must ensure the result reflects their own voice and ideas. For translation, the policy recommends writing in the native language and including the AI translation in a quote block.
Sources: AI_POLICY.md:3-7, AI_POLICY.md:8-11, AI_POLICY.md:12-18, AI_POLICY.md:20-23, AI_POLICY.md:25-28, AI_POLICY.md:30-34
What happens when the rules are not followed
The repository’s contribution guidance points contributors to the AI Policy for all AI use in contributions. Contributions that do not follow that policy will be closed.
The policy gives two specific consequences: comments believed to be AI-generated may be hidden without notice, and pull requests that appear to use autonomous agents may be closed, perhaps without notice. These consequences make disclosure, human authorship of maintainer communication, and genuine understanding practical conditions of participation rather than optional style preferences.
A report that is not reproducible may also fail to progress because maintainers cannot verify the behavior. The bug template explicitly says that a bug is unlikely to be fixed when maintainers cannot reproduce it, while allowing reporters to file large-corpus cases so maintainers can help determine next steps.
Sources: CONTRIBUTING.md:3-8, AI_POLICY.md:8-11, AI_POLICY.md:20-23, .github/ISSUE_TEMPLATE/bug_report.yml:61-71
How it connects
This page is an orientation guide for the repository described in Project Overview. The issue template covers ripgrep and its crates, including ignore and globset, so a report may concern either the command-line tool or one of its reusable components.
Bug reports should include diagnostic output from the command-line interface, while the --debug documentation explains that this output helps identify skipped files and their causes. Contributors who need to understand how arguments reach the rest of the program can continue with CLI Entry and Flag Parsing.
Questions and general discussion have a separate contact path: blank issues are enabled, and the configuration links “Ask a question” to GitHub Discussions.
Sources: .github/ISSUE_TEMPLATE/bug_report.yml:1-2, crates/core/flags/defs.rs:1548-1557, .github/ISSUE_TEMPLATE/config.yml:1-6
Key takeaways
- Understand and take responsibility for everything you publish, including AI-assisted code.
- Write issue descriptions, pull request bodies, and maintainer replies in your own words.
- Do not use autonomous agents to contribute, and do not use AI-generated maintainer comments.
- Give bug reports version, installation method, operating system, reproduction steps,
--debugoutput, actual behavior, and expected behavior. - Describe feature requests through desired behavior, motivation, and concrete usage examples.