How we work together

How the CKI team communicates, takes ownership, and delivers work

This page describes how we work as a team. It is not a technical guide or a strict rulebook. It is a practical guide for communication, ownership, and delivery.

TL;DR

Understand first. Think about users. Communicate early. Make your work visible. Own the result.

Before you start:

Understand the current behavior.
Create a [Jira][jira-board] ticket and confirm priority with the team.

Before you open an MR:

Explain what changed, why, and how you tested it (see [development guidelines]).

Before you close a ticket:

The change works as agreed, links are in Jira, and the team knows what changed.

Nobody is expected to know everything. We do expect you to ask questions, stay engaged, and not go quiet when work gets hard.

Understand the system

Before changing something, understand how it works today.

Many parts of the system have history. Something that looks odd may exist for a good reason: an old bug fix, a dependency from another team, or protection against a non-obvious failure mode.

Before you rewrite, remove, or “simplify” something:

Ask teammates who know the area.
Search the documentation.
Read the code.
Check existing Jira tickets and useful old merge requests.

Useful questions:

Why was this built this way? What could break if I change this?

You do not need full context before you start, but you need enough to make a safe proposal. When you suggest a change, explain what exists today, what problem you see, and why your change helps.

Think about users first

Do not think only about our repositories and tools. Think about people who use the system: kernel developers, QE engineers, other teams, and future maintainers. They may not know our internals. They want the system to be faster, clearer, and easier to debug.

Before proposing a change, ask:

What user problem does this solve?
Does it make work easier, or only our implementation nicer?
Could it make someone’s workflow harder?

When you propose a change, explain how it helps users, not only what changes in the code.

Communicate early

Do not work in silence for too long.

If you notice a problem or have an idea, share it early. You do not need a perfect solution first. A short Slack message is often enough:

I noticed this behavior in the pipeline. I think we may be able to simplify it. I will check the current flow and create a Jira ticket if it looks useful.

For bigger topics, use standup, refinement, or a short meeting. If you need a decision in a meeting, send a short note beforehand: what you want to discuss, why it matters, and what help you need. Do not surprise people with a large topic they had no time to prepare for.

Use Jira before you build

Before implementation, create a ticket in the CKI project.

The ticket does not need to be perfect, but it should explain what you want to do and why. Slack is fine for quick discussion, but important information should not live only in Slack. Jira is where we track work, link merge requests, capture decisions, and show blockers.

A good ticket answers:

What problem are we solving?
Why does it matter?
What result do we expect?
What is in scope, and what is clearly out of scope?

To create issues, use + Create in Jira and select the CKI Project (CKI) space, or use:

Check priority before going deep

A good idea is not always the highest priority right now.

Before a large implementation, check with the team and Product Owner. Sometimes the problem is agreed, but a smaller first step is preferred.

Should I work on this now, or is something else more important?

Asking early avoids spending days on work that is not needed yet.

Make work easy to follow

Others should understand your work without private messages every time.

Keep the Jira ticket updated.
Link merge requests.
Summarize decisions from Slack or meetings in Jira or the MR.

That is enough context for the team later—including future you.

What “done” means

Done means more than “the code was merged.”

Work is done when it works as agreed, the team understands what changed, and important information is captured in the right place.

It is probably not done if:

The code is merged but nobody knows how to use the change.
The Jira ticket is closed but basic questions keep appearing in Slack.
Documentation is deferred with no ticket or follow-up.

Before closing a task:

Can someone else understand what changed and what to do next?

If you are unsure, ask in review, standup, or the Jira ticket.

Ask for help when blocked

Being blocked is normal. Staying silent while blocked is not.

If you are stuck without progress, say so within a day or two (standup, Slack, Jira, or 1:1). Be specific: what you tried, what happened, and what help you need.

I am blocked on this ticket. I checked the logs and the deployment config, but I still do not understand why the job fails. I need help from someone familiar with this pipeline.

If another team blocks you, record that in Jira: link, team, and what you are waiting for. Do not keep blockers only in private chat.

Take ownership

When you take a task, you own the result. That does not mean doing everything alone; it means the work does not get lost.

Ownership includes:

Following the task through to a clear end.
Keeping the ticket updated and responding to review comments.
Following up on blockers and asking for help when needed.
Communication, coordination, reviews, documentation.

If you agree to sync with another team, follow through. If you make a decision, explain it. If you were wrong, help fix the outcome.

Ownership is not hero mode or hiding problems. When someone asks for help with production and you know the area—or shipped the change—respond first. A quick triage or “I’m looking” is enough to start; you do not have to solve it alone. Delegate or bring in others when they can fix it faster. If you cannot finish something, say so and help transfer it instead of letting it stall.

Own what you ship

When your change is merged, stay involved if it causes problems, confuses users, or breaks a workflow. You know the change best. You are expected to help the team understand and fix issues.

After a risky or important change, watch CI, logs, dashboards, Slack, or user reports as appropriate. Shipping means the change works in production and is supported, not only that the MR merged.

Share context in the MR, Jira ticket, and docs so you are not the only person who understands the feature. Good ownership creates shared knowledge.

Work with other teams carefully

CKI touches many teams. Small changes can have large effects.

If your work may impact another team, tell them early, not after merge or after something breaks on their side. Give them time to ask questions, test, or plan.

One Slack message may not be enough; follow up in Slack or email if needed.

Cross-team work should be visible in Jira. Link related tickets and record decisions there instead of only in Slack threads.