Was macht Projekt-Workflow-Ops?
Diese Fähigkeit verwandelt isolierte GitHub-Issues, PRs und Linear-Aufgaben in einen einheitlichen Ausführungsfluss.
Verwenden Sie sie, wenn das Problem Koordination ist, nicht Programmierung.
Wann zu verwenden
- Triage offener PR- oder Issue-Backlogs
- Entscheiden, was in Linear gehört vs. was nur auf GitHub bleiben sollte
- Verknüpfen aktiver GitHub-Arbeit mit internen Ausführungsspuren
- Klassifizieren von PRs in Merge, Port/Neubau, Schließen oder Parken
- Prüfen, ob Review-Kommentare, CI-Fehler oder veraltete Issues die Ausführung blockieren
Betriebsmodell
- GitHub ist die öffentliche und gemeinschaftliche Wahrheit
- Linear ist die interne Ausführungswahrheit für aktive geplante Arbeit
- Nicht jedes GitHub-Issue benötigt ein Linear-Issue
- Linear erstellen oder aktualisieren nur, wenn die Arbeit:
- aktiv ist
- delegiert ist
- geplant ist
- funktionsübergreifend ist
- wichtig genug ist, um intern verfolgt zu werden
Kern-Workflow
1. Die öffentliche Oberfläche zuerst lesen
Sammeln:
- GitHub-Issue- oder PR-Status
- Autor und Branch-Status
- Review-Kommentare
- CI-Status
- verknüpfte Issues
2. Die Arbeit klassifizieren
Jeder Eintrag sollte in einem dieser Zustände enden:
| Zustand | Bedeutung |
|---|---|
| Merge | in sich geschlossen, richtlinienkonform, bereit |
| Port/Neubau | nützliche Idee, sollte aber manuell innerhalb von ECC neu eingebracht werden |
| Schließen | falsche Richtung, veraltet, unsicher oder dupliziert |
| Parken | potenziell nützlich, aber derzeit nicht geplant |
3. Entscheiden, ob Linear gerechtfertigt ist
Linear nur erstellen oder aktualisieren, wenn:
- die Ausführung aktiv geplant ist
- mehrere Repos oder Arbeitsströme betroffen sind
- die Arbeit interne Zuständigkeit oder Sequenzierung benötigt
- das Issue Teil eines größeren Programm-Pfads ist
Nicht alles mechanisch spiegeln.
4. Die beiden Systeme konsistent halten
Wenn Arbeit aktiv ist:
- GitHub-Issue/PR sollte öffentlich sagen, was passiert
- Linear sollte Eigentümer, Priorität und Ausführungspfad intern verfolgen
Wenn Arbeit ausgeliefert oder abgelehnt wird:
- die öffentliche Lösung zurück auf GitHub posten
- die Linear-Aufgabe entsprechend markieren
Überprüfungsregeln
- Nie nur nach Titel, Zusammenfassung oder Vertrauen zusammenführen; den vollständigen Diff verwenden
- Externe Quellfunktionen sollten innerhalb von ECC neu aufgebaut werden, wenn sie wertvoll, aber nicht in sich geschlossen sind
- CI Rot bedeutet klassifizieren und beheben oder blockieren; nicht so tun, als sei es merge-bereit
- Wenn der eigentliche Blocker die Produktrichtung ist, dies sagen, anstatt sich hinter Werkzeugen zu verstecken
Ausgabeformat
Zurückgeben:
PUBLIC STATUS
- Issue / PR Status
- CI / Review Status
CLASSIFICATION
- merge / port-rebuild / close / park
- ein Absatz Begründung
LINEAR ACTION
- create / update / no Linear item needed
- Projekt / Spur falls zutreffend
NEXT OPERATOR ACTION
- genauer nächster Schritt
Gute Anwendungsfälle
- „Prüfe das offene PR-Backlog und sage mir, was zusammengeführt vs. neu aufgebaut werden soll“
- „Ordne GitHub-Issues unseren ECC 1.x- und ECC 2.0-Programmpfaden zu“
- „Prüfe, ob dies ein Linear-Issue benötigt oder nur auf GitHub bleiben sollte“