Notes on using workflow

Let's keep a loose list of things we notice while working on the issues:

Ideas:

I need a status for when I am waiting on something to complete my ticket, so that I can work on another one in the meantime
when I use the "Next" column to park new tasks that are shedding of the thing I am currently working on, and then i start working on one of the "Next" tasks, what status does it get? Also "Doing"?
is there any way for us to know or see when the status of an issue has changed, or how long an issue has been sitting in a particular column?
- doesn't seem to be something the interface tells you. But what we will do is: when you start working on it, you just comment briefly under it to say that you start working on it.
at the end of the day, when your issue isn't done yet, make a comment on the issue and explain where you're at or what the remaining work is
- this gives everybody a good sense of where we're at and also makes sure that we don't lose information

Week 1

Good:

feels less stressful than a sprint because you don't have a long list of things looming behind you

Improve:

not really clear where to put this list of good and bad things we notice (the Wiki is probably not the best place?)
there are a ton of issues in the main project, it is hard to prioritize and keep an overview
we could use labels more extensively to bring order to this chaos. But then we need to sync the labels across repos (maybe via GH API?)
I'm not sure what the role of "Next" is in our board

Ideas:

keep only high-level issues in the project, and then split them up into smaller items when work becomes more clear or begins. this, so that the backlog isn't hopelessly cluttered with items of very different significance
use the filter functions more on the board to organize and declutter. Big issues could have their own label or title class
only assign issues to the top level projects / roadmap when they reach a certain level of priority. The "Icebox" column is probably a sign that we aren't doing this well - those issues should just not be part of the project
start using epics again. we can just use task-lists and tagging: https://docs.github.com/en/issues/tracking-your-work-with-issues/about-task-lists#about-issue-task-lists. Then we could organize work with the epics and only go to the tasks themselves when work happens.

Kanban Notes

External recommendations

Keep the Kanban board as simple as possible (e.g. few columns) to start out. It can always become more complex if need be.
You will begin to notice is bottlenecks over time - like items sitting in columns for too long. This speaks to a key metric for Kanban users: "lead time" This is how long a feature/task takes to move from the backlog to completion.
Term that is used for the agreed upon limit for the number of tasks an individual can work on is the 'Work-in-Progress' (WIP) limit

Our noticings

A 'Next' column may be useful in order to for an individual to corral related tasks that they see will follow the current one they are working on
WIP limit may need to be flexible as sub-tasks will arise during work on one task, necessitating in the creation and self-assignment of the sub-task