-
Notifications
You must be signed in to change notification settings - Fork 2
Description
Purpose
This issue proposes a standard Kanban board layout for use with GitHub Projects across the AerynOS organisation.
The goals of this layout are to:
- Make priority visually obvious
- Align clearly with MoSCoW prioritisation
- Separate triage, planning, and execution
- Scale across multiple repositories
- Work cleanly with the proposed label taxonomy (
priority:*,status:*,type:*)
This proposal is intended to complement the roadmap work and the issue/PR label
standardisation proposal.
Proposed Column Order (Left → Right)
Untriaged / Backlog | Won’t Do (at this time) | Could Do | Should Do | Must Do | Ready | Doing | Done
The further right an item appears on the board, the more important and/or actionable it is.
Column Definitions and Usage
Untriaged / Backlog
Purpose
- Default landing column for all new issues and pull requests
What goes here
- Newly created issues and PRs
- Items missing priority, scope, or clarity
Expected labels
status: triage- Often combined with
type: needs more information
Won’t Do (at this time)
Purpose
- Explicit holding area for items that are out of scope for now
What goes here
- Valid ideas or requests that do not align with current goals
- Work deferred indefinitely but not closed
Expected labels
priority: wont
Notes
- Items may move out of this column if priorities change
Could Do
Purpose
- Nice-to-have, low-risk improvements
What goes here
- Opportunistic enhancements
- Non-essential features
Expected labels
priority: could
Common pairings
good first issueeffort: small
Should Do
Purpose
- Important improvements that materially increase quality or usability
What goes here
- Meaningful but non-blocking work
- Often planned into upcoming milestones
Expected labels
priority: should
Must Do
Purpose
- Critical work required for stability, releases, or security
What goes here
- Release blockers
- High-severity bugs
- Core functionality gaps
Expected labels
priority: must
Ready
Purpose
- Work that is fully defined and ready to be picked up
What goes here
- Items with clear scope and acceptance criteria
- No outstanding questions or dependencies
Expected labels
status: accepted
Notes
- Items should only move here after triage is complete
Doing
Purpose
- Work that is actively in progress
What goes here
- Issues or PRs currently being worked on
Expected labels
status: in progress
Notes
- This column should ideally be WIP-limited
Done
Purpose
- Completed work
What goes here
- Merged pull requests
- Fully resolved issues
Expected state
- Issue closed or PR merged
- Optional
status: donelabel if desired
Suggested Workflow
- New issues and PRs start in Untriaged / Backlog
- During triage:
- Assign
type:* - Assign
priority:* - Add
area:*where appropriate
- Assign
- Move items into the appropriate MoSCoW column
- Once fully defined, move items into Ready
- Active work moves to Doing
- Completed work moves to Done
- Out-of-scope items move to Won’t Do (at this time) with a brief explanation
Why This Layout
- Encourages deliberate prioritisation before execution
- Makes high-impact work immediately visible
- Reduces reactive or ad-hoc task switching
- Works naturally with GitHub Projects v2 filtering and automation
Next Steps
- Agree on this layout
- Create a GitHub Project using these columns
- Apply labels consistently across repositories
- Optionally add automation rules (auto-triage, auto-done on merge)
This proposal is intended to evolve as AerynOS grows, but provides a clear and shared starting point for project coordination.