For as long as I’ve been a part of a WordPress-centric company, I’ve had to maintain a large catalogue of products. Keeping track of bugs to fix and enhancements to build has been a challenge, as originally at WooThemes we kept track of this on SVN in combination with our own custom forum.
Since joining Automattic when Woo was acquired, I found this challenge only increased due to the size of the company and the vast amount of information on top of managing the products on my team.
The way I was handling this at the time was that all the products were in individual repositories in Github. The biggest problem here, is that Github doesn’t have a centralized dashboard where you can immediately see which repositories have been neglected or have a large number of open issues.
I would have to manage these repositories using my daily notifications screen, assigned issues screen, and going through my “watch list” – the problem with doing it this way, is that I could easily miss a notification, or not assign an issue properly to myself, or even worse, while clicking through to each repository on my “watch list” I might miss clicking one! My “watch list” is a paginated list, and there are 100 repositories per page. The risk of error with that amount of product repositories is high!
So I set about to improve this situation by hacking together a very basic plugin for a local WordPress installation, and used a Github personal access token to query the Github API, and came up with a simple tabulated list of repositories which show the number of open issues.
And this worked for a number of months.
But it wasn’t optimal, never mind being close to a perfect solution – it didn’t give me an indication of open pull requests, or what the issues were about, and the sorting of the list was terrible. It was a simple dump of repositories that I had on my “watch list”. This meant that replicating this for my teammates was a big problem, prone to error, as they had to go and follow each of those repositories manually in order to replicate my dashboard.
So my dashboard was actually amplifying my problem in the long run.
Thankfully I have some pretty awesome teammates 🙂 Ernesto Méndez is the undisputed script/tools king of the Theme Team, and while I was away on paternity in early 2017 he handled my workload. I had left instructions and access to use my dashboard, and I’m glad I did, because he ended up making an incredible new variation of it!
He removed the dependency on a personal “watch list” and added a repository JSON config file, much like NPM package files. This means that we could, in theory, roll this out to multiple team members with a central config file of products to maintain. This eliminates individuals becoming single points of failure.
The implementation had some other clever ideas to not query Github on every page load by doing a synchronization with the API data when I needed to by clicking a sync button.
The end result is a dashboard which shows me,
- The different types of products I’m maintaining – Themes, Plugins, Libraries, and Tools.
- The priorities of those repositories – Priority, Selling (on woocommerce.com), and Maintenance (but not sold anymore).
- Number of open issues, with a basic description of the issue if I click the repository to drill down.
- Number of open pull requests, with a basic description of the issues.
- Bonus Points: He used the Github styles for a consistent experience as if you were on Github. Very slick 🙂
This shows me everything that I need to know on 1 page. So, since the first iteration of my workflow, I’ve gone from over 100 click throughs, to 1 well organized page!
This has been a 2 year process to get to this point, but the value in doing constant workflow improvement has been immense! While this isn’t perfect, it’s pretty close, and it has made a huge difference in getting a handle on maintenance volumes.
Automattic Design 