Clarify GitHub roles

[caichinger]

To avoid issues such as:

• Update https://swkwien.github.io/ to include meetup.com #122
• GDCR23: Session 3: Outside-In without Mocks #119

[codecop]

people less active or only active in the past should not have full access to repos. people active at the moment should have. Not sure what is difference of team and people. Maybe drop inactive people from team and make whole team owners?

[caichinger]

Just sharing as far as I understand it:

• https://github.com/orgs/swkWien/people:
  • the people that are part of the organization
  • privileges per person
  • privileges affect all repos in the organization (with the repo you can also specify a base role)
• https://github.com/orgs/swkWien/teams
  • group of people
  • when you add a team a repo, you can set privileges for the group
    • you can not assign privileges directly to a team
  • can be nested and hierarchical

At the moment we have two teams:

• Core (2: Peter, Christian)
• Organizers (12: ...)

and in total People (18: ...) with different privileges.

[caichinger]

At the moment I would do the following:

• Set all privileges per person to the minimum
• Organize all privileges through teams

I imagine that this way it is maybe more transparent.

However, that's just an idea and maybe there are better ways.

What do you think?

Pinging if you want to share @ReaSu @gregorriegler @maosmurf @rolger

[codecop]

I support whatever you decide to do

[gregorriegler]

I trust in whatever you do, and am happy to try it and iterate if needed.

[ReaSu]

I concur that using teams would make things more transparent, and I also support reducing privileges to the necessary minimum. However, I'm not entirely sure what that minimum would look like, what privileges/permissions are assignable separately, which are applicable on organisation level, and which are granted on a per-repo basis etc. I've been wanting to read about it, but haven't had the time yet.

I wanted to say more, but my brain has already shut down for the day. Words hard. Try again tomorrow.

[caichinger]

Von mir aus können wir auch gerne ausprobieren und dann weiter iterieren.

@ReaSu wie magst du tun?

[ReaSu]

Ich bin für ausprobieren - die Frage ist viel mehr: Was probieren wir aus?

[caichinger]

Ich bin für ausprobieren - die Frage ist viel mehr: Was probieren wir aus?

Ich würde den Vorschlag von oben probieren und schauen, wo er hinführt. Hab's mir nicht im Detail angeschaut, also vielleicht lernen wir eh schnell was. :D

Teams (mit einheitlicher Schreibweise):

• Core (erweitern weil Core entspricht irgendwie Owner?)
  • Organizer (mit Core als Parent)
  • GDCR24 (nur als Beispiel, das wäre praktisch beim nächsten Event)

Auf den Repos die Base Role auf "nix" setzen.

In den Repos Organizer als Team mit "Role: Write".
Wenn man will kann, man dann immer noch Core mit "Role: Admin" hinzufügen aber als Owner kann man das sowieso.
Bei dem bin ich mir unsicher (es gibt halt auch die per-User-Privileges). 🤷

[ReaSu]

Klingt gut!

Ich glaub, wir haben uns schon mal kurz drüber unterhalten - wer ist in welchem Team drin? Oder anders rum gefragt - wie lang bleibt man z.B. im Team Organizer, selbst wenn man länger nichts mehr organisiert hat? Wollen/brauchen wir da eine Faustregel?

[caichinger]

Klingt gut!

Dann probieren wir das.

Ich glaub, wir haben uns schon mal kurz drüber unterhalten - wer ist in welchem Team drin? Oder anders rum gefragt - wie lang bleibt man z.B. im Team Organizer, selbst wenn man länger nichts mehr organisiert hat? Wollen/brauchen wir da eine Faustregel?

Berechtigte Frage, habe da im Moment keine Meinung dazu.
Ich würde im ersten Schritt die Struktur aktualisieren und an den Personen (außer bei Core) erst mal nix ändern.
Wenn die Struktur steht, dann dazu weiter überlegen.
Kann mir vorstellen, dass wenn wir Team etwas bewusster nutzen, sich dann vielleicht was ergibt,

[ReaSu]

