📋 Project Management
Project Tracker
GitHub issues and pull requests are the authoritative record for all work in the Z-Shell organization. Open issues are tracked across repositories in Z-shell Delivery, GitHub Project 28:
Open Z-shell Delivery →
The project board is the cross-repository execution view: status, priority, impact, effort, and dependencies. It does not replace the owning repository's issue thread, which remains where discussion, implementation, and review happen.
The board separates workstreams into views so unrelated work does not compete for attention:
| View | Contents |
|---|---|
| Human delivery | Ordinary bugs, features, maintenance, and documentation |
| Automation | Bot dashboards and recurring automation records |
| Dependency maintenance | Routine dependency updates and dashboards |
| Security | Security work requiring maintainer attention |
| Administrative | Organization and repository governance |
What Happens After You File
A maintainer triages the issue: classifying it, setting the board fields, and linking it to related work. You do not need to set any of this yourself.
Related issues are connected using GitHub's native parent and sub-issue relationships; blockers use native issue dependencies, so if your issue is waiting on something else that link is visible on the issue itself.
Pull requests appear on the board once they are linked to a tracked issue or are
ready for review. Closed and merged items move to Done.
The full maintainer procedure lives in the triage runbook.
Capturing Deferred Work
Do not leave postponed work only in local diffs, review notes, or a chat thread. Create or update an issue in the repository that owns the work so it stays visible.
When splitting or deferring work:
- Create one issue per logical task so each can be prioritized and completed independently.
- Include enough context for someone else to resume later: the observed problem, why it matters, relevant files, and known constraints.
- Use the canonical labels described below instead of repo-local tracking conventions.
Do not create standalone project-only items for a deliverable that belongs in a repository issue.
Priority
Maintainers set priority during triage; contributors do not need to. If your issue is urgent, say why in the description rather than setting a field — the justification is what drives the decision.
The bands and their meanings are defined in the
triage runbook
in z-shell/.github.
Where to File
Always open issues and pull requests in the repository that owns the work. That thread is the authoritative record.
Maintainers additionally mirror a small amount of cross-repository, strategic, release-blocking, or security-sensitive work into an internal planning tool. That mirror is a convenience view for maintainers and is not a source of truth — nothing there replaces the GitHub issue, and contributors never need to consult it.
Labels
All repositories in the z-shell organization share one canonical label set. A
maintainer applies labels during triage — you do not need to set them yourself,
though knowing what they mean helps you read an issue's state.
The authoritative list, including colors and descriptions, is
lib/labels.yml
in z-shell/.github. That file is the source of truth; this page summarizes it
rather than restating it, so the two cannot drift apart.
Namespaced labels are written without a space after the colon — type:bug,
not type: bug. Spaced variants are legacy and are being retired.
What the namespaces mean
| Namespace | Answers | Examples |
|---|---|---|
type: | What kind of work is this? | type:bug, type:feature, type:docs, type:question, type:maintenance |
area: | Which part of the ecosystem does it touch? | area:zi, area:plugin, area:annex, area:package, area:docs, area:ci |
status: | What is blocking progress? | status:triage, status:blocked |
priority: | How urgently is it needed? | priority:high |
Standalone modifiers carry no namespace: regression, security,
performance, breaking-change, needs-info, duplicate, invalid, and
wontfix.
Labels worth watching as a contributor
| Label | Meaning |
|---|---|
good first issue | Well-scoped starter task — a good place to begin |
help wanted | Maintainers would welcome outside help |
needs-info | Waiting on more detail before work can continue |
status:blocked | Cannot proceed until an external dependency or decision changes |
Label Rollout
Creating and syncing labels across repositories is a maintainer operation. It is
documented in the
labels.md runbook
in z-shell/.github, together with the migration path for legacy names.