Proposal: GitHub Projects Kanban Layout (MoSCoW-Driven)

[chrisdebian]

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 issue
• effort: 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: done label if desired

---

Suggested Workflow

1. New issues and PRs start in Untriaged / Backlog
2. During triage:
   • Assign type:*
   • Assign priority:*
   • Add area:* where appropriate
3. Move items into the appropriate MoSCoW column
4. Once fully defined, move items into Ready
5. Active work moves to Doing
6. Completed work moves to Done
7. 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.