Welcome to the NZRT Wiki Podcast. Today we’re looking at GitHub Collaboration Overview.

If you’ve ever wondered how a development team stays coordinated without stepping on each other’s toes, GitHub’s collaboration tools are the answer. Today we’re walking through what those tools are, how NZRT uses them, and what the full workflow looks like from idea to deployment.

Let’s start with the big picture. GitHub gives teams five core collaboration mechanisms. You have pull requests, which are how code gets reviewed before it lands in the main codebase. You have issues, which handle bug tracking and feature planning. You have discussions, which are more open-ended conversations — great for questions, announcements, and ideas that aren’t quite a bug or a feature yet. Then you have project boards, which are essentially a kanban-style way to visualise what work is sitting where. And finally, you have notifications, which keep you informed about mentions, review requests, and assignments. On top of all that, GitHub can sync with tools like Slack, Jira, or Linear, and you can mention teammates directly using the at-sign with their username, or notify an entire team at once using the at-sign with a team name.

Now let’s look at how NZRT actually uses each of these.

Pull requests are where code review happens at NZRT. Before anything gets merged, peers review it. You can leave inline comments on specific lines of code, which makes it easy to point to exactly what you’re discussing. Depending on which branch you’re working with, you’ll need either one or two approvals before a merge can happen. Automated checks also run at this stage — things like linting and tests — so problems get caught before they ever reach the main branch.

Issues are how the team tracks bugs and plans features. When a bug comes in, it gets assigned to a team member and discussed right there in the issue comments. Feature requests get tagged so they can be picked up in future planning cycles. And milestones let you group related issues together — for example, everything targeted for version one-point-one or version two-point-zero lives under its own milestone.

Discussions serve a different purpose. This is where the team announces releases, asks broad questions, shares knowledge, and runs RFCs — which stands for Request for Comments — when an architecture decision needs wider input. It’s also where general troubleshooting conversations happen.

Project boards give you that visual overview of where everything stands. Work items move through four columns: Backlog, In Progress, In Review, and Done. You can drag and drop items as their status changes, and a lot of this can be automated — pull requests can be auto-added to the board when they’re opened, and items can auto-close when a PR gets merged. There are also templates available for issue types that come up repeatedly.

Now let’s talk through the full NZRT collaboration workflow, which runs in five stages.

It starts with planning. A team member creates an issue to describe a feature or bug, adds it to the project board in the Backlog column, assigns it to a developer, and ties it to the relevant milestone.

Stage two is development. The developer creates a feature branch, works locally — in NZRT’s case that means using the Laragon environment — writes commits with descriptive messages, and pushes the branch up to GitHub when ready.

Stage three is code review. The developer opens a pull request from their feature branch and requests between one and two reviewers. Reviewers leave comments, the developer responds and makes any needed changes, pushes those updates, and then waits for approval.

Stage four is merge and deploy. Once the pull request is approved, the maintainer clicks merge. From there, GitHub Actions takes over and automatically deploys to staging. Tests run, and the team gets notified in Slack.

Stage five is the wrap-up. The pull request closes automatically. The feature branch gets deleted automatically. If the pull request was linked to an issue, that issue closes automatically too. And the project board gets updated to reflect that the work is done.

What’s worth noting about this workflow is how much of it is automated. Once the merge happens, you’re not manually chasing down steps — GitHub and the Actions pipeline handle the heavy lifting. That’s what keeps the team moving without communication gaps.

The main takeaway here is that GitHub’s collaboration tools aren’t just about storing code. They’re a full coordination layer for your team — from the moment an idea is captured as an issue, all the way through to it being deployed and confirmed done on the project board.

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