I just don't get GitHub Projects

For my personal projects I use GitHub. At work I use a lot of Kanban boards, and GitHub supposedly has them too. I just don't get how one should work with them, they feel rather weird compared to Jira.

So for my project I have a flat list of issues. And they have a binary status property, either they are open or they are closed. There is no “planned”, “in progress”, “in quality assurance” or “ready for release”. This is nice to get started and likely works for a lot of things.

But when I do some sprint planning, I already have a problem with this. How do I represent the issues that I work on this sprint? How do I add metadata about which version contains the fix? How do I track which issues have been started on, but aren't finished yet?

With Jira all of these things are not a problem at all. There is tracking of releases and you can assign a “fix version” and a “problem version” to each issue. This way you can see which issues appear in which release and also which release fixes which issues. On top you can define an arbitrarily complex workflow with all the intermediate statuses that you want.

Compared to Jira, GitHub issues feel like a child's toy. The issue system in GitLab seems to be more advanced but not as comprehensive as Jira.

But let's dive in and give it a try. In the repository there are no projects, so let us create a new one.

There we're asked what style of project we want to have. I'll just use a Kanban board because I don't want anything more at this point.

I need to give it a name. That might make sense. In Jira you basically have a pool of issues. Then you define custom filters on them. Finally you define boards as views of a certain filter. You define which statuses go into which columns. And then your board is populated. So it makes sense that GitHub also supports multiple views onto the same pool of tickets.

When we create the new project, it is empty. Also in the URL you can see that it is not attached to the repository but to my personal account. That is already a tad weird.

This weirdness is to be explained by the ability to put issues from multiple repositories onto a single board. The idea is that you can have some sprint or other bigger unit of work that consists of issues in multiple repositories. I can get what they aim at.

And now the weird part starts. How do you get issues onto your board? In Jira you define the filter and then have them. In GitLab you define a handful of tags and then create board columns for each tag. So you would define tags like “planned” or “in progress” and map those to columns. Everything without a tag would end up in the default column. As soon as you drag issues around, they are assigned a different tag. This way the column information is also visible in the tickets.

Okay, but how is that here? We just have an empty list.

And I can add single issues by just typing their name, ID or paste the URL.

They cannot be serious! I have to import every single issue of my project manually?

Well, there is the option to bulk-import them, though only the most recent 25 issues.

Here I only have 9 open issues, so that is fine. In some sense it makes sense to import things which are closed, but also it doesn't really make sense. At least I can filter there.

Now we have imported all of them to the board. They sit in the “no status” column which popped up.

So what does that mean? Aren't they all “to do”? Let me drag them over.

So now the Kanban feature complains that there are more than five things in “to do”. Ah, so that is actually the “planned” column and not the backlog. Why is the current tab called “backlog”? Isn't the thing that we view the actual board?

We can open a preview of the issues by clicking on them. Then you have an overlay which gives the detailed view. And the column position isn't really put into the metadata of the issue, rather it is just mentioned in the activity of the ticket.

This all feels very weird. It seems that you aren't supposed to import all the tickets right away. Rather one should just import those which shall appear on the board. On the flipside, newly created issues don't automatically appear on the board. You have to manually add these issues to the board. Also the status on the board doesn't exactly propagate back to the ticket. You can have the weird situation where a ticket is closed, but on the board it is still in a column which indicates open work. Or the other way around.

Also the board doesn't serve as a replacement view over the tickets. Basically you need to take a look at the issue list and then manually add the new ones to the board. If you miss one, it will just not be worked on. And you need to propagate changes between the board and the issues themselves.

So basically the GitLab Project boards are a whiteboard thing where you can just add issues from all repositories and so something that is detached from the actual issues. So the planning part is not done within the board, but rather by deliberately adding selected issues to that board. That means that one needs to open the issue tab on the repository and then go through the open issues and add them to the board. And there is no easy dragging functionality, it seems.

I think I now get how it is supposed to work, but it doesn't amaze me. It still feels pretty cumbersome.

Perhaps I just don't get it yet. So I've read some article about it and the article is involuntarily funny. It starts off with this superlative:

On September 14th, 2016, GitHub shook the world with their new “Projects” feature. It’s first-class support for project management. And it’s incredible.

And then later:

With these new additions to GitHub, it’s hard to believe that any other option can compare anymore!

So, GitHub added some boards and they are not even close to Jira. But apparently there are enough people who lack the experience with a professional issue system that they think that GitHub now has the best there is. I guess if you haven't used the other ones, you might actually think that. And so this tells me what the target audience for this is: People who have no clue how Jira works.

The article makes it seem that I didn't miss anything, it is just is the way that I've discovered. Perhaps it is useful for some, but I don't really see the value in it.

And I still consider whether it is worth to move that repository to GitLab because their boards are a tad more sensible. Though such a move always disrupts things. People have to update their repository URLs in Git, they need to update their bookmarks. The issue situation isn't so bad that it really warrants a move.

In order to simulate the Jira statuses, I have just created some labels in GitHub:

This way I can see what I have started working on and where I need some more information from the reporters:

It isn't a nice board, but it should work sufficiently well with the rather small number of issues that there are in this project.