Trying out GitHub Boards

Recently I became a fan of Kanban boards, see the article about board software. GitLab has boards for a while, and GitHub has them too now. I wanted to try them out, but it turned out to be quite hard to understand at first. After understanding Jira, I have a different mental model for such boards. Basically there are two major ways of having a board:

1. The board can be the fundamental thing. This is how Trello and Todoist work. You define columns, then you add your issues as cards on that board. The cards don't have intrinsic state, rather their status gets defined by their position on the board.
2. The board is just a view. Fundamentally the cards correspond to tickets which have certain meta information attached to them. You can create multiple board views from the same underlying pool of tickets. This is how Jira and GitLab issues work. Jira issues have a status, and you map statuses to columns. And in GitLab you specify filters for each column (usually with tags) and then tag the issues such that they appear in the columns.

GitHub seems to be neither of that. And I find it really confusing. This is what I could understand about it.

When using Agile, one usually has some sort of planning period. You have a “backlog” where you have a virtually unlimited supply of ideas. For each iteration one choses a handful and puts them into the “to do” (or “planned”) column. From there on the developers take issues into “in progress” and eventually discard them in “done”. If there is formal testing in place, there may be “in QA” or something like that.

Trello supports this workflow by just letting you have a ton of tickets in a column named “backlog”. Jira supports this by having the tickets in the “open” state (and displaying them in the “backlog” column). You then mark them as “ready” and they appear in the “planned” column. One can also drag them there, and Jira will do the modification to the underlying data.

But with GitHub, it feels strange. You have your regular flat list of tickets. And completely separate you have a board, which for instance looks like this:

Then you click on “add cards” in the top right and open a drawer with issues from the issues list.

You can select an issue from there and turn it into a card, put it somewhere you want. It will then appear on the board.

And then you can move it around the columns of the board.

In the ticket view, it is marked as being present on one of the boards. You can also see which column it is in. You see the status changes, but the changes on the board don't necesarily propagate back into the issues.

Just like with Jira, one can open a sidebar with information about the issue when one clicks on a card. One can also change metadata there.

At this point, GitHub boards feel extremely weird. They are neither a view onto the available tickets, but they also aren't the exclusive boards like a Trello board would be. I have the impression that the issue list is supposed to be the backlog, and the boards are then used to plan a sprint. In this case it makes sense, adding cards to the board manually is sprint planning. But I find it odd that tickets have a status of “open” and “closed”, and yet they can be in any column of the any board. A ticket could be in the “done” column of one board, and in the “in progress” column of another board. I imagine that perhaps two different teams (frontend and backend) work on the same issue and one is already done with their part, while the other isn't. But then wouldn't it make sense to have two smaller tickets for that?

There are configurable actions that can be triggered when a card is moved from one column to the other. One can also add actions when issues are created to also create cards. This feels highly flexible, and one can likely emulate both the Jira and Trello workflows with that. But it feels really overengineered in the sense that it has so many degrees of freedom that I find it too hard to understand. And when the tool which should manage my work, becomes too complicated to use, it isn't helping.

If somebody could enlighten me, I'd be delighted. Until then, I'll just continue to use the flat list of issues that GitHub always had.