Automatically add issues to GitHub Project Kanban board for easier management

[chrisdebian]

Hi, all.

I can see that there are a lot of outstanding issues. It's good that the project is receiving feedback, but this amount makes it difficult to manage. Can I propose that this is automated to a certain extent, using GitHub's Projects, that can be set up as a Kanban board?

This would go something like this:

1. All new and open issues are automatically added to Projects > Kanban "Needs Triage" backlog column.
2. They would have labels attached to them, as a first pass at categorizing them, and some often used GitHub colours.

Label	Description	Suggested Colour
type: bug	A defect, unexpected behavior, or incorrect result.	#d73a4a (red)
type: feature	New feature request or enhancement.	#0e8a16 (green)
type: performance	Performance improvements or regressions.	#fbca04 (yellow)
type: docs	Documentation problems or requests.	#5319e7 (purple)
type: test	Test-related issues (new tests, failing tests).	#1d76db (blue)
type: tool	Tools/ecosystem (formatter, LSP, analyzer, IDE integrations).	#ff8c00 (orange)
type: build	Build system or platform-specific build failures.	#a371f7 (violet)
type: dependency	Issues or updates involving external dependencies.	#cfd3d7 (light gray)
type: question	Question or clarification needed; not actionable yet.	#f9d0c4 (peach)

3. They'd then have MoSCoW applied to them (Must Have, Should Have, Could Have, Won't Have (at this time)).

Label	Description	Suggested Color
prio: must have	Critical; required for upcoming releases or blocking development.	#b60205 (dark red)
prio: should have	Important, but not blocking.	#d93f0b (orange-red)
prio: could have	Nice-to-have; low urgency.	#0e8a16 (green)
prio: won't have (this time)	Intentionally deferred or out of scope for now.	#e4e669 (tan)

4. This would then allow contributors to pick the issues/ tasks that are most important, and aligned to the roadmap. These will mostly be from the "Must Have" column.

So, something like this:

[ Inbox / Needs Triage ]
↓
[ Needs Info / Needs Repro ] ←→ [ Ready for Work ]
↓
[ In Progress ]
↓
[ Review Needed ] ←→ [ Awaiting Author ]
↓
[ Done ]
(and occasionally → [ Blocked ])

This would have the benefit to devs of having a manageable backlog, and will hopefully prevent the users from re-submitting issues, or adding comments to existing issues, to "bump" them.

What does anyone think?

Cheers,

Chris

[Wajinn]

I can see that there are a lot of outstanding issues

There are outstanding issues with all widely used or popular programming languages. The proper context to view it, is arguably the open issues to close issues ratio. In that regard, V is doing very well (open to close ratio). Of course there is perfect, but we should be realistic.

set up as a Kanban board

Do you have experience with using a Kanban board for software development and issues? It's one thing for us to tell others to use something versus we have used it and can give stronger guidance or arguments for its use.

[chrisdebian]

That seems fair enough. Yes, I do have experience with Kanban boards, but as you say, "V is doing very well (open to close ratio)", so I don't think my idea will add any value. I won't close this, right now, because it's meant to be a discussion, but if anyone else feels that the subject has finished being discussed, then please close.

Thanks,

Chris.

[Wajinn]

To add a bit more. Agree with keeping this open. Something that might be considered, is the age of issues too. While there can be a good open to close ratio, there may be very old issues that haven't been addressed or are no longer relevant, so should be closed. Happen to find that this was mentioned previously (24497).