Welcome to the NZRT Wiki Podcast. Today we’re looking at the Code Review Process.

Code review is one of those practices that separates teams that ship quality software from teams that don’t. At NZRT, every code change goes through a structured review process using GitHub pull requests before anything gets merged. Let’s walk through how that works and what’s expected of you whether you’re the person writing the code or the person reviewing it.

First, let’s cover the key roles. There are two main players in every review. You’ve got the author, that’s the person who wrote the code and opened the pull request, and the reviewer, who examines the changes and gives feedback. Reviewers are looking at four main things: correctness, meaning does the code actually do what it’s supposed to do, style, meaning does it follow the team’s conventions, security, meaning does it introduce any vulnerabilities, and maintainability, meaning will future developers be able to understand and change this code without pain.

Now, not all feedback is created equal. Some comments are blocking issues, which are serious enough that the code cannot merge until they’re fixed. Others are suggestions, which are improvements the author can choose to address but aren’t required. Comments happen in threads attached to specific lines of code, so the discussion stays contextual and traceable.

So what does NZRT actually require before a pull request can merge? There are five things. The PR needs at least one approval if it’s targeting the develop branch, or two approvals if it’s going to main. All automated checks must pass, that includes linting, tests, and security scans run by GitHub Actions. The branch must be up to date with the base branch. Every conversation thread must be resolved. And if a CODEOWNER is assigned, they must have approved.

As a reviewer, your job is to genuinely understand the change, check the logic, look for security issues like exposed secrets or improper authentication, verify that edge cases and error handling are covered, confirm that new functionality has tests, and make sure documentation has been updated if needed. You should only approve if you’re actually confident in the quality of what you’re looking at.

As an author, your job starts before the review even begins. Write a clear title and description. Keep your PR focused, one feature or fix per pull request. When feedback comes in, respond to every comment, address it promptly, and request a re-review when you’re ready. Don’t merge without the required approvals, and don’t dismiss someone’s review without discussing it first.

Let’s talk through what good review communication looks like. Imagine a reviewer spots a SQL injection vulnerability. They’d explain the problem, show an example of the problematic pattern, which would be building a query by gluing a variable directly into a string, then show the correct pattern, which uses a parameterized query where a placeholder stands in for the user input and the actual value is passed separately. That separation is what prevents an attacker from manipulating the query.

When the author responds and fixes it, a good response acknowledges the catch, explains what was done to fix it, lists the specific changes made, such as switching to parameterized queries, adding input validation, and adding a unit test, and references the commit where those changes live.

Not every comment is a blocker. A reviewer might suggest extracting some logic into a separate method for reusability and explicitly flag it as not required for merge, just something worth considering for the long run.

The overall flow looks like this. You open a pull request. GitHub Actions run automatically to check lint, tests, and security. If they fail, you fix them before moving forward. If they pass, you request reviewers. Reviewers examine the code and either approve, leave comments, or request changes. If changes are requested, you address them and loop back. Once you have the required approvals and everything is green, a maintainer merges the PR and the branch gets cleaned up.

A few tips to make reviews work well for everyone. Be respectful and focus on the code, not the person. Ask questions instead of making accusations, something like “can you explain why this approach was chosen” is far more useful than just saying “this is wrong.” Suggest solutions, not just problems. Be timely, aim to review within twenty-four hours, same day if you can. Give context when you flag something, explain why it matters whether that’s security, performance, or readability. And don’t forget to call out good work when you see it. Reviews are as much about reinforcing strong patterns as they are about catching problems.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at ?? GitHub Discussions.

If you’ve spent any time in GitHub, you’re probably familiar with issues and pull requests. But there’s a third space in GitHub that NZRT uses just as actively, and that’s Discussions. Think of it as the team’s open conversation floor, a place where you can ask questions, float ideas, share news, or just check in with each other, all without cluttering up the issue tracker.

So let’s talk about what GitHub Discussions actually are and how NZRT uses them.

At the heart of it, Discussions are organised into categories. NZRT uses four main ones. There’s Questions, for when you need an answer from the team. There’s Ideas, for proposing features or improvements. There’s Announcements, for sharing important updates like releases or policy changes. And there’s General, for everything else, think project updates, team celebrations, onboarding, retrospectives, that kind of thing.

One of the most useful features in the Questions category is solution marking. When someone asks a question and another team member gives a helpful answer, the original author can mark that reply as the solution. This means the next person with the same question can find the answer instantly, without reading through a whole thread.

You can also upvote discussions and individual answers. So if someone asks a question you’ve been wondering about too, or if an idea resonates with you, a quick upvote lets the team know without needing a reply.

Now let’s look at some real examples of how NZRT actually formats these discussions, and I’ll walk you through what they look like without reading out any of the formatting characters.

The first example is a question post. It opens with a clear heading asking how to run tests locally. The person explains they’re trying to set up tests for a new WordPress plugin and want to know what command to use. Then they list their environment details, which include Windows 10 with Laragon, PHP version 8.1, and WordPress version 6.1. That’s a great example of a well-structured question. You’re telling the team what you’re trying to do, why you’re stuck, and exactly what your setup looks like. That context makes it much easier for someone to give you a useful answer.

