docs(templates): require expected/actual + QA proof for external contributions

PR template: - Make the rubric explicit at the top: link an issue, OR provide a clear problem description + expected vs. actual + visual QA proof. - Add dedicated sections for each piece so the bot has a deterministic shape to read. - Keep the existing 'Linear ticket' section for internal contributors (they're exempt from the auto-triage rubric). Bug report template: - Split 'What happened?' into 'Actual behavior' + 'Expected behavior'. - Make logs/screenshot a required textarea. - Warning banner at the top tells external contributors that incomplete reports will be auto-closed (with re-evaluation on reopen). Feature request template: - Require a concrete use case + example in the motivation field, not just a one-liner pitch. - Same auto-triage warning banner. Co-authored-by: Mateo Wang <mateo-berri@users.noreply.github.com>
2026-09-15 23:31:29 +00:00 · 2026-05-17 16:25:07 +00:00 · 2026-05-17 16:25:07 +00:00 · ac18f1407e
commit ac18f1407e
parent 2e7fdc6f9c
3 changed files with 105 additions and 32 deletions
--- a/.github/ISSUE_TEMPLATE/bug_report.yml
+++ b/.github/ISSUE_TEMPLATE/bug_report.yml
@ -6,8 +6,11 @@ body:
  - type: markdown
    attributes:
      value: |
-        Thanks for taking the time to fill out this bug report!
-        
+        Thanks for taking the time to file a bug report!
+
+        > ⚠️ **Auto-triage notice for external contributors:**
+        > Bug reports without **clear reproduction steps, expected vs. actual behavior, and a screenshot or terminal/log output** are auto-closed by our LLM triage bot with an explanation of what was missing. You can fill in the missing details and reopen at any time — the bot will re-evaluate. Internal BerriAI contributors are exempt.
+
        **💡 Tip:** See our [Troubleshooting Guide](https://docs.litellm.ai/docs/troubleshoot) for what information to include.
  - type: checkboxes
    id: duplicate-check
@ -20,21 +23,33 @@ body:
  - type: textarea
    id: what-happened
    attributes:
-      label: What happened?
-      description: Also tell us, what did you expect to happen?
-      placeholder: Tell us what you see!
-      value: "A bug happened!"
+      label: What happened? (Actual behavior)
+      description: A clear description of what is happening today, with the bug.
+      placeholder: e.g. "Calling completion() with model=gpt-4o-mini returns an empty string."
+    validations:
+      required: true
+  - type: textarea
+    id: expected-behavior
+    attributes:
+      label: What did you expect to happen? (Expected behavior)
+      description: A clear description of what you expected to happen. **Required.**
+      placeholder: e.g. "I expected completion() to return the model's response text."
    validations:
      required: true
  - type: textarea
    id: steps-to-reproduce
    attributes:
-      label: Steps to Reproduce
-      description: Please provide detailed steps to reproduce this bug(A curl/python code to reproduce the bug)
+      label: Steps to reproduce
+      description: |
+        Provide a minimal reproduction. Include a runnable Python snippet or a
+        `curl` command, your config.yaml if relevant, and the exact LiteLLM
+        version + Python version. Reports without a runnable reproduction are
+        auto-closed.
      placeholder: |
-        1. config.yaml file/ .env file/ etc.
-        2. Run the following code...
-        3. Observe the error...
+        1. Create `config.yaml` with: ...
+        2. Start the proxy with: `litellm --config config.yaml --port 4000`
+        3. Run this Python / curl: ...
+        4. Observe: ...
      value: |
        1. 
        2. 
@ -44,9 +59,15 @@ body:
  - type: textarea
    id: logs
    attributes:
-      label: Relevant log output
-      description: Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks.
+      label: Relevant log output / screenshot
+      description: |
+        **Required.** Paste the full traceback, stderr, proxy logs, or attach a
+        screenshot showing the bug. For UI bugs a screenshot or screen
+        recording is mandatory. Without proof of the bug, the issue is
+        auto-closed.
      render: shell
+    validations:
+      required: true
  - type: dropdown
    id: component
    attributes:
@ -63,14 +84,14 @@ body:
  - type: input
    id: version
    attributes:
-      label: What LiteLLM version are you on ? 
+      label: What LiteLLM version are you on ?
      placeholder: v1.53.1
    validations:
      required: true
  - type: input
    id: contact
    attributes:
-      label: Twitter / LinkedIn details 
+      label: Twitter / LinkedIn details
      description: We announce new features on Twitter + LinkedIn. If this issue leads to an announcement, and you'd like a mention, we'll gladly shout you out!
      placeholder: ex. @krrish_dh / https://www.linkedin.com/in/krish-d/
    validations:
--- a/.github/ISSUE_TEMPLATE/feature_request.yml
+++ b/.github/ISSUE_TEMPLATE/feature_request.yml
@ -1,4 +1,4 @@
-name: 🚀 Feature Request 
+name: 🚀 Feature Request
 description: Submit a proposal/request for a new LiteLLM feature.
 title: "[Feature]: "
 labels: ["enhancement"]
@ -6,7 +6,10 @@ body:
  - type: markdown
    attributes:
      value: |
-        Thanks for making LiteLLM better! 
+        Thanks for making LiteLLM better!
+
+        > ⚠️ **Auto-triage notice for external contributors:**
+        > Feature requests need (1) a clear description of the proposed feature, (2) the motivation / use case with a concrete example, and (3) what success looks like. Vague requests are auto-closed by our LLM triage bot with an explanation. Fill in the missing details and reopen at any time — the bot will re-evaluate. Internal BerriAI contributors are exempt.
  - type: checkboxes
    id: duplicate-check
    attributes:
@ -18,16 +21,25 @@ body:
  - type: textarea
    id: the-feature
    attributes:
-      label: The Feature
-      description: A clear and concise description of the feature proposal
-      placeholder: Tell us what you want!
+      label: The feature
+      description: A clear and concise description of the feature proposal. What should LiteLLM do that it doesn't today?
+      placeholder: e.g. "Support per-team max_input_tokens overrides on the proxy."
    validations:
      required: true
  - type: textarea
    id: motivation
    attributes:
-      label: Motivation, pitch
-      description: Please outline the motivation for the proposal. Is your feature request related to a specific problem? e.g., "I'm working on X and would like Y to be possible". If this is related to another GitHub issue, please link here too.
+      label: Motivation, pitch, and concrete example
+      description: |
+        **Required.** Why is this needed? Include a concrete use case — what
+        you're trying to accomplish, what's blocked today, and what success
+        would look like (ideally with an example config / API call / UI flow).
+        If this is related to another GitHub issue, link it here too.
+      placeholder: |
+        I'm running a multi-tenant proxy where team A processes long docs and
+        team B only does short chats. Today I have to spin up two proxies.
+        With this feature I could set max_input_tokens per team and route in one
+        proxy. Example config: ...
    validations:
      required: true
  - type: dropdown
@ -56,7 +68,7 @@ body:
  - type: input
    id: contact
    attributes:
-      label: Twitter / LinkedIn details 
+      label: Twitter / LinkedIn details
      description: We announce new features on Twitter + LinkedIn. When this is announced, and you'd like a mention, we'll gladly shout you out!
      placeholder: ex. @krrish_dh / https://www.linkedin.com/in/krish-d/
    validations:
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@ -1,10 +1,57 @@
+<!--
+👋 Hi there — please read before submitting.
+
+To keep the review queue healthy for everyone, **external contributions are
+auto-triaged** by an LLM bot ("Agent Shin") on open / reopen. Pull requests that
+do not meet the rubric below are auto-closed with an explanation, and you can
+update + reopen at any time to be re-evaluated.
+
+To pass triage, your PR must satisfy AT LEAST ONE of:
+
+  (A) Link a related GitHub issue (e.g. "Fixes #1234" or "Resolves
+      https://github.com/BerriAI/litellm/issues/1234"), OR
+
+  (B) Provide ALL of the following IN THIS PR DESCRIPTION:
+      - A clear problem description (what bug or missing feature this addresses)
+      - Expected vs. actual behavior
+      - Visual QA proof (before/after screenshots, screen recording, or
+        terminal output demonstrating that the fix/feature works end-to-end)
+
+PRs also receive a Greptile code review. PRs open for ≥7 days with a Greptile
+Confidence Score below 4/5 are auto-closed; re-request a review from
+@greptileai once you've addressed the feedback and reopen to be re-evaluated.
+
+Internal BerriAI contributors are exempt from this auto-triage — fill in the
+Linear ticket section instead.
+-->
+
 ## Relevant issues

-<!-- e.g. "Fixes #000" -->
+<!-- e.g. "Fixes #000". If you have no related issue, fill in the
+"Problem description / Expected vs. Actual / QA proof" sections below. -->

 ## Linear ticket

-<!-- if you are an internal contributor, add the Linear ticket e.g. "Resolves LIT-1234" to magically link the Linear ticket to the GitHub PR -->
+<!-- INTERNAL CONTRIBUTORS ONLY: add the Linear ticket e.g. "Resolves LIT-1234"
+to magically link the Linear ticket to the GitHub PR. External contributors:
+leave this blank and fill in the problem/expected-actual/QA sections below. -->
+
+## Problem description
+
+<!-- What bug or missing feature does this PR address? One or two paragraphs.
+External contributors: required unless you linked a GitHub issue above. -->
+
+## Expected vs. actual behavior
+
+<!-- What did you expect to happen? What is happening today (before this PR)?
+External contributors: required unless you linked a GitHub issue above. -->
+
+## QA proof
+
+<!-- Required for external contributors: include before/after screenshots,
+a screen recording, or terminal/log output that demonstrates the fix or feature
+works end-to-end. For UI changes, before/after screenshots are mandatory.
+For backend changes, terminal output of a passing test or curl command is fine. -->

 ## Pre-Submission checklist

@ -36,13 +83,6 @@ If you're seeing a delay in your PR being merged, ping the LiteLLM Team on [Slac
 - [ ] **Merge / cherry-pick CI run**  
       Links:

-## Screenshots / Proof of Fix
-
-<!-- Include screenshots, screen recordings, or log output demonstrating that your changes work as expected.
-     For bug fixes: show reproduction before the fix and passing behavior after.
-     For new features: show the feature working end-to-end.
-     For UI changes: include before/after screenshots. -->
-
 ## Type

 <!-- Select the type of Pull Request -->