PixelPlayer Project Status, Priorities, and Scope

[lostf1sh]

This post helps set expectations about what this project is focused on right now.

1) Current priorities

We usually prioritize work in this order:

1. Crash fixes and severe playback bugs
2. Data loss / library corruption risks
3. Reproducible regressions in recent releases
4. UX and quality improvements
5. New feature requests

2) What is considered in-scope

• Playback reliability and stability
• Library scanning/sync correctness
• UI/UX bugs with clear reproduction steps
• Performance issues (lag, stutter, high battery drain)
• Accessibility and localization improvements
• Reasonable feature additions aligned with app architecture

3) What may be out-of-scope (or lower priority)

• Device-specific ROM quirks with no reproducible path
• Requests requiring heavy backend/cloud dependencies
• Features that significantly increase maintenance burden
• Breaking behavior changes for existing users without strong reason

4) “Planned” does not mean immediate

When an issue is labeled planned, it means:

• the idea is accepted,
• but timing depends on complexity, risk, and available time.

No ETA is guaranteed unless explicitly announced.

5) How to increase chance of fast resolution

Reports move faster when they include:

• exact reproduction steps,
• expected vs actual behavior,
• app version + Android version + device model,
• logs/screen recording.

6) Labels you may see

• needs info: Missing details, waiting for reporter response
• confirmed: Reproduced by maintainer/contributor
• planned: Accepted for future work
• in progress: Being implemented
• duplicate: Tracked in another issue
• wontfix: Not aligned with current scope/constraints

7) Closing policy

Issues may be closed when:

• fixed in a newer build,
• duplicate of an existing tracked issue,
• missing requested info for an extended period,
• outside project scope.

Thanks for reporting clearly and helping improve PixelPlayer.