Definition of generic structure for representing the STATE life cycle

[virgiliolino]

Small intro: this is a very creative moment in our organization, everything will change from one day to another. I just voted in favor of using AppFlowy, still this week I built a huge amount of documentation in Miro. In this ticket I'd like to start a discussion about what is written in the subject.
Using our typical example of a Kanban Board, I'm talking about a generic way to represent typical states: NEW, TODO, IN PROGRESS, etc.
Please lets stress the structure, it helps us to reason on it to visualize the concept as a Kanban Board, but sould be applied to every working process that start from NEW and ends into DONE.

I'm inviting every one to our Miro board, even if it will be perhaps for this week. I find it useful to progress
The board is this one:
https://miro.com/app/board/uXjVMqnQG9M=/?share_link_id=740242807354

[DeluxeRaph]

Each one of these states will require a transaction on the blockchain. Who is changing this state? Will the project manager(PM) have this ability? If he does how does he know a task is being worked on by a user, or if anyone has agreed to the work at all? In my opinion user should have to pledge themselves for the task. This pledge could be a small fee to change the state from TODO to IN PROGRESS. This now allows the PM to know the task has interest from the community and that it is being actively worked on.

[virgiliolino]

a couple of very good questions.

who is changing the state

there will not be one specific person like the PM to move forward the board. This is a bad behavior I noticed in many companies, this is top down, this is deresponsibilizing every team member, beyond that this would be not trust less.

on every state, an expert of that state will be allowed to update this task from one state to another. What does it mean an expert?
for example, if I request a pull request, this task of "reviewing a pull request" can be worked out only by a developer.

if I request a QA, this task can be worked out only by a QA.

Graphically there is this document that perhaps may help you to have a better overview:
https://miro.com/app/board/uXjVMqnQG9M=/?moveToWidget=3458764562429087145&cot=14

in this graph you may see some PINK sticky notes with messages like "MUST BE ANOTHER DEV", or "MUST BE A QA".
If you're curious about it, this graph is the result of brainstorming technique called brain storming, it is convention that constraints are colored in something near to read, like pink.