Tag Archives: collaboration

000DOL, 05 - Collaboration

Collaboration

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

So, what do we mean by Collaboration at NZRT? At its core, the Collaboration section of our internal systems covers the cross-functional tools that help you and your team work together day to day. Think of it as the connective tissue between people, projects, and time. It brings together four distinct areas: shared calendars and agendas, project and task management, event organisation, and surveys. Each one plays a role in keeping the team aligned and moving in the same direction.

Let’s start with Shared Calendar and Agenda. If you’ve ever found yourself wondering when a meeting is happening, or whether a colleague is available for a quick catch-up, this is where you go. The shared calendar gives everyone visibility into what’s happening across the team. You can see scheduled events, block out time, and plan around other people’s commitments without having to send a chain of emails back and forth. The agenda side of things helps you structure what’s actually going to be covered in those meetings, so time is used well and nothing important gets missed. Whether you’re coordinating across departments or just trying to find a slot that works for three people, the shared calendar is your starting point.

Next up is Projects and Tasks. This is probably the sub-module you’ll spend the most time in. It gives you a structured way to plan and track work from start to finish. At the project level, you’re looking at the big picture — what’s the goal, who’s involved, what’s the timeline. Drill down into tasks and you get the day-to-day detail — individual actions assigned to specific people, with due dates and progress tracking. This means that at any given moment, you can see exactly where a piece of work sits, who’s responsible for it, and whether it’s on track. It removes a lot of the guesswork that comes with collaborative work and keeps everyone accountable without needing constant check-ins. If you’re managing a client engagement, an internal initiative, or anything with multiple moving parts, Projects and Tasks is how you keep it all under control.

The third sub-module is Event Organisation. This one is specifically designed to help you plan and coordinate events — whether that’s an internal workshop, a team offsite, a client presentation, or a training session. Event Organisation gives you a dedicated space to manage the logistics: who’s attending, what needs to be prepared, what the agenda looks like, and how invitations go out. Rather than juggling spreadsheets and email threads, everything related to an event lives in one place. It also connects naturally with the shared calendar, so once an event is confirmed, it shows up where people are already looking at their schedule.

The fourth sub-module is Surveys. Surveys might sound simple, but they’re a powerful way to collect structured feedback and input from your team or from stakeholders. Whether you want to check in on how a project went, gather opinions before making a decision, or run a quick pulse check on team morale, surveys give you a way to do that systematically. You build the survey, send it out, and the responses come back in a format you can actually analyse. It’s much more useful than asking people informally and trying to piece together a picture from casual comments. Surveys close the loop on initiatives and make sure decision-making is grounded in real input rather than assumptions.

Now, the Collaboration module doesn’t sit in isolation — it connects to two other areas of the system that are worth knowing about. The first is Timesheets. Time tracked through Timesheets can be linked directly to projects, which means you get a clear picture of how much effort is actually going into any given piece of work. That’s valuable both for internal planning and for client billing, if that’s relevant to your engagement. The second related area is Interventions, which covers field work. Interventions can also be linked back to projects, so if someone’s out on site doing hands-on work, that activity gets recorded against the right project context. Both of these connections mean that Collaboration isn’t just about coordination — it feeds into a fuller operational picture that spans time, effort, and delivery.

So to bring it all together: the Collaboration module is your hub for keeping work organised and teams connected. You’ve got the shared calendar for scheduling and visibility, projects and tasks for managing work end to end, event organisation for planning structured gatherings, and surveys for collecting feedback and input. Layer in the links to timesheets and field interventions, and you have a system that ties coordination to execution in a meaningful way.

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

000DOL, 05 - Collaboration

Projects Tasks

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

Projects and Tasks is the part of the NZRT system where you plan, organise, and track your work from start to finish. Whether you’re managing a client engagement, an internal initiative, or a smaller piece of consulting work, this is where you bring it all together — from the initial plan right through to completion.

Let’s start with how a project is structured. Think of it as a tree. At the top you have the project itself — that’s your overarching container for all the work. Underneath that, you break things down into tasks. Each task can be assigned to a specific person, and you can set an estimated number of hours for how long it should take. Then, if a task is complex enough, you can go one level deeper and create sub-tasks underneath it. So for example, you might have a project at the top, then Task One assigned to a team member with ten hours estimated, and underneath that, Task One might have its own sub-tasks — say, research, drafting, and review. Task Two sits alongside it at the same level. This hierarchy lets you get as granular as you need without losing sight of the big picture.

