Diese Anleitung erklärt, was eine GitHub Organization ist, warum sie für Teams wichtig ist und wie wir sie bei OpenSIN sauber nutzen.
Eine GitHub Organization ist der gemeinsame Arbeitsraum für ein Team, eine Firma oder eine Community.
Statt dass alle Repositories unter einzelnen Privataccounts liegen, gehören sie einer gemeinsamen Struktur.
Das bringt Ordnung, klare Verantwortlichkeiten und bessere Zusammenarbeit.
Mit einer Organization bekommt ihr:
- gemeinsame Besitzstruktur statt Einzelabhängigkeit
- Teams und Rollen statt Chaos
- zentrale Rechteverwaltung
- bessere Onboarding- und Offboarding-Prozesse
- gemeinsame Sichtbarkeit nach außen
- ein professionelles Zuhause für alle Repos
Kurz:
Eine Organization ist das Betriebsmodell für ernsthafte Teamarbeit auf GitHub.
Owners haben weitreichende Rechte. Sie können unter anderem:
- Mitglieder verwalten
- Teams anlegen
- Repository-Rechte ändern
- Sicherheits- und Abrechnungssettings ändern
Regel:
Owners sollten wenige sein. Nicht jeder im Team braucht Owner-Rechte.
Members sind normale Organisationsmitglieder. Sie arbeiten in Teams und Repositories, ohne alles administrieren zu müssen.
Teams sind die wichtigste Struktur innerhalb einer Organization.
Beispiele:
corefrontendautomationdocsresearchops
Über Teams steuert ihr:
- Repository-Zugriff
- Review-Verantwortung
- klare Zuständigkeiten
Die Repositories sind die eigentlichen Arbeitsräume. Sie sollten klar benannt, thematisch sauber und für das Team nachvollziehbar strukturiert sein.
Für OpenSIN sollte die Organization nicht nur ein Repo-Container sein, sondern ein klarer Betriebsraum.
- gemeinsame sichtbare Markenpräsenz
- klare Teamstruktur
- sauberes Rechtekonzept
- nachvollziehbare Verantwortung
- schnellere Zusammenarbeit
- neue Mitglieder können sauber eingeladen werden
- Zugriffe lassen sich über Teams vergeben statt einzeln
- wenn eine Person geht, bleiben Repos, Prozesse und Wissen im System
- Außenstehende sehen ein professionelles Gesamtbild
Auch eine GitHub Organization kann eine eigene Profilseite mit README haben.
Dafür braucht die Organization ein öffentliches Repository mit dem Namen .github.
Darin liegt diese Datei:
profile/README.md
Beispiel:
.github/profile/README.md
Diese README wird dann auf der Profilseite der Organisation angezeigt.
GitHub unterscheidet bei Organisationsmitgliedern zwischen:
- private membership
- public membership
Wenn Mitglieder auf private stehen, erscheinen sie nicht öffentlich auf der Org-Seite.
Wichtig für Owners:
Du kannst als Org-Owner andere Mitglieder nicht zentral öffentlich schalten. GitHub erlaubt das nur der jeweiligen Person selbst.
Das ist eine GitHub-Regel und kein Konfigurationsfehler von OpenSIN.
Wenn OpenSIN-Mitglieder öffentlich auf der Org-Seite sichtbar sein sollen, muss jede Person die eigene Mitgliedschaft selbst auf public stellen.
- GitHub öffnen
OpenSIN-AIaufrufen- Bereich People öffnen
- Bei der eigenen Mitgliedschaft die Sichtbarkeit von Private auf Public umstellen
Jede Person kann es auch selbst per GitHub CLI tun:
gh auth refresh -h github.com -s write:org
gh api -X PUT /orgs/OpenSIN-AI/public_members/$(gh api user --jq .login)gh api /orgs/OpenSIN-AI/public_members --jq '.[].login'Wenn dort dein Username erscheint, bist du öffentlich sichtbar.
Eine starke Org-README sollte beantworten:
- Wer sind wir?
- Was bauen wir?
- Wofür stehen wir?
- Welche wichtigen Repositories gibt es?
- Wie kann man mitmachen oder Kontakt aufnehmen?
- Kurze Positionierung
- Mission / Fokus
- Wichtige Repositories
- Wie wir arbeiten
- Mitmachen / Kontakt
Empfohlene Basis-Teams:
owners– nur sehr kleiner Kreiscore– technische Kernverantwortungdocs– Dokumentation und Strukturresearch– Recherche und Wissensaufbereitungops– Betrieb, Deployment, Infrastruktur
- Owner-Rechte nur für wenige Personen
- Schreibrechte bevorzugt über Teams statt über Einzelpersonen
- Repos nach Verantwortungsbereich zuweisen
- Admin-Rechte sparsam vergeben
Je klarer Repos benannt sind, desto besser versteht das Team die Landschaft.
Beispiele:
dev-setupwebsite-my.opensin.aiwebsite-opensin.aiinternal-automationdocs-playbooks
Regel:
Repo-Namen sollen Zweck und Inhalt sofort erkennbar machen.
Vermeidet:
- private Spielrepos ohne erkennbaren Zweck
- unsaubere Namenskonventionen
- Owner-Rechte für zu viele Leute
- unklare Teamzuordnung
- Repositories ohne Verantwortliche
# OpenSIN
OpenSIN ist unser gemeinsamer Arbeitsraum für Systeme, Tools, Websites, Automationen und operative Entwicklungsprozesse.
## Fokus
- AI-first Workflows
- Tools mit echtem Hebel
- Dokumentation, Struktur und schnelle Umsetzbarkeit
## Wichtige Repositories
- [dev-setup](https://github.com/OpenSIN-AI/dev-setup)
- [website-my.opensin.ai](https://github.com/OpenSIN-AI/website-my.opensin.ai)
## Wie wir arbeiten
- klare Ownership
- strukturierte Issues und Pull Requests
- sichtbare Dokumentation
## Kontakt
- GitHub Organization: https://github.com/OpenSIN-AI- Rollen und Teams sind klar
- Owner-Kreis ist klein und bewusst gewählt
- Wichtige Repositories sind sichtbar
- Rechte werden über Teams statt über Chaos verwaltet
- Die Org-README erklärt klar, wofür die Organisation steht