Blog: PipeCD's Newcomers Meetings: July 16 & August 6, 2026

Sun, 16 Aug 2026 00:00:00 +0000

Twice this summer, the PipeCD community sat down with a group of people who had never touched PipeCD before, some of them new to CNCF projects altogether, and walked them through the project from scratch. That’s what the Newcomers meeting is for: no assumption that you’ve read the docs, no assumption you know what GitOps even means yet. Just an open call, a screen share, and an hour to answer whatever’s on your mind.

We ran two of these sessions this year, on July 16 and August 6, 2026:

If you were there, this is a recap. If you weren’t, consider this the next best thing, and an open invitation to the next one.

Why the project looks different than it did a year ago

The first thing we try to get out of the way early is the v0-to-v1 question, because it trips up almost everyone who opens the repo cold. If you clone PipeCD today, you’ll find two versions of the piped agent living side by side, and that’s confusing until you know why.

The original piped, what we now call v0, has every deployment stage built directly into the agent. Kubernetes sync, Terraform plan and apply, canary analysis, all of it compiled in. That was simple in the beginning, but it meant that adding support for a new platform meant changing piped itself, and that doesn’t scale to a community project with contributors who each care about a different corner of the deployment world.

pipedv1 is the answer to that. Stage executors became plugins: separate binaries that piped loads and talks to over gRPC. Kubernetes, ECS, Cloud Run, Terraform, wait, waitapproval, analysis, each one its own module now, each one able to move independently. We usually point newcomers to three things to read after the meeting if they want the full picture: the original design post, what actually changed in practice, and the migration guide if you’re moving a real installation over.

What matters most if you’re about to open a pull request:

platformProviders and cloudProviders in piped config don’t exist in v1. Plugins define deployTargets instead.
Every application config uses kind: Application now, not the old per-platform kinds.
Each plugin is a separate module built against the piped-plugin-sdk-go SDK.
Legacy piped (pkg/app/piped/) and pipedv1 (pkg/app/pipedv1/) both live in the repo right now, because the migration is gradual. Before you start on a good first issue, check which side it’s on. If it’s not obvious, ask in the issue, that’s a completely normal question to ask.

What actually happens when you send a pull request

The second half of both meetings is usually spent on the part people are most nervous about: what happens after they write code. Open source can feel like a black box from the outside even when the process behind it is ordinary, so we walk through it step by step.

It starts with an issue. good first issue is the label to search for, and a comment saying you’d like to take it is enough to get assigned, though the expectation is a PR within about a week, so it’s worth claiming something you can actually start on soon. For anything that isn’t a one-line fix, we encourage people to describe their planned approach in the issue before writing code. It’s a five-minute step that saves a lot of rework later.

From there, the mechanics: keep the diff small, somewhere around 300 lines is the rule of thumb, and split anything bigger. Sign off every commit with git commit -s for DCO. Write commit messages in the present tense with a capital first letter, the way Add imports to Terraform plan result reads. Target master. And before opening the PR, run make check locally, it’s the same build, lint, and test steps CI will run anyway, so you find out about failures on your own machine first.

The full contributor guide covers the rest, the license header, the PR template for user-facing changes, how the bug and feature templates work. And code isn’t the only door in: documentation and blog posts (this one included) need contributors too, and so does issue triage and conversation in GitHub Discussions.

Where the conversation continues after the meeting ends

Every Newcomers meeting ends the same way: with people asking where to go next. Here’s what we tell them.

#pipecd on CNCF Slack is where most of the day-to-day questions get answered.
The broader PipeCD Development and Community Meeting runs every two weeks with project news and issue triage. Notes are at bit.ly/pipecd-mtg-notes.
Newcomers meetings themselves happen periodically, not on a fixed schedule, so Slack and the meeting notes are the place to watch for the next date.
If you want something more structured, LFX Mentorship is worth a look, and one mentee wrote honestly about her first month if you want to know what that actually feels like.
Once you’ve merged 5 PRs across the pipe-cd organization and attended a public community meeting, you’re eligible for membership in the GitHub org, though plenty of people contribute happily without ever going that route.

See you at the next one

Both sessions, in the end, come down to the same thing: showing people that the project is smaller and friendlier up close than it looks from the outside. If you missed these two, the recordings are linked above. And if you’re reading this because you’re weighing your first contribution, the door’s open, come find us in #pipecd on Slack and we’ll figure out where to start.

PipeCD – Onboarding

Blog: PipeCD's Newcomers Meetings: July 16 & August 6, 2026

Why the project looks different than it did a year ago

What actually happens when you send a pull request

Where the conversation continues after the meeting ends

See you at the next one