8.5 KiB
Pull Request Checklist
Do not open a pull request as the first step.
For real, reproducible bugs, start with a well-described Issue that explains the problem, why it matters, and what outcome you are looking for.
For feature requests, enhancements, behavior changes, UI/UX changes, architecture changes, suspected fixes, or unconfirmed approaches, start with an active Discussion. Merely opening a discussion is not enough; it needs to be actively discussed.
If you want to propose an implementation, include it only as a reference in the Issue or Discussion, such as a local diff, patch, or branch.
Opening an Issue or Discussion does not mean a PR is the right next step. Maintainers will confirm when a PR would be useful.
We ask for this because PRs, especially from first-time contributors, often need broader maintainer context on product direction, scope, architecture, UX, edge cases, compatibility, documentation, and long-term maintenance before implementation.
Unsolicited PRs may be closed without review. Contributors with a history of successful merged PRs may be given more latitude.
Before submitting, make sure you've checked and filled out the following:
- Linked Issue/Discussion: This PR references an existing, well-described Issue for a real bug or an active, substantive Discussion for a feature request or enhancement —
Closes #___/Relates to #___. - First-time contributor policy: This is not my first contribution to Open WebUI, this PR contains only i18n/localization updates, or a maintainer explicitly asked me to open this PR after reviewing the linked Issue or Discussion.
- Target branch: The pull request targets the
devbranch. PRs targetingmainwill be immediately closed. - Description: A concise description of the changes is provided below.
- Changelog: A changelog entry following Keep a Changelog format is included at the bottom.
- Documentation: Relevant documentation has been added or updated in the Open WebUI Docs Repository.
- Dependencies: Any new or updated dependencies are explained, tested, and documented.
- Testing: I performed manual end-to-end tests that verify the fix/feature works as intended and does not break related functionality. Automated tests, AI-generated tests, or agent-written test summaries are not a substitute for manual verification. I included reproducible steps showing the issue before the fix, tested relevant edge cases (for example URL encoding, HTML entities, and data types), and attached screenshots or recordings for the PR description where applicable.
- User-facing changes: I have confirmed whether this PR changes the UI. If it does, screenshots are required, and a video recording is recommended.
- No Unchecked AI Code: This PR is either human-written or has undergone thorough human review AND manual testing. Unreviewed AI-generated PRs may be closed immediately.
- Self-Review: A self-review of the code has been performed, ensuring adherence to project coding standards.
- Architecture: Smart defaults are preferred over new settings. Local state is used for ephemeral UI logic. Major architectural or UX changes have been discussed first.
- Git Hygiene: The PR is atomic (one logical change), rebased on
dev, and contains no unrelated commits. - Title Prefix: The PR title uses one of the following prefixes:
- BREAKING CHANGE: Changes affecting backward compatibility
- build: Build system or dependency changes
- ci: CI/CD workflow changes
- chore: Refactoring, cleanup, or non-functional changes
- docs: Documentation additions or updates
- feat: New features or enhancements
- fix: Bug fixes or corrections
- i18n: Internationalization or localization changes
- perf: Performance improvements
- refactor: Code restructuring
Changelog Entry
Description
- [Describe the changes, including motivation and impact]
Added
- [New features, functionalities, or additions]
Changed
- [Changes, updates, refactorings, or optimizations]
Deprecated
- [Deprecated functionality or features]
Removed
- [Removed features, files, or functionalities]
Fixed
- [Bug fixes or corrections]
Security
- [Security-related changes or vulnerability fixes]
Breaking Changes
- BREAKING CHANGE: [Changes affecting compatibility or functionality]
Additional Information
- [Any additional context, notes, or references to related issues/commits]
Screenshots or Videos
- [Attach screenshots or videos that demonstrate the fix/feature where applicable. For UI changes, screenshots are required, and a video recording is recommended.]
Contributor License Agreement
- By submitting this pull request, I confirm that I have read and fully agree to the Contributor License Agreement (CLA), and I am providing my contributions under its terms.
Note
Deleting the CLA section will lead to immediate closure of your PR and it will not be merged in.