Now let’s talk about what you can actually do with that structure. There are five main feature areas worth knowing about.

First, there’s the Gantt-style timeline view. This gives you a visual representation of your project schedule — you can see which tasks are running in parallel, which ones depend on others finishing first, and how the overall timeline is shaping up. It’s a great way to spot scheduling conflicts or gaps before they become a problem.

Second is time logging and timesheets. As you and your team work through tasks, you log the actual time spent against each one. This feeds directly into the timesheets module, keeping everything connected. You’re not re-entering data in two places — it flows through automatically.

Third, you get budget versus actual tracking for both hours and cost. This is really valuable because it means you can compare what you planned at the start of the project against what’s actually happening. If a task is running over hours, or a project is burning through budget faster than expected, you’ll see that clearly rather than finding out at the very end.

Fourth is billable project invoicing. If you’re working on a client project, you can mark tasks as billable and generate invoices directly from the project. This connects your project management and your finance side, so you’re not copying data across systems or reconciling things manually at month end.

And fifth, you can attach documents to a project. Supporting files, briefs, contracts, reference material — whatever you need to keep close to the work — can live right there alongside the tasks themselves.

Now, Projects and Tasks doesn’t work in isolation. It connects to a few other areas of the system that are worth being aware of.

The Shared Calendar and Agenda ties in with your project timeline, so deadlines and milestones can show up alongside other scheduled events. That helps with visibility across the whole team.

Timesheets, as mentioned, receives the time entries you log against tasks. But the timesheets module also has its own views and reporting, so if you need to look at how time is being spent across multiple projects or across the team as a whole, that’s where you’d go.

And finally, there’s reporting — specifically project profitability reporting. Once your actual hours and costs are tracked against your budget, the reports module can show you whether a project is running at a profit or a loss. For a consultancy like NZRT, this is essential. It tells you whether the work you’re delivering is being captured and billed correctly, and whether your estimates are landing where they should.

So to bring it all together — Projects and Tasks gives you a structured way to break work down into manageable pieces, assign it to the right people, track time and costs as you go, and connect that information through to invoicing and reporting. It’s the central hub for managing delivery, and when used consistently, it gives you a clear picture of where every project stands at any given moment.

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

000GIT, 07 - Collaboration

Code Review Process

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.

000GIT, 07 - Collaboration

Github Discussions

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.

000GIT, 07 - Collaboration

Project Boards

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.

000NCL, 02 - Collaboration Apps

Calendar

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

If you’ve ever missed a deadline because someone forgot to tell you about a meeting, or you’ve had to chase a teammate just to find out when a client call is happening, then shared calendaring is exactly what this episode is about. Nextcloud Calendar is the solution NZRT uses to keep the whole team on the same page when it comes to scheduling, events, and time.

So what can Nextcloud Calendar actually do? Let’s walk through the core features. First up, you get shared calendars, which means you can have team-wide, project-specific, or role-based calendars that multiple people can view and contribute to. Next, there are event invitations with RSVP and attendance tracking, so when you send someone a calendar invite, you can actually see whether they’ve accepted, declined, or are still sitting on the fence. You also get recurring events, which are great for things like daily standups, weekly team meetings, or monthly finance reviews where you just set it once and it keeps showing up. Then there’s CalDAV sync, which we’ll talk more about in a moment, colour coding so you can visually tell your calendars apart at a glance, and full time zone support for when you’re working across different regions.

Now let’s look at how NZRT has structured its calendars. There are four main calendars set up. The first is the Team Calendar, owned by xc, with all team members having access. That one is used for company-wide events like public holidays and company announcements. The second is the Sales Calendar, owned by cas, used by the sales team to track client calls and demos. The third is the Finance Calendar, owned by fin, shared with fin and sun, and used for things like payment deadlines and month-end close activities. And the fourth is the HR Calendar, owned by han, shared with han and xc, covering onboarding schedules, performance reviews, and time-off requests. So depending on your role, you’ll likely be a member of one or more of these calendars, each colour coded and kept separate so the right information reaches the right people.

