Skip to main content
Use this page as the team-level onboarding index for engineers joining Fleet Manager development and operations. Before anything else, read Ways of Working — it covers the operating context, what’s expected of you on this team, and the four execution mechanisms we use day to day. That’s the bar. Come back to it whenever you’re weighing a tradeoff or unsure how to approach a problem. Then read Operating Rhythm — how that bar shows up in the week: planning, standups, reviews, retros, and the Friday update.

​
Onboarding Checklist

  1. Read Ways of Working — operating context, expectations, and the four execution mechanisms. This is the bar we work to.
  2. Read Operating Rhythm — how that bar shows up in the week: planning, standups, reviews, retros, and the Friday update.
  3. Read Start Here Overview and complete access prerequisites in Getting Access.
  4. Skim the Glossary — it defines the hardware, OpenStack, scheduling, and validation vocabulary the rest of these docs assume.
  5. Complete local setup from Developer Guide Overview and repository-specific setup in docs/development-setup.md.
  6. Read the Architecture doc — it covers the hub/satellite topology, why Temporal is used for workflows, the agent pattern, and the external systems Fleet Manager integrates with. This is the recommended mental model to build before reading code.
  7. Confirm you can run:
    • make dev
    • uv run fleetctl --help
    • make test
  8. Join Fleet Manager communication channels and project tracking tooling (see Communication Channels below).
  9. Optional Use deep-dive skill to understand the codebase quickly.

​
Repository Access

Most Fleet Manager work spans more than just the main repo. Request access to the following GitHub repos as part of onboarding: For access to k8s-cluster-fleet-manager and k8s-deploy-fleet-manager, ask Tom Matthews or Oscar Savolainen.

​
Communication Channels

​
Stakeholders and Points of Contact

Keep this table up to date as ownership changes.

​
Linear: Board, Projects, and Labeling

​
Tickets and Branch Naming

When you create a ticket in Linear, use the Copy git branch name button on the issue (it produces something like oscarsavolainen/fleet-714) and use that as your git branch. Linear will then auto-link the ticket to your branch and move it through the workflow stages based on PR state (open PR moves it to In Review, merged moves it to Done).

​
Issue Labeling

Labels are used for issue type and scope metadata. For the current canonical label list, see Linear team labels: https://linear.app/nscale-workspace/team/FLEET/settings/labels

​
Release and Deploy

For deploying a branch to the shared dev environment, see Testing in Dev. For the full release flow — Release Please PRs, dev rollout, prod rollout, and ArgoCD sync — see Releasing to Production. Branch names must contain the Linear ticket ID somewhere (for example fleet-916); anything before or after is fine.

​
More information

  • #squad-fleet-manager channel has a lot of onboarding information inside bookmarks new-starter-onboarding
  • Technical Team Onboarding For general company-wide technical onboarding doc