Welcome to the NZRT Wiki Podcast. Today we’re looking at ?? Issues & Projects.

If you’ve ever wanted a way to track bugs, plan features, and keep your development work organised in one place, GitHub Issues and Projects are exactly what you need. Let’s walk through how they work and how NZRT uses them day to day.

So, what is a GitHub Issue? Think of it as a conversation-backed task card. You create one with a title, a description, and a few extra details, and from that point on it becomes the single place where everything related to that task lives. Issues come in a few flavours at NZRT. You might open one for a bug someone found, a new feature the team wants to build, or a piece of documentation that needs writing. The type of issue is communicated through labels. Labels are just tags you attach to an issue to categorise it. You might have labels for priority, for which system is affected, for which team owns it, or for where it sits in the process.

Alongside labels, you have milestones. A milestone groups a set of issues together under a shared goal, like a release or a sprint. When you look at a milestone, you can see at a glance how many issues are closed versus still open, which gives you a quick health check on whether you’re on track. Then there are assignees, which is simply the person or people responsible for getting that issue done.

Now, one of the most useful things you can do with issues is link them directly to your code. When you’re writing a commit message or describing a pull request, you can reference an issue by its number, and if you use the word “Closes” before that number, GitHub will automatically close the issue the moment that pull request is merged. This keeps your board clean without any manual housekeeping.

To make sure issues are reported consistently, NZRT uses issue templates. Templates are pre-filled forms that guide whoever is opening the issue through what information to include. Let’s look at the two main ones.

The bug report template asks you to fill in four things. First, a brief description of what the bug is. Second, the steps to reproduce it, written out as a numbered sequence so someone else can follow along and see the same problem. Third, what you expected to happen, and fourth, what actually happened instead. There’s also a section for environment details, things like which browser you’re using, which version of PHP is running, what your Laragon environment looks like, and which versions of WordPress or Dolibarr are involved. That context is often what makes the difference between a bug that gets fixed quickly and one that takes days to pin down.

The feature request template is a bit different. It starts with a description of the feature itself, then asks you to explain the use case, meaning why this feature is actually needed and what problem it solves. Finally, there’s an acceptance criteria section where you list out the specific conditions that need to be true for the feature to be considered complete. This is really valuable because it means everyone, developers, testers, and stakeholders, agrees upfront on what done actually looks like.

Now let’s talk about GitHub Projects. Where issues are the individual task cards, a Project is the board that holds them all. NZRT uses a board called the Dolibarr-Custom Board, and it’s organised into six columns that represent the life of a piece of work from start to finish. Something lands in Backlog when it’s identified but not yet started. It moves to Design when it’s in the design review stage. Once someone picks it up and starts building, it moves to Development. From there it goes to Testing, which is your QA phase. Once testing passes, it moves to Deployment, meaning it’s ready to go live. And finally, when it’s out in the world, it lands in Done.

Projects also support automation, so you can set rules that move cards between columns automatically based on events, like an issue being closed or a pull request being merged. That saves a lot of manual drag-and-drop work and keeps the board accurate without relying on everyone to remember to update it.

If you want to dig deeper into the GitHub ecosystem, this topic connects closely with the GitHub Overview, Pull Requests, and Collaboration Overview pages in the wiki. Those will give you more context on how issues and projects fit into the wider workflow of code review and team collaboration at NZRT.

In short, Issues give you a structured, consistent way to capture and track work, and Projects give you the visual layer to see how all that work is progressing. Together they make it a lot easier to stay on top of what’s happening across your repositories without things slipping through the cracks.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.