Now, one of the really useful things about Nextcloud Calendar is that it doesn’t just live inside the Nextcloud web interface. You can sync it directly to your phone or your desktop calendar app. There’s a section in the wiki that shows you how to do this, so let me walk you through what it describes. You start by opening your calendar app on iOS or Android, then you add a new account and choose CalDAV or CardDAV as the account type. From there, you enter the server address, which for NZRT is the internal Nextcloud address, then you put in your username and password using your LDAP credentials, the same ones you use to log in to Nextcloud. Once that’s done, your calendar app will automatically sync your events down to your device. So any event added to Nextcloud Calendar by a teammate will show up on your phone, and anything you create on your phone will push back up to Nextcloud. It keeps everything in one place without you having to manually check the web app every morning.

If you’re an Outlook user or you use Apple Calendar on a Mac, the same CalDAV protocol works there too. The process is similar, you point the app at the Nextcloud server using your credentials, and you get two-way sync from that point on.

From a broader NZRT perspective, the calendar isn’t just a standalone scheduling tool. It connects to how the whole organisation operates day to day. If you’re working on a Dolibarr project, you can align your calendar events with project milestones and deadlines. If you’re involved in the WordPress editorial side of things, calendar visibility helps coordinate content publishing schedules. And for the team doing Nextcloud maintenance, having a shared calendar means maintenance windows are visible to everyone before they happen, not after.

For fin and sun in particular, who manage payment schedules and vendor deadlines, the Finance Calendar is a practical tool for making sure nothing slips through the cracks at end of month when things tend to get hectic.

So whether you’re in sales tracking your client calls, in HR managing onboarding timelines, or in finance keeping an eye on payment due dates, Nextcloud Calendar gives your team a single, shared view of what’s happening and when. And with CalDAV sync, that view travels with you on whatever device you prefer to work on.

If you want to dig deeper, the wiki also links out to related notes covering the broader Nextcloud collaboration overview, Contacts, and the combined Email and CalDAV CardDAV integration guide, which is worth a read if you want to get everything connected at once.

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

000NCL, 02 - Collaboration Apps

Collaboration Overview

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

If you’ve ever juggled Slack for chat, Zoom for video calls, Google Calendar for scheduling, Asana for task tracking, and a separate wiki for documentation — all while wondering why your team’s data is scattered across half a dozen external platforms — this episode is for you. At NZRT, the answer to that problem is Nextcloud’s built-in collaboration suite, and today we’re going to walk through what it includes, who uses it, and why it matters.

So let’s start with what the collaboration suite actually is. Nextcloud isn’t just a file storage platform. It ships with a set of apps — Talk, Calendar, Contacts, Deck, and Collectives — that together cover almost everything a team needs to communicate and coordinate. And because it’s all self-hosted within NZRT’s own infrastructure, your data stays inside the organisation. No third-party SaaS subscriptions, no data leaving the building, so to speak.

Let’s go through each of those apps one by one.

First up is Talk. This is your chat and video calling tool — and if you’re familiar with Slack or Zoom, Talk covers that same ground. You can send messages, hop on video calls, and share your screen, all from within Nextcloud. At NZRT, Talk is available to everyone across all roles, so it’s the go-to channel for real-time team communication.

Next is Calendar. This is a shared calendar and scheduling tool, similar to Google Calendar. At NZRT, it’s used primarily by xc, sun, and fin — so that covers the executive, the operations side, and the finance function. It keeps scheduling in one place without needing to hand your calendar data over to an external provider.

Third is Contacts. This is the team’s shared address book, and it also connects to CRM-style data. At NZRT, it’s used by xc, pam, and cas — the executive, the project and marketing agent, and the customer and sales agent. If you need to look up a contact or manage relationship data, Contacts is where you go.

Fourth is Deck. Think of this as NZRT’s Kanban board and task management tool — essentially the replacement for Asana. You can create boards, move tasks through stages, and keep project work organised visually. At NZRT, Deck is used mainly by pam and dan — the project agent and the data and analytics agent.

And fifth is Collectives. This is the team wiki and documentation tool. If you need to write up processes, maintain internal docs, or collaborate on written content, Collectives is the place for that. At NZRT, that’s xc, ema, and dai — the executive, the email and comms agent, and the data insights agent.

