Core Team
The core team is the small group that stewards the Nano Collective day to day. This section covers what that means in practice and how new members are brought on board.
It is published openly for the same reason the rest of these docs are: anyone investing time in the collective deserves to see how it actually runs. The audience here is narrower than most of the site. It is written for people joining the core team and for the people bringing them on.
What the core team is
Most people who build with the Nano Collective are contributors and maintainers. There is no application process for that, and nothing in this section changes it. See Community for how contribution works and Governance for how maintainership is offered.
The core team is a smaller and more committed circle. Today it is the founding group that holds collective-level direction, makes the calls that span projects, and carries the operational load of running NC: the docs, the brand, the charter, sponsorships, and the health of the community. Joining it means a higher level of trust, broader access, and a standing responsibility for the collective as a whole rather than a single project.
The line between the two is deliberately soft. Sustained contribution that shows real judgement is the usual path onto the core team, and the collective’s whole direction is to widen decision-making outward over time, not to harden a permanent inner ring. The Governance page describes where that is heading.
In this section
- Onboarding. The working playbook for bringing a new core team member on board: what we set up before they start, what their first weeks look like, how we work together, and what each side can expect of the other.
- Onboarding template. A fillable welcome sheet the point of contact completes for each new member and sends privately, alongside the playbook above.
Principles this section follows
- Trust over process. We keep the process light on purpose. The point of writing it down is to make the first weeks legible and welcoming, not to add bureaucracy.
- Write it down so no one is left out. The founding team knows each other in person and talks often. The moment anyone joins remotely, that context has to move into writing. Defaulting to written and async is how a distributed team stays fair.
- Expectations run both ways. A new member owes the collective clarity and follow-through. The collective owes them context, access, and a real point of contact. Both are spelled out.
- It evolves as we grow. This is an early version written for a small team. It will widen and change as the collective does, and the changes happen in the open like everything else here.