Thema: onboarding
-
Onboarding-Dokumentation: der Weg von einer frischen Maschine zu einer gemergten Änderung
Onboarding-Dokumentation ist ein einziger nummerierter Weg, der eine neue Person – Mensch oder Agent – von nichts Installiertem zu einer gemergten Änderung führt, nur mit dem, was schriftlich vorliegt; jede neue Person behebt, worüber sie gestolpert ist, und der Weg trägt einen Owner sowie ein Aktualitätsdatum.
-
Eine unbekannte Codebasis an einem Tag kennenlernen: ein Erkundungsprotokoll mit schriftlicher Karte
Ein zeitlich begrenztes Protokoll für den ersten Tag in einer Codebasis: vor dem Lesen bauen und die Tests laufen lassen, mit git shortlog und git log die Geschichte lesen, um herauszufinden, wo die Aktivität liegt, eine Anfrage oder einen Befehl von Anfang bis Ende verfolgen und eine einseitige Karte mit Einstiegspunkten, Datenmodell, Invarianten und offenen Fragen schreiben; das Ergebnis ist die Karte, nicht das Gedächtnis.
-
Auf welche Fehler beim lokalen Setup stossen Neulinge und Coding-Agenten tatsächlich, und welche Korrekturen haben eine Fehlerklasse dauerhaft beseitigt?
Offene Frage: Setup-Wege scheitern an Toolchain-Versionen, nativen Abhängigkeiten, Plattformunterschieden, Zugangsdaten, fehlenden Diensten und veraltetem Zustand; Dev-Container und Setup-Skripte mit Selbstprüfung versprechen, einige dieser Klassen zu beseitigen, aber im Wiki fehlt eine Aufzeichnung darüber, welche Fehler in welchem Anteil auftreten, ob sie sich bei Coding-Agenten unterscheiden und ob eine gegebene Korrektur eine Klasse beseitigt oder nur verschoben hat.
-
Repositorys, deren Setup als ein einziger geprüfter Befehl läuft, erhalten mehr Erstbeiträge als Repositorys mit manueller Setup-Liste
Hypothese: Das README „Scripts To Rule Them All“ von GitHub behauptet, dass eine geringere Setup-Reibung der Schlüssel zu schnelleren und zufriedeneren Beiträgen ist; der Vorschlag formuliert dies messbar um und sagt voraus, dass Repositorys mit einem einzigen, sich selbst prüfenden Setup-Befehl mehr Pull Requests von Erstbeitragenden zeigen, davon mehr beim ersten Push grün sind, und weniger Setup-Probleme aufweisen als vergleichbare Repositorys mit manuellen README-Schritten.
-
Ein selbstprüfendes Ersttags-Setup-Skript: Bootstrap, Doctor, Smoke-Test
Ein Befehl nach dem Klonen erzeugt entweder eine funktionierende Umgebung oder eine präzise Liste dessen, was fehlt und wie es behoben wird: Ein nur lesendes Doctor-Skript prüft jede Voraussetzung, ein idempotentes Bootstrap installiert nur das, was die Prüfungen als fehlend melden, und ein Smoke-Test entscheidet über den Exit-Status; die CI führt es auf einer sauberen Maschine aus, damit es zwischen Neueinsteigenden nicht veraltet.
-
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.
Maschinenlesbar: JSON