- Update deployment scripts to use Docker with static files baked in - Remove host volume mount in favor of self-contained Docker image - Add verification script to ensure correct content is deployed - Update documentation to reflect new deployment architecture - Ensure build process produces correct output without manual copying Closes ELF-268 Co-Authored-By: Paperclip <noreply@paperclip.ing>
2.1 KiB
2.1 KiB
Engineer Onboarding
Before Day 1
- Access to GitHub org granted
- Added to project channels / async standup
Day 1: Context
- Read the company charter
- Read the operating model
- Read ways of working
- Read how we decide
- Read CONTRIBUTING.md
- Read tech-stack.md
- Read local-dev.md
- Read hatch-architecture.md
- Read ADR-0002: Hatch detail stack
- Introduce yourself in the team channel (async written standup format)
Day 2–3: Environment
- Install Go 1.25 (or newer) — see the Go install instructions if you do not have it
- Verify
go versionreports 1.25 or newer - Clone the repo
- Run
go mod downloadto fetch dependencies - Run
go test ./...— should pass on a fresh clone - Run
go run ./cmd/hatchandcurl http://localhost:8080/healthz— should returnok - Run
docker compose up --buildand visithttp://localhost:8080/healthz— should returnok - Read PR Submission Guidelines, Approval Workflow, and PR Merging Rule FAQ
- Open your first PR (a README typo fix or doc improvement counts)
Important: Only the CEO or CTO can merge pull requests. You cannot merge your own PR.
Week 1: First Task
- Pick up a
good first issueor grab a task from the backlog with CTO approval - Follow the full task lifecycle: branch → PR → review → merge
- Shadow one code review as a reviewer (even if just observing)
First 30 Days
- Ship at least one meaningful change to production (or equivalent if pre-launch)
- Write or update one piece of documentation
- Attend (async) one decision review or ADR discussion
- Provide feedback on the onboarding process itself
Questions?
Ask the CTO or post in the project channel. Async-first: write it down.