Kann mir vorstellen, dass wenn wir Team etwas bewusster nutzen, sich dann vielleicht was ergibt

Ja, das kann gut sein.

[ReaSu]

Organizer (mit Core als Parent)

Zwei Fragen dazu:

1. Child teams erben alle Berechteigungen des parent teams. Wozu brauchen wir dann überhaupt die Unterscheidung zwischen Core und Organisers?
2. Core ist jetzt ein secret team, damit kann es keine child teams haben. Gibt es ei en Grund, warum es secret sein soll?

[caichinger]

1. Child teams erben alle Berechteigungen des parent teams. Wozu brauchen wir dann überhaupt die Unterscheidung zwischen Core und Organisers?

Ich finde eine Unterscheidung zwischen Kernteam und "alle die auch irgendwie vielleicht wollen" schon sinnvoll.
Vorallem bei Letzterem tue ich mir dann leichter, Personen einfach mal dazu zu nehmen.

(Für mich persönlich ist der Unterschied zwischen Core und den Rechten auf Account Ebene unklarer.)

[ReaSu]

Ich hab natürlich die Rolle Owner mit dem Team Core vermischt. Dachte, es bekommen dann alle Organiser alle Owner-Berechtigungen.

[ReaSu]

Dachte, es bekommen dann alle Organiser alle Owner-Berechtigungen.

Da dachte ich doch nicht so falsch. Die Hierarchie funktioniert umgekehrt - das Kind-Team kann eine Rolle mit mehr Rechten haben als das Elter-Team, nicht umgekehrt.

Wir haben jetzt also:

• Members haben keine besonderen Rechte: sie können öffentliche Repos clonen und pullen.
• Team Organisators hat Schreibrechte auf alle aktiven Repos. In diesem Team sind alle, die Dojos oder Retreats organisieren/organisiert haben. Ist Elter von Admins.
• Team Admins formerly known as Core, mit Adminrechten in allen aktiven Repos. Ist Kind von Organisers.

Falls jemand mal testen will - bitteschön. Geht z.B. pushen auf dieses Repo? Sollte für alle in Organisators funktionieren. Bitte melden, falls nicht.

[caichinger]

Klingt gut. Danke für's Angehen!

Da dachte ich doch nicht so falsch. Die Hierarchie funktioniert umgekehrt - das Kind-Team kann eine Rolle mit mehr Rechten haben als das Elter-Team, nicht umgekehrt.

Ja, du hast Recht. Irgendwie lustig, das Kind hat mehr Rechte als die Eltern. Ich habe es so gemeint wie du aber es im Sinn dieser Relation falsch ausgedrückt.

[...] Repos [...]

Die Berechtigungen auf den Repos, wie hast du die gesetzt? Jeweils in den Repos oder geht das "globaler"?

Falls jemand mal testen will - bitteschön.

@gregorriegler bitte probiere das aus. Wir hatten bei dir ja das Thema mit https://github.com/swkWien/gdcr23.

---

Falls jemand so wie ich das Admin Team sucht. Ausklappen hilft ^^

[ReaSu]

Irgendwie lustig, das Kind hat mehr Rechte als die Eltern.

Ich bin bei der Elter-Kind-Bezeichnung geblieben, aber es macht mehr Sinn für mich, wenn ich an Menge und Teilmenge denk. Wir sind alle Organisers, und einige davon sind auch noch Admins.

Die Berechtigungen auf den Repos, wie hast du die gesetzt? Jeweils in den Repos oder geht das "globaler"?

Nein, das geht nicht globaler. Teams können zwar auf Organisationsebene angelegt werden, aber Rollen können sie nur in spezifischen Repos haben. Also in jedem Repo: Team hinzufügen, Rolle vergeben. Deshalb hab ich das auch bei den archivierten Repos nicht gemacht - da hat mir die Ausdauer gefehlt. 😬

Global, also auf Organisationsebene, können nur Grundrechte festgelegt werden - die Rechte der Members, die in keinem Team sind.

Falls jemand so wie ich das Admin Team sucht

