So a few weeks (months?) ago GitHub released a Projects feature that is same-same-different to the functionality offered by Zenhub (read about it and the new Reviewers feature here).
You can access the Projects feature from the tab at the top of the GH interface, it’s next to the Pull Requests tab.
@oeoeaio and I have been playing around with the feature to see how it compares to zenhub and whether it is something that may benefit the OFN community. And the result - we think it will in trying to manage the bigger projects that come through (Standing Orders, or Bulk Import), but even more in term so managing each local team’s priorities for non-project ad-hoc issues that are being worked on by their teams.
Why we think this is a good idea and the problems it solves:
- Experience with the UK dev pipe is that once an issue gets put into a release milestone they lose track of it in their own UK Current GitHub list.
- It allows us to use Milestones purely for releases rather than as another way of grouping issues that are relevant to a project or local instance
- The above ^ means that we can assign a milestone AND a project to an issue/PR. Which means I wouldn’t have to move something out of UK Current or Standing Orders or whichever milestone we’re using, I would just attach the release milestone. Much cleaner approach.
- We tried something similar with labels but it didn’t work as well due to the milestone groupings being preferred.
- We also use Epics but they’ve become more than just the higher level story for a feature, they’ve almost become the catch all for all the stories within a feature (e.g. standing orders and bulk uploads).
Here’s an example we put together on how it could work:
You can see I’ve added all the issues (not PRs) from the UK Current milestone into a UK Current Project. I recreated all the same columns as we use as steps in the dev process (Backlog, Dev Estimate, Dev Ready, etc etc). You can add things to the project by searching for them through the ‘Add Cards’ link on the top right of the board and dragging them into a column. You can remove them by clicking on the down arrow on the issue itself and selecting the option.
This view gives non-tech people like @NickWeir and @MyriamBoure and @CynthiaReynolds a place to manage all their priorities and see where they are in the process. It’s a simple way of creating a list of things to talk about when you’re doing standup or some kind of catchup or deciding what the next priority is.
The only issues I have with it are firstly that Zenhub are not integrating it into their offering at this stage (tried and failed), and secondly that it’s not as advanced a board as Zenhub when it comes to things like linking Issues and PRs.
GitHub Projects Issues/PRs view
Zenhub Issues/PRs view
So, next steps. We’re going to try it out with a couple of projects we run here in AU. It would be ever so wonderful if other local teams (@lin_d_hop, @MyriamBoure) tried out a local pipeline board and determined whether it worked well for them also. Then we can decide on whether we set up in this way and write up the process so that everyone has a “how to” guide on it.
NOTE: Outside of this we still have the issue of permissions and allowing everyone to use labels and move things through the pipeline columns, etc. We’re trying to figure out the best approach for this…more thoughts to be posted separately soon.