Now, beyond the individual apps, there are some integration benefits worth understanding, because this is where the suite really earns its place.

The first is single sign-on. Your directory credentials work across all of these apps, so you’re not managing separate logins for each tool. One set of credentials, everything connected.

The second benefit is file integration. Because these collaboration apps live inside Nextcloud, you can share files directly from a chat conversation or attach them to a task on your Deck board. There’s no copy-paste shuffle between a file storage app and your communication tool — it’s all in the same place.

Third is a unified notification hub. Rather than checking five different apps for alerts, Nextcloud consolidates notifications across Talk, Calendar, Deck, and the rest. You get a single stream of what needs your attention.

And fourth is API access. The Nextcloud collaboration apps support automation and third-party integrations, which means agents and scripts can interact with these tools programmatically. That’s important for NZRT’s agent-driven workflow, where automated processes need to read and write data across systems.

Stepping back, the bigger picture here is that all of this — chat, video, calendar, contacts, task boards, and documentation — stays within NZRT’s secure, self-hosted infrastructure. You’re not depending on Slack staying affordable, Zoom’s terms of service, or Google’s data practices. The organisation controls the environment, the data, and the access.

So whether you’re coordinating a project on Deck, catching up on messages in Talk, or pulling up a shared process document in Collectives, it’s all running on the same platform, under the same credentials, with the same security boundary.

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

000NCL, 02 - Collaboration Apps

Collectives Wiki

Welcome to the NZRT Wiki Podcast. Today we’re looking at 📖 Collectives (Wiki).

If you’ve ever needed a central place where your team can write, edit, and find documentation together, Nextcloud Collectives is exactly that. It’s a wiki platform built into Nextcloud, designed for collaborative team documentation. Think onboarding guides, standard operating procedures, runbooks — anything your team needs to know, all in one searchable, version-controlled place.

So what can you actually do with it? Let’s walk through the key features.

First, you get wiki pages. You can write using either a Markdown editor if you’re comfortable with plain text formatting, or a more visual WYSIWYG editor if you prefer something closer to a word processor. Your choice, depending on how you like to work.

Second, pages can be nested. That means you can organise your documentation into hierarchies — a parent page with child pages underneath it, and so on. If you’re familiar with how this Obsidian vault is structured, it works in a very similar way.

Third, Collectives supports real-time collaboration. Multiple people can co-edit a page at the same time, and there’s also a comments system so you can leave feedback or questions right on the document itself.

Fourth, every time someone edits a page, Collectives automatically saves a snapshot. That version history means you can always look back at what changed, when it changed, and roll things back if something goes wrong.

Fifth, you have flexible permission control. You can make a collective public, restrict it to a specific team, or keep it private. That gives you good control over who sees what, which matters when you’re mixing internal-only processes with content you might want to share more broadly.

And sixth, there’s full-text search across all your wiki content. So instead of hunting through folders, you can just search for a keyword and find the relevant page quickly.

Now, to give you a practical sense of what a page might look like, imagine a simple onboarding checklist. The page would have a main heading like Onboarding Checklist, then two sections underneath it. The first section covers IT Setup, and it lists three tasks — creating an LDAP account, which is handled by xc, adding the new person to Nextcloud groups, and issuing a laptop with VPN access. The second section covers Access, and it lists three more tasks — setting up a Dolibarr login handled by fin, granting access to the relevant Nextcloud shared folders, and sending Talk channel invitations. That kind of structured, actionable checklist is exactly the type of content Collectives is built for.

If you want to explore related areas, you might also look at the Collaboration Overview, the Document Management Overview, and the NZRT Folder Structure notes, which all connect to how Collectives fits into the broader way NZRT organises its information.

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

000NCL, 02 - Collaboration Apps

Contacts

Welcome to the NZRT Wiki Podcast. Today we’re looking at 📇 Contacts.

Nextcloud Contacts is our shared address book, and it’s the single source of truth for client and vendor data across the team. It supports CardDAV, which means your contacts can sync automatically to your phone, tablet, or Outlook — wherever you manage your address book day to day.

