Repository-Struktur und Kanban-Board
Repository-Struktur
Auf der Plattform openCode organisiert KERN die Arbeit am Design-System und am Code. Du findest dort folgende Repositorys:
- KERN – Hauptrepository: Hier sind das Anforderungsmanagement und die Entwicklung des Design-Systems organisiert. Auf dem Kanban-Board kannst du Änderungen und neue Komponenten vorschlagen oder beitragen (LINK auf Seite “Komponente / Pattern vorschlagen oder beitragen”). Code findest du in diesem Repository nicht.
- KERN – Plain-CSS-HTML-Kit: Wie der Name sagt, findest du in diesem Repository das KERN Plain-CSS-HTML-Kit. Diese Technologie wird vom KERN Team immer aktuell gehalten. Bug-Reports und Verbesserungsvorschläge, die sich ausschließlich auf den CSS/HTML-Code beziehen, sind hier richtig.
- KERN – Produktwebseite: Dieses Repository enthält den Code für alles, was du auf dieser Webseite findest.
- KERN – Labor: In diesem Ordner probieren wir Dinge aus. In diesen Repositorys findest du experimentelle Ansätze und neue Ideen, die noch nicht Teil des offiziellen Produkts sind. Die Inhalte sind oft noch unfertig und können Fehler enthalten.
- KERN – Community: In diesem Ordner entstehen nach und nach Repositorys mit KERN Kits für weitere Technologien. Diese Repositorys werden von Community-Mitgliedern bereitgestellt und gepflegt. Dadurch wird das KERN Angebot sehr viel schneller ausgeweitet. Vielen Dank an alle Beteiligten!
Kanban-Board im Hauptrepository
Auf dem Kanban-Board im Hauptrepository sind das Anforderungsmanagement und die Entwicklung des Design-Systems organisiert. Du erhältst dort einen detaillierten Überblick über die aktuelle Arbeit und zukünftige Planung.
Das Kanban-Board hat acht Spalten:
| Spalte | Beschreibung |
|---|---|
| Open | Hier landen automatisch alle erstellten Tickets. Zusätzlich liegen hier die Roadmap-Tickets und Epics. Tickets in Open ohne Label wurden noch nicht betrachtet und priorisiert. |
| Refinement benötigt | Enthält die Tickets, die noch nicht umsetzungsbereit sind und klärungsbedarf haben. |
| Startklar | Enthält die Tickets, die zur Bearbeitung freigegeben sind. Sortiert nach Priorität. |
| In Bearbeitung | Enthält die Tickets, deren Umsetzung gerade erfolgt. |
| Qualitätssicherung | Enthält die Tickets, die nach der Bearbeitung qualitätsgesichert werden. |
| Finales Review | Enthält die Tickets, die im Review vorgestellt werden. |
| Closed | Enthält alle Tickets, die erfolgreich abgeschlossen oder abgelehnt wurden. |
Weitere Labels helfen bei der Einordnung auf den ersten Blick:
| Label | Beschreibung |
|---|---|
| Loading... | Themen für eine langfristige und strategische Produktplanung. |
| Loading... | Tickets, die noch nicht bearbeitet werden und im Backlog liegen. |
| Loading... | Diese Tickets wird das KERN Team bearbeiten. |
| Loading... | Diese Tickets werden vom KERN Team begleitet, wenn eine externe Person / Organisation die Umsetzung übernimmt. (siehe: So trägst du Komponenten / Patterns bei ) |
| Loading... | Tickets, die unerwünschtes Verhalten in der Dokumentation oder in den Komponenten festhalten. Ziel: Funktionalität und Qualität des Produktes sicherstellen. |
| Loading... | Tickets, die aufgrund von Abhängigkeiten nicht weiterbearbeitet werden können. |
| Priotitäten-Labels: Loading... Loading... Loading... Loading... Loading... | Für die Priorisierung des Produktbacklogs. Standardmäßig werden Prio 2, 3 und 4 vergeben. Prio 1 ist für akute Einschübe reserviert, Prio 5 ist für Tickets, die noch in weiter Ferne liegen. |
| Typ-Labels: Loading... Loading... Loading... | Epics dienen der langfristigen Projektplanung. Storys und ToDos sind für die Bearbeitung gedacht. ToDos sind in sich abgeschlossene Einzelaufgaben. |
| Gewerk-Labels: Loading... Loading... Loading... Loading... Loading... | Tickets werden den Gewerken zugewiesen, wenn diese an der Bearbeitung beteiligt sind. |