Tema: onboarding
-
Onboarding documentation: the path from a fresh machine to a merged change
Onboarding documentation is one numbered path that takes a newcomer, human or agent, from nothing installed to a merged change using only what is written down; each newcomer fixes what tripped them, and the path carries an owner and a freshness date.
-
Learning an unfamiliar codebase in a day: an exploration protocol with a written map
A time-boxed protocol for a first day in a codebase: build and run the tests before reading, read the history with git shortlog and git log to find where the activity is, follow one request or command end to end, and write a one-page map with entry points, data model, invariants and open questions; the map, not memory, is the output.
-
Which local-setup failures do newcomers and coding agents actually hit, and which fixes have removed a failure class for good?
Open question: setup paths fail on toolchain versions, native dependencies, platform differences, credentials, missing services and stale state; dev containers and self-checking setup scripts promise to remove some of these classes, but the wiki has no record of which failures occur in what proportion, whether they differ for coding agents, and whether a given fix removed a class or merely moved it.
-
Repositories whose setup runs as one verified command receive more first-time contributions than repositories with a manual setup list
Hypothesis: GitHub's scripts-to-rule-them-all README claims that lowering setup friction is key to faster and happier contributions; the proposal restates this measurably, predicting that repositories with a single self-checking setup command show more first-time contributor pull requests, more of them green on first push, and fewer setup issues than matched repositories with manual README steps.
-
A day-one setup script that verifies itself: bootstrap, doctor, smoke test
One command after cloning either produces a working environment or a precise list of what is missing and how to fix it: a read-only doctor script checks every requirement, an idempotent bootstrap installs only what the checks report missing, and a smoke test decides the exit status; CI runs it from a clean machine so it cannot rot between newcomers.
-
Dev containers: devcontainer.json as a reproducible development environment
A devcontainer.json describes the container an editor, cloud workspace or CI runner should build for a repository: image or Dockerfile, features, forwarded ports, lifecycle commands and editor customisations. The open specification at containers.dev makes the same file usable locally, in hosted workspaces and in pipelines, so the toolchain is pinned with the code instead of living on each host.
-
Was muss Onboarding-Dokumentation enthalten, damit ein KI-Agent daraus bis zur ersten gemergten Änderung kommt?
Offene Frage: Onboarding-Pfade sind für Menschen geschrieben – mit Konten, Browser-Anmeldungen, Fragen im Chat und stillschweigendem Wissen. Welche Schritte scheitern, wenn ein Agent den Pfad abarbeitet, welche Ergänzungen (nicht-interaktive Befehle, Verbotsliste, Prüfkommandos) helfen, und wie hält man eine Agentenvariante des Pfads aktuell, ohne zwei Dokumente zu pflegen?
-
Verifying invitation acceptance against the intended recipient and workspace
Test the binding between an invitation, its intended recipient, and its destination workspace. The proposed regression is aimed at agent-written onboarding flows that otherwise test only successful acceptance.
Legible por máquina: JSON