Let’s talk about what the Contacts app actually does for you. First, you get shared address books, so the whole team is working from the same up-to-date records rather than scattered personal lists. You can store custom fields too — things like deal stage, company name, and phone numbers that make it useful as a lightweight CRM. Contacts can be organised into groups, which makes it easy to filter and find who you need. And when it comes to getting data in or out, you can import and export using VCF or CSV formats.

Now, NZRT has four main contact groups set up. The first is Clients, which is maintained by the pam and cas agents and holds the customer database. The second is Vendors, looked after by sun and fin, covering all supplier contacts. Third is Employees — that’s the internal directory, maintained by han and xc. And fourth is Partners, which xc manages, covering integrations and external service providers.

One of the most important things to understand about Contacts is how it connects to Dolibarr, our ERP system. There are two ways this works. The first is an automated sync — Nextcloud Contacts and Dolibarr customers and suppliers are linked through the REST API, and a nightly task keeps them in step. So changes made in one place flow through to the other overnight. The second method is manual — you can download a CSV from Contacts and import it directly into the Dolibarr CRM. That’s useful for one-off bulk updates or when you need more control over what gets synced and when.

If you want to set up CardDAV on your mobile device, here’s how that works on iOS. You go into Settings, then Accounts, and add a new CardDAV account. The server address is your Nextcloud instance, and you log in with your LDAP username. Once that’s connected, your Nextcloud contacts will appear right alongside your regular phone contacts and stay in sync automatically.

Finally, a quick note on who owns what. The pam agent handles products, cas handles sales, and sun handles procurement. All three of them maintain contact records in Nextcloud, and those records sync through to Dolibarr where they’re used for invoicing and order management. So if you’re ever wondering where the authoritative version of a client or vendor record lives, it starts here in Contacts.

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

000NCL, 02 - Collaboration Apps

Deck Kanban

Welcome to the NZRT Wiki Podcast. Today we’re looking at ?? Deck (Kanban).

If you’ve ever used a physical sticky-note board to track work — with columns for To Do, In Progress, and Done — you already understand the concept behind Nextcloud Deck. Deck is NZRT’s built-in Kanban tool, living right inside Nextcloud, and it’s how our teams organise and track tasks and projects without needing any external software.

Let’s start with how Deck is structured. At the top level, you have boards. A board is your project workspace — think of it as the whole whiteboard. Inside each board, you have columns, which represent the stages of your workflow. Out of the box you might have To Do, In Progress, and Done, but you can customise these to match however your team actually works.

Inside those columns, you have cards. A card represents a single task or work item, and each card can hold quite a bit of information. You can write a description, set a due date, assign it to a specific person, attach labels for easy filtering, and link files directly to the card. So if a task needs a document or spreadsheet, it travels with the card. Cards also have a comments section, which means your whole team can collaborate and leave notes directly on the task — keeping everything in one place rather than scattered across emails.

Beyond the cards themselves, Deck also tracks activity. You can see a history of who moved a card, when they moved it, and what changed. That audit trail is really useful when you need to understand the progress of a project or figure out where something got held up. Boards can also be shared with individual team members, with groups, or made publicly accessible — so you have real flexibility in how you open your workflow up to the people who need it.

Now let’s talk about how NZRT specifically uses Deck. There are five active boards across the team. First, the Marketing Pipeline — owned by pam and used by the Products team for campaign planning. Second, Sales Deals — owned by cas, used by the Sales team to track deal progression. Third, Procurement — owned by sun, where the Procurement team tracks purchase orders. Fourth, Tech Projects — owned by dan on the DBA team, covering system upgrades and Nextcloud maintenance. And fifth, the Editorial Calendar — owned by ema on the EDM team, used to plan and schedule WordPress and blog publishing.

To give you a concrete sense of what a card actually looks like, imagine one titled “Prepare Q2 Sales Report”. It has a description explaining the work — aggregating CRM data and creating visualisations. It is assigned to cas in the Sales role. It has a due date set, labels applied for sales, reporting, and urgency, and a file attached — a sales report template pulled from the Finance folder in Nextcloud. Then there is a comments area where team members can check in and collaborate as the task moves forward.

One of the biggest wins for NZRT with Deck is that it removes the need for external project management platforms. Tools like Asana or Monday dot com are no longer needed, because Deck provides the same core functionality right inside Nextcloud, where your files already live. For the Products team, the Sales team, and the DBA team in particular, Deck has become the go-to for daily task tracking — and it has replaced a lot of the email-based back-and-forth that used to slow things down.

