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.