Hi everyone! Alloverse PM Tobes here with another update on how we do open source product development. This time I’ll be taking a closer look at the GitHub Projects beta and share some of my thoughts on it. Let’s go!
First off; readers of Nevyn’s latest post will recall this illustration regarding project tracking tools:
When we began working on Alloverse, Shortcut was our initial tool of choice. While very competent, it was perceived by the team as complex and overwhelming. Sometimes even the most basic things, like planning and viewing sprints, felt like a drag.
More importantly though, Alloverse’s focus is on developing in public – and Shortcut doesn’t allow for viewing boards from outside the organization. Thus, we had more than enough motivation to switch tools.
Enter GitHub Projects
GitHub is a central part of Alloverse. All our code is hosted with them, and the years they’ve spent creating the largest hosting platform for open source have generated a great deal of trust and goodwill. As such, the bar to entry for trying out another one of their tools was very, very low.
As some some readers may already know, GitHub has supported simple project tracking for a long time. However, the tool’s been very barebones and, honestly, quite lacking. In that light, it’s very exciting that they’re currently working a major overhaul which, in a burst of exhilarating creativity, was dubbed “Projects Beta”.
I brought it up to the Alloverse team, and we made the decision to get on board. Now, after having used it for a few months, here’s my short list of takeaways. I hope they can be of use for you.
The Good Stuff
- Views (tabs with filters) can be made public. As previously explained, this is a hard requirement for us, and I’ve yet to see another tool that allows for this.
- The ability to directly link a group of issues with a particular label (tag). For example, here’s a direct link to all Good First Issues for people new to the project. Pretty cool!
- GitHub Projects is lightweight and, for most developers, familiar. Internally, we’re simply more likely to use it than other unfamiliar or more complex tools.
- Because it’s built on the code hosting platform and all its usual functionality, GitHub Projects provides straightforward, logical couplings with a project’s ongoing issues.
- Keyboard shortcuts everywhere makes navigating and using the page a breeze.
The Not-So-Good Stuff
GitHub Project is still very clearly in beta. It’s not buggy, but it is clearly lacking features. This leads to hacks, which in turn leads to frustration and increased complexity.
- Unfortunately, milestones are solely available on a per-repo basis, not per-project. An Alloverse Milestone can involve any number of our 50+ repos, and it’s not realistic for us to create the same milestone 50+ times across all repos. 😬
- There’s no concept of Epics. As it stands, we’re currently hacking this desired functionality together – but neither creation or syncing of the related issues is automated, so it’s never certain to be an exact representation of the actual work done.
- Inability to link issues to each other, like “A is blocked by B”.
Hacking Milestones & Epics
To work around GitHub Projects’ lack of Milestones and epics, we’ve created an empty repo called open planning (and created a tab/view for it; “2022Q2Q3” below):
In this repo, we’ve added a few issues and (with a current Milestone label) beginning with “EPIC”, as such:
Each of these quasi-epics, in turn, contain a list of issues that relates to it. These have to be added, and linked to, manually, as part of the issue description.
It’s a bit tedious, but it’s the best solution we got so far – feel free to check it out here. It’s high on my wishlist for GitHub to add this functionality natively by providing us:
- The ability to create milestones on an organizational level.
- A concept of an epic. Preferably, it would be able to automatically generate a description (such as our checklist above) based on which issues gets linked to it.
- Epics could have custom properties (why not use the already-existing concept of labels?) such as “research”, “mockup”, “design” etc. Said labels could then act as headers to its corresponding sub-list of issues (so our solution above is achieved automatically).
- When an issue is closed, the corresponding checkbox in the Epic gets checked. No manual checking tickets allowed – it’s important that the list is always tightly coupled with the actual issues.
What the Future Holds
Their new Projects feature is obviously a major focus for GitHub, and they’re far from done with it. According to their own marketing team, several of our problems are actively being worked on right now. In addition, I’m excited to try out some all-new features also in progress, such as custom-made, automated workflows. They have the potential to be quite useful for further keeping the project up-to-date with its actual progression, such as by automatically closing issues and setting its status to “Done” when its pull request have been approved.
Conclusion
After having used GitHub Projects Beta for a few months, we’ve found it to be a good fit for us, and we have no plans of switching away from it. While it has some problems, the most important of them are actively being worked on by the GitHub team (although it would be nice to have access to a timeline…).
Over a transitional period, we’ll still be keeping Shortcut for large-scale milestone planning. Additionally, it serves as a bucket of backlog issues and ideas from the past couple of years which will slowly get migrated to GitHub issues as we move forward.
That’s all for now – thanks for reading! If you’d like to check out GitHub Projects Beta in action, take a look at our current sprint, or the Milestone we’re working toward.