Ah ja, danke. Das hab ich vergessen. Ich find, die Darstellung ist ein bisschen unglücklich gewählt.

[caichinger]

Irgendwie lustig, das Kind hat mehr Rechte als die Eltern.

Ich bin bei der Elter-Kind-Bezeichnung geblieben, aber es macht mehr Sinn für mich, wenn ich an Menge und Teilmenge denk. Wir sind alle Organisers, und einige davon sind auch noch Admins.

Mein Kommentar hat sich auch mehr auf die sprachliche Natur bezogen.

Glaube ich sollte mir anschauen, wie man sowas richtigerweise aufschreibt. :)

Die Berechtigungen auf den Repos, wie hast du die gesetzt? Jeweils in den Repos oder geht das "globaler"?

Nein, das geht nicht globaler. Teams können zwar auf Organisationsebene angelegt werden, aber Rollen können sie nur in spezifischen Repos haben. Also in jedem Repo: Team hinzufügen, Rolle vergeben. Deshalb hab ich das auch bei den archivierten Repos nicht gemacht - da hat mir die Ausdauer gefehlt. 😬

Global, also auf Organisationsebene, können nur Grundrechte festgelegt werden - die Rechte der Members, die in keinem Team sind.

Danke für die Klarstellung und das Tun!

Falls jemand so wie ich das Admin Team sucht

Ah ja, danke. Das hab ich vergessen. Ich find, die Darstellung ist ein bisschen unglücklich gewählt.

GitHub ist manchmal komisch.

[ReaSu]

Und dann gibt es auch noch ca. 125 Outside Collaborators im Repo https://github.com/swkWien/kata-bootstraps-gdcr20 - alle mit Schreibrechten auf diesem Repo.

Wir könnten uns überlegen, ob wir da einmal aufräumen wollen - z.B. Leute entfernen, die seit (Hausnummer) 1 Jahr nichts mehr gepusht haben; Teams für zukünftige Events anlegen, um dann einen besseren Überblick zu haben. Oder auch nicht. Der Monk in mir will Ordnung haben, aber so wirklich wichtig ist es mir auch nicht. Und schon gar nicht vor dem CR am Donnerstag.

[caichinger]

Ich hab viele Gedanken, die sich teilweise widersprechen.

:)

Was, wenn wir die bestehenden "Outside Collaborators" alle in ein eigenes Team geben?

Daran habe ich auch schon gedacht. Es ist aber ein bisschen so, wie wenn ich aufräume, indem ich alles was herumliegt einfach unters Bett schiebe. Es schaut zwar besser aus, aber den Monk befriedigt es nicht.

Ich sehe es nicht ganz so eng.

Andererseits: Ich glaube, wenn jemand einem Team hinzugefügt wird, wird dazu auch eine Einladung verschickt. Wir könnten dann alle löschen, die nicht innerhalb einer bestimmten Frist diese Anmeldung angenommen haben.

Sicher eine Möglichkeit. Ich fände es auch okay, sie direkt in das Team zu schieben und fertig (siehe unten).

Und weiters: Wenn bei neuen Terminen nur Leute hinzugefügt werden, aber nie gelöscht, dann verschiebt sich das Problem wieder, und es wird nicht gelöst.

Für mich ist das Problem weniger, dass wir Personen "herumliegen" haben, als dass ich die Features rund um Berechtigungen und Notifications mehr nutzen möchte und dafür sind Teams hilfreich.

Und dann stellt sich die Frage: Ist es wirklich ein Problem, dass in diesem Repo so viele Outside Collaborators sind? Warum? Warum nicht? Was ist der eigentliche Zweck dieser Aufräumaktion?

🤔

Für mich wäre dieses Sammelteam eine Möglichkeit, einen klar definierten Zustand herzustellen, von dem aus wir dann systematischer mit Teams weiter arbeiten.

Einen Vorteil den ich bspw. sehe, wenn es keine "Outside Collaborators" gibt: Wenn es doch welche gibt, weiß man, die gehören eigentlich in ein Team und dann kann man sie dorthin schieben. Mit der Anzahl die wir im Moment haben, ist das mMn nicht praktikabel.

