Triage and classify GitHub issues for the Vorta project. Use when reviewing issues, applying labels, deciding whether to close issues, or evaluating feature requests against project scope.
Use this policy to classify, label, and manage GitHub issues for the Vorta project.
status:ideastatus:wontfix with comment directing to BorgBackuphelp wantedtype:support.type:bug - Something doesn't work as intendedtype:enhancement - Improvement of an existing functiontype:feature - New functionalitytype:question / type:support - Questions about using Vortatype:docs - Documentation issuestype:refactor - Code refactoringtype:translations - Translation problemspriority:high - Security issues, data loss risks, crashes in core functionalitypriority:medium - Broken features with workaroundspriority:low - Cosmetic issues, minor improvements, edge cases| Label | When to Apply |
|---|---|
status:idea | Valid suggestion but: adds complexity, requires external dependencies, environment-specific, or rare use case. Keep open for discussion. |
status:wontfix | Outside project scope OR belongs in Borg itself. Close with explanation. |
status:duplicate | Already reported. Close and link to original. |
status:invalid | Not actionable or not a Vorta issue. Close. |
status:needs details | Missing reproduction steps, version info, or logs. |
status:not-reproducible | Cannot reproduce with provided information. |
status:planning | Large accepted feature needing design discussion. |
status:ready | Fully specified, ready for implementation. |
status:stale | No activity for 60+ days awaiting reporter response. |
os:linux, os:macos, os:windowspackage:flatpak, package:pip, package:native-linux, package:pyinstallerhelp wanted - Maintainers need community help (testing, implementation)good first issue - Simple change for new contributorsIs this a Borg feature request?
├─ YES → status:wontfix, close with comment linking to BorgBackup issues
└─ NO → Continue...
Does it add significant complexity?
├─ YES → status:idea
└─ NO → Continue...
Does it require new external dependencies?
├─ YES → status:idea
└─ NO → Continue...
Does it only work in specific environments?
├─ YES → status:idea (+ help wanted if testing needed)
└─ NO → Continue...
Is it a rare/niche use case?
├─ YES → status:idea
└─ NO → Accept as type:feature or type:enhancement
Close immediately with explanation:
status:wontfix)status:wontfix)status:invalid)Close after waiting period:
status:needs details for 30+ days → add status:stale, close after 14 more daysKeep open with status:idea:
Before marking as status:needs details, check for:
This feature would need to be implemented in BorgBackup itself rather than Vorta.
Vorta is a GUI wrapper and relies on Borg's capabilities.
Please consider opening a feature request at: https://github.com/borgbackup/borg/issues
Closing as `wontfix` since this is outside Vorta's scope.
Thank you for this suggestion! This is an interesting idea, but it would add
significant complexity / require external dependencies / only affect specific
environments.
Marking as `idea` to keep the discussion open. Community contributions are welcome
if someone wants to implement this.
This has been addressed in version X.Y.Z / commit abc123 / PR #NNN.
[Brief explanation of how it was fixed]
Closing as resolved.
We cannot reproduce/test this on [platform]. Adding `help wanted` - if you have
access to [specific environment], please help verify this issue.
| Scenario | Labels |
|---|---|
| Critical bug | type:bug, priority:high |
| Minor Linux-only bug | type:bug, priority:low, os:linux |
| Good starter task | help wanted, good first issue |
| Needs macOS testing | help wanted, os:macos |
| Complex feature request | status:idea, type:feature |
| Flatpak packaging issue | type:bug, package:flatpak |
| Borg feature request | status:wontfix (then close) |
| Accepted large feature | status:planning, type:feature |
status:needs details issues, apply status:stale if no responsestatus:idea issues for relevance, close if obsolete