Title: Do you have trouble presenting Github issues to non-technical clients as a freelancer?

In my last freelancing gig, I faced an issue with presenting our project status to our client. I'd like to know, am I alone in facing this issue? Have you experienced a similar problem? I explain further below.

Context

In my last freelance gig, I was building a website for a publishing client. We had a team of freelancers working on the website. I worked on the front-end website and also helped manage the roadmap for the team.

We kept track of our progress and outstanding issues on Github. It was a convenient way for us as developers to track issues, assign them, and manage the code base.

Problem

However, we didn’t have an easy way to present our project status to our client using the meticulously managed issues on Github. At first, we tried presenting the Github issues as-is, without any modifications. But they were not familiar with Github, some of them had to create Github accounts, and it caused a lot of confusion. Furthermore, they couldn’t tell which issues were most important, how to filter by issues, etc.

It didn’t make sense for us to train them on Github, since they would only be spending at most a few hours a month reviewing our work on Github.

Next, we tried using Zenhub and its Kanban boards to present our project status. Zenhub allowed us to add some needed metadata (like “effort points” and sprints). It helped a little bit, but the Kanban boards were not suitable when making a presentation in a meeting. To guide our planned discussion, we created columns on the Kanban board to group issues into various topics, ie “priority”, “completed in the last 2 weeks”, “critical UX bugs”, etc. But this method also was not perfect:

  1. We couldn’t include the same issue in multiple columns, by nature of the Kanban board. So if an issue was both a “priority” and a “critical UX bug”, we could only show it in one column or the other
  2. If a column had too many issues, the dashboard could not fit all of them on the screen. We would have to scroll down each column to show the rest of the issues. [A screenshot here would be nice...]. Again, most of our clients did not have a Github account to log in and view for themselves.

Overflow issues not immediately seen. Issues can only exist in 1 column at a time.

Overflow issues not immediately seen. Issues can only exist in 1 column at a time.

Makeshift solution

In the end, I learned how to create filters, and save the URLs of those saved filters within Github. Then, I would create an agenda on Google Docs, and add links to those views. So when we began to talk about one of the topics (ie “these are our priority issues...”), I would click on the saved link and it would open the full list of priority issues.

Question for you

From this experience, I figured there may be a missed opportunity here.