Fazit für mich gerade: "Outside Collaborators" und "Teams" sind verwandte Themen aber mir geht es mehr um das Nutzbarmachen der Teams als das Aufräumen. Wobei mMn ein gewisses Aufräumen hilfreich ist, wenn wir Teams in Zukunft gezielter auch nach außen hin verwenden wollen.

[ReaSu]

Für mich wäre dieses Sammelteam eine Möglichkeit, einen klar definierten Zustand herzustellen

I see your point.

Ich habe jetzt ein Team External angelegt, und ihm im Repo kata-bootstraps-gdcr20 Schreibrechte gegeben.

Wichtiger Hinweis: Die Leute werden nicht ins Team verschoben, d.h. auch wenn sie im Team sind, sind sie auch weiter als external collaborators gelistet. Es ist also ein Prozess mit mehreren Schritten:

• Person ins Team einladen (und Person muss annehmen)
• Person als Outside Collaborator entfernen

Nachdem das eine ganze Menge Leute sind, sehe ich nicht, dass ich alle in einem Aufwasch einladen werde. Mein Plan wäre, über die nächsten Tage immer wieder daran zu arbeiten. Falls jemand mittun möchte, oder Zeit/Lust hat, alle auf einmal zu bewegen freu ich mich natürlich.

Ich glaube, dass für beide Ereignisse auch ein E-Mail versendet wird - es macht also durchaus Sinn, beide Schritte unmittelbar hintereinander auszuführen, damit die E-Mails auch kurz hintereinander eintreffen.

[codecop]

Wenn Du das machen willst dann entferne einfach alle Kollaborators. Nächster Termin von mir dazu ist Juni 2024, also kein Grund sich jetzt die Arbeit zu machen. Ich füge dann hinzu wen ich brauche, 1 Tag vor dem Event. Ok?

[codecop]

Würde ich dann ein eigenes Team machen mit den SR Coderetreats und das Team dann nur vor dem Event zu dem Repo zuweisen und nachher wieder entfernen? Dann würde in der Zeit dazwischen kein unerlaubter Zugriff sein?

[ReaSu]

Würde ich dann ein eigenes Team machen mit den SR Coderetreats und das Team dann nur vor dem Event zu dem Repo zuweisen und nachher wieder entfernen? Dann würde in der Zeit dazwischen kein unerlaubter Zugriff sein?

Das ist eine gute Frage, auf die ich keine Antwort weiß. Ist "unerlaubter Zugriff" ein Problem, das wir haben, und vor dem wir uns schützen wollen?

Für mich ist der Zweck dieser Übung hauptsächlich, mehr Ordnung zu haben, einen schnellen Überblick darüber, wer warum welche Rechte worauf hat. Für mich wärs deshalb interessanter, Leute aus der Liste zu entfernen, die keine Schreibrechte (mehr) brauchen, als denen Rechte nehmen, die sie immer wieder brauchen. Das würde aber heißen, dass die Liste der Teammitglieder auch in Zukunft gepflegt werden müsste, sprich: nicht nur Leute dazufügen, sondern auch entfernen. Und ich weiß ehrlich gesagt nicht, wie praktikabel das ist.

[caichinger]

Team für GDCR24