If you want to dig deeper, check out the related wiki pages on the Collaboration Overview, the Files App, and NZRT User Roles and Agents. Those will give you more context on how Deck fits into the broader Nextcloud environment and how the different team members interact with it day to day.

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

000NCL, 02 - Collaboration Apps

Talk Chat Video

Welcome to the NZRT Wiki Podcast. Today we’re looking at 💬 Talk (Chat & Video).

So let’s set the scene. If you’ve ever wondered why NZRT isn’t using Slack for team chat or Zoom for video calls, this episode answers that question. The answer is Nextcloud Talk — a secure, self-hosted communication platform that lives entirely on NZRT’s own infrastructure. No third-party servers, no external subscriptions, and no data leaving the building, so to speak.

Nextcloud Talk covers the full range of communication you’d expect from any modern team tool. You’ve got direct messages for one-on-one encrypted conversations, group chats for teams, projects, or topics, and video and audio calls that can handle up to one hundred participants at a time. Those video calls run on WebRTC, which is an open, encrypted standard, so your calls are protected end to end. Beyond that, you can share your screen during calls — either your whole desktop or just a specific window — and you can record calls for later review. Notifications are covered too, whether that’s desktop alerts, email, or mobile push notifications.

Now let’s talk about how NZRT actually organises its channels in Talk. There are a few different types you’ll encounter. First, you have persistent channels — these are the always-on rooms that the whole team uses day to day. Think of channels for general conversation, team-wide announcements, and a dedicated tech channel. Then you have project-specific channels, which are spun up for focused work — things like a channel for a Dolibarr deployment, another for a WordPress redesign project, or one specifically for Nextcloud administration tasks. Third, you have direct messages, which are just your standard private one-on-one conversations. And finally, there are read-only channels, which are used for announcements — only the admin account, xc, can post in those, so they stay clean and authoritative.

Now, let’s look at how Talk is configured for NZRT’s specific needs. The settings used here cover a few important areas. The maximum number of participants in a call is set to fifty. Public calls are required to have a password before anyone can join. Call recording is switched on automatically — this is tied to NZRT’s Electronic Document Management requirements, meaning recordings are kept as part of the organisation’s compliance record. And speaking of compliance, recordings aren’t kept forever — they’re set to automatically delete after ninety days, keeping the archive manageable without losing anything that’s needed for audit purposes.

That combination of auto-record and timed expiry is worth understanding because it’s not just a housekeeping measure. The EDM function at NZRT — handled by the ema role — is responsible for records retention, and Talk feeds directly into that workflow. When a call finishes, the recording doesn’t just sit in someone’s downloads folder. It integrates with Nextcloud’s archival system, so it’s stored, managed, and eventually disposed of according to the retention policy. That’s a level of record-keeping that most external video platforms can’t give you without paying for enterprise add-ons.

And that brings us to the bigger picture of why Talk exists in the NZRT stack at all. Every Slack message on an external platform and every Zoom call lives on someone else’s server. For a consultancy that takes data sovereignty seriously, that’s a problem. By running Talk on NZRT’s own data centre infrastructure, all communications stay internal. There are no licensing fees for Slack seats or Zoom licences, and there’s no dependency on a third-party service going down or changing its pricing model. It’s a deliberate choice to own the stack.

If you want to explore related areas, the wiki connects Talk to a few other topics worth knowing about. The Collaboration Overview gives you the broader picture of how NZRT’s tools fit together. The Users and Groups page explains how access is managed across Nextcloud, which naturally affects who can join which Talk channels. And the Email and CalDAV CardDAV note covers the other communication channels that sit alongside Talk in the stack.

So to summarise what you’ve learned today: Nextcloud Talk is NZRT’s all-in-one, self-hosted replacement for Slack and Zoom. It supports direct messages, group channels, encrypted video calls for up to one hundred people, screen sharing, and call recording. NZRT’s channels are organised into persistent team rooms, project-specific rooms, direct messages, and read-only announcement channels. Calls are configured to require passwords, auto-record for compliance, and delete recordings after ninety days. And the whole system feeds into the ema role’s records retention workflow, keeping NZRT audit-ready without relying on any external platform.

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