Paid Work project board

One GitHub Project across all client repos, so there's a single place to see what's active, blocked and due. Designed but not built yet.

Scope

Paid client work only. Volunteer work stays out, otherwise the board stops being an honest picture of what I'm being paid to do.

One repo per client, and every client repo gets added to the same project.

Status options

Replace the default set with:

Status	Means	Appears in
To do	Queued and ready to pick up	To do
In progress	Actively being worked on	Now
Blocked	Stuck on something that isn't the client, a dependency, a decision, a third party	Blocked
Waiting on client	Stuck on the client specifically	Blocked
Done	Finished	none

No Inbox or Triage. Those exist to sift unscoped incoming requests, and since I create nearly all the tasks myself there's no unsorted pile to sift. Work arrives already scoped, so it goes straight to To do.

Blocked and Waiting on client are split deliberately. They need different actions from me, one is chasing a third party or a decision, the other is chasing the client.

Fields

Field	Why
Status	As above
Priority	What sorts the To do view
Due date	Also sorts the To do view
Up next (checkbox)	Marks the single next task per client

Deliberately not included:

Field	Why not	Add it if
Client	One repo per client, so the repo name already identifies the client	A client ever spans two repos
Repo	Projects already knows the source repo and groups by it natively	Never, it's duplicate data
Billing status	That's the invoicing tool's job, not a task board's	Never
Effort / Size	I don't estimate sizes today	I start estimating

Eight fields per issue is the kind of upkeep that quietly stops happening after a fortnight. Four is maintainable.

Delivery dates use GitHub's native per-repo milestones rather than a custom field.

Views

View	Filter
Now	Status is In progress
To do	Status is To do, sorted by Priority then Due date
Blocked	Status is Blocked or Waiting on client
By client	Grouped by repo, no status filter

There's no separate Next view. With a single To do status, filtering for "next" just returns the whole backlog. Sorting the To do view by Priority then Due date gives the same effect without a fake extra status.

The Up next flag

GitHub can't filter to "the top card in each group", so seeing one next task per client needs a flag.

Tick Up next on whichever task sits at the top of each client's queue, then build a view filtered to Up next = true. One row per client.

Cost is one extra click each time a task finishes and the next gets promoted. Start manual. Only automate if that click genuinely becomes annoying.

One board for status, not many

Don't run a second board for day-to-day status. An item's field values and drag order are per-board and don't sync, so the same issue tracked on two boards means maintaining both and trusting neither.

There is still a per-project board, created by the github-project-backlog skill at kickoff, but it has a different job: scoping, phases, and a client-facing roadmap. This board owns Status, Priority and Up next. The project board owns Phase and Target date. Keep that split and they don't fight.

Building it

Views can't be created through the API, so this board can't be scripted from scratch either. Same answer as the project template: build it once by hand, gh project mark-template it, and copy it if it ever needs rebuilding. Fields can be scripted with gh project field-create.

Later, maybe

Automating the Up next tick is possible but it's a real build, not a setting. GitHub Projects' built-in workflows can't compare items or look across a queue. It'd be a GitHub Action firing on Status changing to Done, using GraphQL to find the top remaining To do item for that client and tick it.

Catch: it would have to sort on Priority and Due date, because the manual drag order of cards isn't readily queryable. So the automation's idea of "next" and my card order could drift apart unless Priority is kept accurate.

Not worth building until the manual version has proven annoying.

Related

• Daily task roundup depends on this board existing, and on the Up next field.