Ich würde als Testfall ein Team "gdcr24" anlegen (bezugnehmen auf Paul's Kommentar in #125 )

Für mich ist:

• "Admins" Teil von "gdcr24"
• "Organizers" auf gleicher Ebene wie "gdcr24"

Macht das Sinn?
Wenn ja, wie bildet man das ab?
Wenn nein, wie könnte man das noch sehen?

Nicht so:

[ReaSu]

Ich kann deinen Gedankengang nachvollziehen, aber ich glaub nicht, dass das so abbildbar ist.

Ich würde es so sehen:

• Alle, die beim GDCR mithelfen, sind auch im Team Organisers. Also muss GDCR24 in der Hierarchie unterhalb von Organisers stehen.
• Zwischen gdcr24 und Admins besteht keine hierarchische Beziehung (im Sinn von: keins der Teams ist eine Teilmenge des anderen)

Daraus ergibt sich: Admins und gdcr24 haben beide Organisers als Elter, und stehen nebeneinander auf der gleichen Ebene.

Team gdcr24 kann dann auch im gdcr-repo Maintainer-Rechte bekommen, damit umgehen wir Probleme wie Gregor sie dieses Jahr hatte.

[caichinger]

Ich kann deinen Gedankengang nachvollziehen, aber ich glaub nicht, dass das so abbildbar ist.

Danke für deine Einschätzung.

Ich glaube auch, dass das nciht geht.

Alle, die beim GDCR mithelfen, sind auch im Team Organisers. Also muss GDCR24 in der Hierarchie unterhalb von Organisers stehen.

Das sehe ich nicht so. Für mich sind nicht alle GDCR24-Mithelfenden auch SWK-Organizer (bspw. Karin von GDCR22).

Zwischen gdcr24 und Admins besteht keine hierarchische Beziehung (im Sinn von: keins der Teams ist eine Teilmenge des anderen)

Vielleicht ist das eine wichtige Differenzierung. Ich dachte, Admins braucht man evtl. um Berechtigungsprbleme zu lösen aber dafür müssen sie natürlich nicht im Team sein. Danke.

---

Ich werde ein GDCR24 Team anlegen, da kann man Personen hinzufügen und wenn man später noch eine Relation hinzufügen möchte, kann man das tun.

[ReaSu]

Das sehe ich nicht so. Für mich sind nicht alle GDCR24-Mithelfenden auch SWK-Organizer (bspw. Karin von GDCR22).

Stimmt, daran hab ich nicht gedacht.

Danke fürs Anstoßen und Machen!

[caichinger]

Klar, bitte gerne. Danke auch dir. :)

[caichinger]

Beobachtung:

Paul und Gregor haben sich gemeldet, um dem GDCR24 Team beizutreten. Dieses bewusste Opt-in finde ich gut und ist auch, was ich mir erhofft habe.

(Danke, Rea, für's Hinzufügen.)

[caichinger]

@gregorriegler ich habe gesehen, dass es wieder Schwierigkeiten/Verwirrung rund um die Berechtigungen gab. Ich habe gerade nicht die Zeit um das nachzuvollziehen aber falls es ein Learning gibt, bitte hier teilen. Schade um die Energieverluste bei dem Thema.

[gregorriegler]

Das Problem war, dass GitPod.io nicht berechtigt war auf unser Repository zu pushen, und ich hatte keine Berechtigung das herzustellen. Peter hat den "request" dann approved. Er hatte also die Berechtigung. Ich hab lange damit verbracht heraus zu finden was das Problem ist, und konnte meine eigentliche Arbeit nicht machen.

[codecop]

Hallo Leute, danke für die Diskussion. Ist das Ergebnis dieser Diskussion konkret? Was soll gemacht werden? Was sollen unsere Regeln sein? Oder können wir das schließen?

[caichinger]

Mein Wunsch war zu klären, wie wir das Berechtigungssystem von GitHub sinnvoll nutzen um Berechtigungsprobleme in Zukunft zu vermeiden.

Also klären:
a) Wie funktionierts?
b) Wie bilden wir uns darin ab?

Im Moment ist der Prozess so, dass wir ad hoc Leute direkt zu Repos hinzufügen. Dabei werden verlässlich immer Personen vergessen. Die Laufen in ein Problem. Die melden sich. Es wird gefixed. Das hat noch jedes Mal Reibungsverluste und eine gewisse Frustration erzeugt.

---

Es gibt kein konkretes Ergebnis, weil wir die Diskussion nicht zu Ende geführt haben.

---

Vielleicht zahlt es sich nicht aus, weil unser bestehender Prozess auch funktioniert.

Wenn du das Bedürfnis hast, die Diskussion zu schließen, kannst du das von mir aus tun.