Über¶

Wer sie baut¶

Dennis Otto baut und pflegt jedes Projekt auf dieser Website, öffentlich und unter Open-Source-Lizenzen. Er liest jedes Issue, prüft die Pull Requests anderer, entscheidet, was als Nächstes kommt, und beantwortet die Meldungen von Sicherheitslücken; Bots erledigen die Routinearbeit, jeder mit den geringsten Rechten, die er braucht.

Warum es sie gibt¶

Die Projekte verbinden Werkzeuge, die Menschen zu Hause und bei der Arbeit schon nutzen: ein Autodarts-Board mit Home Assistant, das Dokumentenarchiv von Paperless-ngx mit Nextcloud, und die Issues und Releases eines Repositorys mit Bots, die sich darum kümmern. Jedes soll so verlässlich sein wie die Arbeit eines Teams, mit einem Menschen dahinter: Tests für jede Änderung, signierte Releases, die jeder prüfen kann, Sicherheitsprüfungen, eine eigene Website und eine erste Antwort auf jedes Issue. Die Seite Vertrauen zeigt, was jedes Projekt garantiert.

Wie sie entstehen¶

Jedes Repository entsteht aus einer Vorlage, Repo Blueprint: dieselben Prüfungen, Workflows, Einstellungen und Richtlinien in jedem, für jede Art von Projekt. Was ein Repository lernt, bringt der Blueprint zu allen.

Ein Blueprint. Eine Änderung am Blueprint, etwa eine schnellere Prüfung oder eine neue Sicherheitskontrolle, wird zu einem Release des Blueprints, und sein Bot bringt dieses Release als Pull Request in jedes Repository, der die Prüfungen dieses Repositorys besteht wie jede andere Änderung.
Releases. Der Release-Bot macht aus den Titeln der gemergten Pull Requests die nächste Version und ihr Changelog, baut, signiert und veröffentlicht dann das Release, und ein Workflow prüft es so, wie seine Nutzer es können.
Updates. Renovate hält die Abhängigkeiten, die Actions und die Images aktuell, eine Woche nach ihrem Release, oder sofort, wenn ein Update eine Sicherheitslücke behebt.
Triage. Der Issue assistant gibt einem neuen Issue eine erste Analyse durch eine KI, die nur liest, vergibt seine Labels, findet Duplikate, erinnert an offene Fragen und schließt ein Issue, sobald ein Release seinen Fix ausliefert.
Einstellungen. Der Settings-Bot wendet die Einstellungen jedes Repositorys, etwa die Regeln seines main, nach jeder Änderung und jede Woche aus einer Datei des Repositorys an, sodass sich eine Einstellung nur in einem geprüften Pull Request ändert.
Hilfe in Pull Requests. Jede Prüfung erklärt sich, wenn sie fehlschlägt: was sie gefunden hat, warum das wichtig ist und wie es sich beheben lässt, und ein Bot macht jeden Fix, den ein Befehl machen kann.

flowchart TB
    accTitle: Von einer Änderung zum Release in jedem Repository
    accDescr: Eine Änderung am Blueprint, ein Pull Request eines Menschen, von Renovate oder eines Bots, erreicht main nur über jede Pflichtprüfung. Der Release-Bot des Blueprints macht daraus ein Release mit einem signierten Tag, Provenienz und SBOMs, das sich nach der Veröffentlichung nicht mehr ändern kann. Der Blueprint-Bot jedes Projekts prüft dieses Release und öffnet einen Pull Request damit, der jede Pflichtprüfung des Projekts besteht, wie die eigenen Pull Requests des Projekts. Der Release-Bot des Projekts veröffentlicht dann ein eigenes signiertes, unveränderliches Release. Ein Workflow prüft jedes Release so, wie seine Nutzer es können, nach jedem Release und jede Woche, der Issue assistant schließt die Issues, die das Release behebt, und die Nutzer bekommen das Release, das diese Website zeigt.

    subgraph blueprint ["Repo Blueprint"]
        change(["Ein Pull Request eines Menschen,<br>von Renovate oder eines Bots"])
        checks{{"Jede Pflichtprüfung"}}
        main["main"]
        release(["Release-Bot<br>signierter Tag, Provenienz, SBOM,<br>ein unveränderliches Release"])
    end

    subgraph project ["Jedes Projekt"]
        update(["Blueprint-Bot<br>prüft das Release und<br>öffnet einen Pull Request damit"])
        own(["Seine eigenen Pull Requests"])
        projectchecks{{"Jede Pflichtprüfung<br>des Projekts"}}
        projectmain["main"]
        projectrelease(["Release-Bot<br>ein signiertes, unveränderliches Release"])
    end

    verify(["Release prüfen<br>so geprüft, wie seine Nutzer es können,<br>nach jedem Release und jede Woche"])
    issues(["Issue assistant<br>schließt die Issues,<br>die das Release behebt"])
    users["Die Nutzer<br>und diese Website"]

    change --> checks --> main --> release
    release -- "jedes Projekt" --> update
    update & own --> projectchecks --> projectmain --> projectrelease
    projectrelease --> verify & issues
    projectrelease --> users

    classDef bot fill:#526cfe2e,stroke:#526cfe,stroke-width:2px
    classDef person fill:#f59e0b2e,stroke:#f59e0b,stroke-width:2px
    classDef done fill:#16a34a2e,stroke:#16a34a,stroke-width:2px
    class release,update,projectrelease,verify,issues bot
    class change,own person
    class users done

Automatisierung listet jeden Workflow dieses Repositorys mit dem, was er tut, und das Dashboard zeigt den Zustand jedes Repositorys auf einen Blick.

Entscheidungen¶

Die Entscheidungen, die ein Projekt prägen, sind mit ihren Gründen aufgeschrieben, damit eine spätere Änderung sieht, warum die Dinge so sind, wie sie sind. Die Entscheidungen dieser Website erklären auf Englisch, wie sie die ganze Adresse bedient und woher ihre Live-Fakten kommen, und die des Blueprints prägen jedes Repository.

Unterstützen¶

Die Projekte sind kostenlos und Open Source. Wenn sie dir nützen, kannst du ihre Entwicklung über GitHub Sponsors unterstützen.

Unterstützen

Kontakt¶

Fragen, Probleme und Ideen zu einem Projekt gehören in die Issues seines Repositorys: Die Issue-Auswahl dieser Website führt zu denen jedes Projekts und hat die Formulare für die Website selbst. Melde eine Sicherheitslücke bitte vertraulich, wie Vertrauen beschreibt. Alles andere erreicht Dennis über sein Profil auf GitHub.