Skip to content

Getting started

Your first day

  • Join the organization with your company GitHub account and enable MFA.
  • Add an SSH signing key if your project requires signed commits.
  • Install current LTS Node.js, Python 3.12+, Docker Desktop, Git, and a GDAL build appropriate for your platform.
  • Install the project’s documented runtime and run its test suite before changing code.
  • Read the project README, architecture decision records, and open milestone.
  • Ask for access through the project owner; never share credentials in chat or issues.

Start small

Make a documentation correction or a tightly scoped issue your first pull request. It validates your setup and establishes a review loop quickly.

Onboarding path

flowchart TD
  A[Access + local tooling] --> B[Run application and tests]
  B --> C[Read architecture and active milestone]
  C --> D[Pick a small ready issue]
  D --> E[Open PR and receive review]
  E --> F[Own a production slice]

Standard repository structure

app-or-service/
├── src/                 # Production code, organized by feature or domain
├── tests/               # Unit, integration, and end-to-end tests
├── docs/                # Product-specific decisions and runbooks
├── infra/               # Infrastructure-as-code and deployment config
├── scripts/             # Repeatable developer and CI tasks
├── .github/             # Workflows, templates, ownership
├── Dockerfile
├── README.md
└── .env.example         # Names only; never secrets

For a new repository, copy the maintained repository template.

Before you request review

  • [ ] The branch is current enough to merge cleanly.
  • [ ] Local lint, type checks, and relevant tests pass.
  • [ ] Environment variables are documented in .env.example.
  • [ ] Database or spatial-data migrations have a rollback and backup plan.
  • [ ] The issue, PR description, and user-facing docs reflect the change.

[SCREENSHOT: Developer local environment setup]