_Originally started trying to answer @moul's comment:_

> this number looks scary: it's 2 too much for some people; it's 10 not enough for some other
> and it's completely incompatible with the fact that you don't own your in progress column if someone can review your task and move your unfinished task to in progress
>
> we should definitely encourage something instead of enforcing
>
> and a failed PR should go to TO DO, maybe

I tend to agree with you, together with the other "magical numbers" on this file.

Integrating with what you said, I think we need to think about projects without necessarily thinking of "gno" as a monoproject, but dividing it into many subprojects. The monorepo model is just a convenience, after all: it should not dictate how we organise work.

With that said, I have an addendum for how I see we can improve Tablero Infinito: a "hierarchical" project structure, with as many projects as we need, where each project may have its own "config" rules.

For instance, we can have these as the projects (`@` being the root):

@/                         -> lead by A
@/gnovm,@/examples         -> lead by B
@/tm2,@/gnoland            -> lead by C
@/gnovm/stdlibs,@/examples -> lead by D
@/gnovm/pkg/gnolang        -> lead by E

- In this example, people are not neatly divided into teams and concerns.
- You may consider this as a terminology switch from "team" to "area": there is an area leader for each file and each directory, but people are not enforced (and in fact, discouraged) from working exclusively in one area.
- The leader is also variable, and can be generally understood as "the most knowledgeable _in that domain_ who is willing to be the team lead".
- The leader may lead multiple teams at once.
- Sub-teams are always strict subsets of other teams; ie. there is no "venn diagram intersection": a team may only fully contain others.
- _This may not fit nicely all the time with code,_ but we can create "code ownership" rules that exclude certain directories, for instance: `@/tm2/pkg/crypto/keys/client` is owned by the same team as `@/gno.land`.
- The advantage of this is that it simplifies board views and rule determination overall, more on this later.

Crucially, as @moul was mentioning, the numbers set for reviews and so on cannot really be a one size fits all. IOW, a change in `docs` needs to be reviewed far less than a change in `gnovm/pkg/gnolang`.

So I propose that each team can configure the following variables:

# Maximum tasks by any team member at any one point.
max_tasks          = 3
# Approvals required by team members to merge a PR.
approvals_required = 2
# From which GH team should the approval count?
approvals_team     = "tech-staff"
# Can a lead merge their PR without approval from others?
lead_0_approval    = False

max_tasks may be capped at a higher level. (For instance, we may establish globally `@/` that the cap is 10, so that I cannot be working on an issue in Gnovm if I already have 10 assigned in examples, docs and tm2.)

An issue may only be specific to a team, but the corresponding PR(s) may touch multiple. The PR must be approved by `$approvals_required` of people in the `$approvals_team` for each touched sub-project. So if my work touches `docs` and `examples`, it must be approved by both.

> Note that if A is in the approval team for both `docs` and `examples`, then the `approvals_required` counter is decreased for both.

lead_0_approval only applies if the PR touches _only_ files lead by the same team leader.

> Ideally, the team leader should be the main point of contact for the subproject, and be aware at all times of all changes happening within.
> However, holidays happen, shifting to other projects happen, so the team needs to be able to continue without their permanent guidance.
> The idea behind `lead_0_approval` is a kind of "fast track" for things like documentation changes done by the team leader of the documentation project.

The last part about this idea for "hierarchical project" is that the top-level manager is still the only one managing the back-and-forth between `Backlog` and `TODO`. The top-level may also drop tasks (in progress -> todo) and move back from Done -> in progress, however these can be done by any team leader in the hierarchy. (It is still assumed that the top-level manager de/prioritizes based on the suggestions and discussions of each team lead)

What we should have, in the end, is a kanban board for each project:

- Sub-boards do not have a backlog column.
- Each board contains also the tasks for each sub-board, although they can easily be filtered out.

> This is probably overly complex. It would take probably 1 week to POC a GH action bot to enforce this and 1 month to get it usable. Some requirements in this may be dumb; but it is IMO a starting point to how we can recognise that within our very own projects we have different "subprojects" which have different approvals and merging requirements, and a one-size-fits-all approach doesn't work.