Thanks for your interest in contributing to NuvioTV. The project has strict contribution rules that are enforced consistently — issues and pull requests that do not follow them will be closed without review. Read this page completely before opening anything.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/NuvioMedia/NuvioTV/llms.txt
Use this file to discover all available pages before exploring further.
What PRs Are Accepted
Even outside the current freeze period, the project accepts only a narrow set of contribution types. The full list of accepted categories is:- Reproducible bug fixes for issues that are already documented in the issue tracker
- UI glitch fixes for specific, visible bugs (broken layout, overlapping or clipped text, unreadable content, incorrect visual state, remote/focus navigation glitches, regressions from a previous version, or crashes caused by UI code) — must include before/after screenshots or a short video
- Behavior bug fixes that restore the intended behavior without changing product direction — must include an explanation of old behavior, broken behavior, new behavior, and how it was tested
- Small maintenance work that does not change UI, UX, behavior, dependencies, architecture, or public contracts
- Small documentation fixes that improve accuracy
- Translation/localization updates
Translation and localization PRs are always welcome and are not subject to the current freeze. They are accepted as long as they stay focused on translation work and do not bundle feature or UI changes.
What PRs Are NOT Accepted
Pull requests are not accepted for:- New major features
- Product direction or UX/UI redesigns
- Cosmetic-only UI changes (colors, spacing, typography, icons, copy, layout, animations, visual style)
- Behavior changes not tied to a reproducible bug or explicitly approved feature request
- Refactors without a clear maintenance need
- Dependency additions or architecture changes without prior approval
Large Changes: Approval Required First
Any change that is not a simple bug fix requires a Feature Request issue to be opened and explicitly approved by a maintainer before you write any code.Open a Feature Request issue
Describe the change you want to make. Include the problem you are solving, your proposed solution, and any alternatives you considered (see Feature Request Format below).
Wait for explicit maintainer approval
A maintainer must clearly state that the implementation is approved. A feature request being open, popular, or labeled
enhancement is not approval.Bug Report Format
Bug reports must include all of the following. Missing fields will delay or block action on the issue.- Short, specific title — describes the bug, not just
[Bug]:as a placeholder - App version — the release version string (e.g.
0.7.13-beta) or the commit hash if building from source - Platform + device model + Android version — e.g.
NVIDIA Shield Pro · Android 11 - Install method — release APK, CI build, or built from source
- Steps to reproduce — exact, numbered steps starting from the app launch state
- Expected vs. actual behavior — what should happen, and what actually happens
- Frequency — always / sometimes / once
<details> block in the issue. For crashes, include the full stack trace from Android Studio’s Logcat panel or from adb logcat.
Feature Request Format
Feature requests should include:- The problem you are solving — describe the use case, not just the solution
- Your proposed solution — what you want the app to do
- Alternatives considered — other approaches you thought about
Before Opening a PR
Pre-submission checklist
Pre-submission checklist
Before submitting any pull request, confirm every item on this list:
- The PR is allowed by the current policy (localization, or critical bug fix during the current freeze)
- The PR is small in scope and focused on one problem
- The PR is clearly aligned with the current direction of the project
- The PR is not cosmetic-only
- The PR does not change behavior unless it fixes a linked bug or has explicit maintainer approval
- The PR does not change UI unless it fixes a linked glitch/bug and includes before/after screenshots or video
- The PR does not bundle refactors, cleanups, or drive-by changes with a bug fix
- The PR has been tested manually and/or automatically in a way that matches its risk level
- If the change is large, directional, or non-trivial, it links to an approved feature request issue
- The PR template is fully filled out — not left with placeholder text
- Are cosmetic-only UI changes
- Change behavior without a linked bug or approved feature request
- Change UI without screenshots or video
- Bundle unrelated changes
- Leave the PR template incomplete
- Add dependencies, architecture changes, or broad refactors without prior approval