Follow Zube on Twitter

Introducing Local Cards

Create cards that don’t go to GitHub

For most companies, not every card on Zube also needs to be a GitHub issue. Zube now lets you to create cards without creating an associated GitHub Issue. If you later decide that your local Zube card needs to be on GitHub, that’s no problem either. You can easily add the card to a source repository by selecting one on the card’s sidebar.

Zube card showing source selector

Seamlessly manage GitHub issues and local cards together

On Zube, your local cards function in the way you’re already used to. To create a non-GitHub backed card, select ‘Only on Zube’ from the source selector when you’re creating a new card. That’s pretty much all there is to it. Your local cards will appear right next to the GitHub backed ones on the kanban board, the sprint board, and the Issue Manager. You can also add local cards to epics, tickets, and sprints, just like their GitHub backed counterparts.

How to use local cards

There are many use cases for local cards, but I’ll highlight a few.

  1. Use local cards to plan new features. Imagine you are the product owner. You know that an important part of Agile project management is to continually refine your requirements by talking to your customers. When you do this, you’ll likely get a bunch of good ideas about how the product can be improved. Your ideas are probably more nebular than specific engineering tasks, so instead of making cards that get sent to the engineers on GitHub, make local cards! You could do this right on your main board if that makes sense for your team’s workflow, but I’d suggest creating a separate workspace for product features that are still in the idea phase. Then at a future date, when you have a clear picture of what needs to get done, you can create the necessary engineering tasks, or convert your local cards to a GitHub Issues by adding a GitHub source.
  2. Use local cards for your non-engineering teams. Your company probably has a workflow that involves multiple teams. Maybe the design team and the product team spec out what they’d like to see before handing it off to the engineering team. And when those new features are ready, they need to be marketed. Local cards let your non-engineering teams use the same system as your developers without adding clutter to the developers’ GitHub repositories.
  3. Use local cards to keep private data off of GitHub. Sometimes you just don’t want certain tasks to go to GitHub. There are a bunch of reasons for this but if you’re using Zube to manage a repository on GitHub where the entire world can view the GitHub Issues there, you might not want a critical vulnerability to be public knowledge. At least until you’ve fixed it.