The second example is an announcement post. The heading identifies it as a release, specifically version 2.1.0 of the dolibarr-custom package going to production. It then lists what’s new, in this case a product comparison widget, an advanced reporting dashboard, and a Dolibarr inventory sync. It notes the exact date and time of deployment, names the person who deployed it, and links to the full changelog on GitHub. That’s the kind of announcement that keeps everyone aligned. Anyone who needs to know what changed and when can find it right there in the discussion.

The third example is much simpler. It shows how you’d reference a discussion from inside a pull request or an issue comment. You simply write something like “Related discussion, number 5, how to set up the development environment.” GitHub will turn that into a clickable link automatically. This is how you connect conversations across the different parts of GitHub without losing context.

Now let’s talk about best practices, because how you use Discussions matters just as much as what you post.

The most important rule is to keep Discussions and Issues separate. Discussions are for conversation. Issues are for tracked work with assignees, labels, and milestones. If an idea in Discussions gains enough traction and the team reaches consensus, you convert it into an issue so it can be planned and implemented properly. That’s the intended flow: discuss, agree, track.

Before you post a question, do a quick search. Duplicate questions slow the team down, and the answer might already be there waiting for you. When you do post, give as much context as you can, including your environment, any error messages you’ve seen, and what you’ve already tried.

Keep the tone professional. GitHub Discussions are company communication, so treat them that way. That said, you can still use emoji reactions for quick feedback. A thumbs up, a rocket, a heart, these are all valid ways to respond when you don’t need to add words.

And finally, make sure you mark solutions when you get a good answer. It’s a small action that has a big payoff for everyone who comes after you.

Discussions also connect to the broader GitHub ecosystem. They’re referenced in the Collaboration Overview and the Issues and Projects notes in the wiki, so if you want to understand how all these pieces fit together, those are worth a look.

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

Welcome to the NZRT Wiki Podcast. Today we’re looking at 📊 Project Boards.

If you’ve ever wondered how NZRT keeps track of all the moving parts in a software release — from idea through to deployment — this is the episode for you. GitHub Projects are the tool we use, and they let you organise issues and pull requests into a visual workflow that the whole team can see and act on.

Let’s start with the two main ways you can look at a project board. The first is the Table View, which works a lot like a spreadsheet. You can see all your items in rows, with custom columns for things like who it’s assigned to, what the status is, and how high the priority is. The second is the Board View, which is a Kanban-style layout — columns running left to right, with cards you can drag between them. The standard columns you’ll see are Backlog, In Progress, In Review, and Done.

One of the most powerful things about GitHub Projects is automation. You don’t have to manually move things around all the time. The board can be set up so that new issues automatically land in the Backlog the moment they’re created. When a pull request is raised, it jumps straight to the Deploy column. When a PR gets merged, it moves itself to Done — and if there’s a linked issue, that gets automatically closed too. A lot of admin just takes care of itself.

You can also filter the board to show only what’s relevant to you — by status, by assignee, by label, or by priority. And if you need to update a bunch of items at once, bulk actions let you select multiple cards and change priority, add a label, or reassign them all in one go.

Let’s look at a real NZRT example. We have a board called the Dolibarr Custom Release Board, set up for version two point one. It has six columns. Backlog, for things not yet started — like a feature request for product export. Design, for anything in design review — for example, mockups for a comparison widget. Development, for work currently in progress, like actually building that comparison feature. Testing, where items are going through QA validation on staging. Deploy, for things ready to release but waiting on a second approval before merging to main. And finally Done, for everything already shipped — like version two point zero, which is already in production.

The board also uses custom fields to add more detail to each card. There’s a Priority field with High, Medium, or Low options. There’s an Effort field using story points — one, two, three, five, or eight points. There’s a Release field to tag which version something belongs to. And there’s an Owner field to assign work to specific team members.

Now let’s talk about sprint planning. Say you’re planning the sprint for a particular week. You go through your backlog and look at what’s available. You might have four issues to consider: one for advanced filtering at five points and high priority, one for improving mobile responsiveness at three points and medium priority, one for API rate limiting at eight points and high priority, and one for documentation updates at three points and low priority. Your sprint capacity for the week is thirteen points. So you’d pick the filtering issue at five, mobile responsiveness at three, and documentation at three — eleven points total — keeping two points in reserve for bugs or unexpected interruptions.

When you’re working day to day, you can filter the board to show only your assigned items. Instead of seeing everything, you’d see just your slice: maybe one item in Design, two in Development, one in Testing, and a collapsed list of whatever you’ve finished that sprint. It keeps your view clean and focused.

Bulk actions make light work of repetitive updates too. Say you’ve selected two items — a bug fix and a mobile responsiveness task. You can set both to High priority, add an urgent label, and assign them to a team member, all in one step rather than editing each card individually.

So to pull it all together: project boards give you and your team a shared, real-time picture of where work stands. Automation reduces the manual overhead, custom fields add the context you need, and filtering keeps your view focused on what matters to you right now. Whether you’re planning a sprint or tracking a release, this is how NZRT keeps things moving forward.

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