Rechts. Jetzt haben wir organisatorische Rollen, die von wenigen Personen besetzt sind und sich nicht in Berechtigungen widerspiegeln, wobei die Annahme ist, dass Personen keine Berechtigungen verwenden werden, wenn sie keine Einigung mit den Personen mit einer Rolle haben. Also, wir sind jetzt ziemlich liberal mit den Berechtigungen, aber ich nehme an, dies würde uns dahin führen, wo Berechtigungen mit Rollen übereinstimmen, was uns wiederum wahrscheinlich dazu führen würde, dass wir Berechtigungen für Personen widerrufen, die in der Vergangenheit Beiträge geleistet haben.

Es könnte eine gute Sache sein, die Dinge ein wenig zu straffen, aber ich weiß nicht, ob es der Community helfen wird. Vielleicht gibt es noch andere Wege?

Eine Möglichkeit, wie es der Community helfen wird, besteht darin, dass Fragen gezielt an die gestellt werden
rechte Menschen. Ich werde oft in Dingen @-erwähnt, die außerhalb meiner Kontrolle liegen. Ich kann ertragen
Verantwortung für solid-auth-client, aber nicht andere.

Ich denke, es ist erwähnenswert, dass wir in dem vor einigen Monaten veröffentlichten Entwurf der Community-Rollenbeschreibungen den Ansatz gewählt haben, Project Core Contributors , Project Contributors und Project Release Managers zu beschreiben.

Daher haben wir für dieses Problem bestehende Definitionen für projektspezifische Teams (dh Knoten-Solid-Server, Solid-Auth-Client). Ich denke, dass das Manko darin besteht, dass in der letzten Pull-Anfrage keine Projektmitwirkenden genannt wurden, noch eine Sprache darüber, warum sie es nicht waren. Meiner Meinung nach sollten wir zumindest einige der Projekte mit höherem Profil (wie Node-Solid-Server, Solid-Auth-Client) identifizieren, die sich derzeit unter der Solid-Organisation befinden, und einen Einblick in die dort verbundenen Teammitglieder geben.

Eigentlich denke ich, dass wir definieren müssen, was wir mit "Projekt", "Repository" usw. meinen. Eigentlich hatte ich nicht das gleiche Verständnis, @justinwb , ich habe "Projekt" als eine sehr breite Sache interpretiert, wie in " Solid Project" und auch "Repository" als ziemlich weit gefasst, dh github ist ein Repository, npm ist ein Repository.

Jetzt haben wir Github-Projekte und Repositories, die wir auch operativ nutzen, also sind diese Begriffe nicht wirklich geeignet.

Wir würden wahrscheinlich auch keine Pro-Repo- oder Pro-Package-Manager-Rollen haben wollen, das wäre ein Manager mit sehr engem Umfang ... Ich denke, es ist besser, "Backend-Manager", "Dev-Tools-Manager" zu haben. usw. Die Rolle des Backend-Managements würde beispielsweise NSS- und Solid-Projekt-Abhängigkeiten umfassen.

Ich denke immer noch, dass wir eine Rolle verwenden könnten, die eine alltägliche operative Rolle ist, um die Kohärenz von Releases bei Bedarf sicherzustellen, was meiner Meinung nach "Project Release Manager" sein sollte, obwohl wir es nicht brauchten diese Funktionen zu haben. Und vielleicht ist es für eine einzelne Person sowieso zu viel.

Ich denke, dass ich in letzter Zeit eine „Tech Lead Backend“-Rolle gespielt habe, aber das ist eher eine Inrupt-Rolle als eine Solid-Rolle.

Ich bringe nur eine sehr enge Perspektive aus meiner eigenen Sicht. Ich bin
derjenige, der derzeit solid-auth-client verwaltet. Ich würde mir solche Klarheit wünschen
Entweder wissen die Leute, dass es meine Verantwortung ist, oder dass jemand anderes es übernimmt
diese Verantwortung; dh ich hätte lieber keine undokumentierten Verantwortlichkeiten,
denn das könnte in Zukunft zu Problemen führen.

Zum Beispiel, als ich de facto noch die Person war, die veröffentlichte
node-solid-server, jemand anderes hat diese Verantwortung vorübergehend übernommen und
versehentlich drei kaputte Veröffentlichungen veröffentlicht.

Lassen Sie uns also zumindest für die wichtigeren Repos klarstellen, wer das kann
freigeben und veröffentlichen.

Was halten Sie von Holacracy https://www.holacracy.org für die Verwaltung von Solid-Projekten?
Theoretisch kann es die Organisation in Kreise nach Interessengruppen aufteilen, jeder Kreis hat einen "Grund zu sein", der es verdeutlicht, mit einem "Referenten" als "erste Verbindung", Rollen und Kreise werden bestimmt, und die Mutation dieser wird in Funktion geregelt der Bedürfnisse.

https://communitywiki.org/wiki/DoOcracy ;)

Ich habe einen Lösungsvorschlag..

Weisen Sie folgende Rollen zu:

node-solid-server Repository-Manager: @kjetilk
solid-auth-client Repository-Manager: @RubenVerborgh
Community-Repository-Manager: @Mitzi-Laszlo

@megoth @justinwb und andere, wer wäre am besten für die folgenden Rollen geeignet?
rdflib-Repository-Manager:
solid-panes-Repository-Manager:
solid-ui Repository-Manager:
mashlib-Repository-Manager:

Es gibt einige Repositories, die meiner Meinung nach von einer Zusammenführung profitieren würden. Zum Beispiel: solid-tutorial-intro, solid-tutorial-angular, solid-tutorial-rdflib.js, profile-viewer-tutorial, Understanding-linked-data, solid-tutorial-pastebin, web-summit-2018, intro-to -solid-slides könnten alle mit resources.md im Community-Repo zusammengeführt werden. Darüber hinaus könnten Releases, solid-architecture, user guide, vocab, solid-namespace, solid-platform, solid-spec, web-access-control-spec, solid-apps und solid.mit.edu möglicherweise ebenfalls in die Community aufgenommen werden Repo. Vielleicht gibt es ähnliche Kombinationen, die mit anderen Repos passieren könnten?

Wenn zwei Personen an demselben Repo arbeiten, wäre es eine Frage der Frage, wer der Manager ist und daher für die Aufsicht verantwortlich ist, und wer der Hauptbeitragende ist.

Projekte müssen in der plan.md des Community Repos definiert werden.

Gedanken?

node-solid-server Repository-Manager: @kjetilk
solid-auth-client Repository-Manager: @RubenVerborgh
Community-Repository-Manager: @Mitzi-Laszlo

Jawohl

rdflib-Repository-Manager:
solid-panes-Repository-Manager:
solid-ui Repository-Manager:
mashlib-Repository-Manager:

Nur @timbl kann das, denke ich.

Es gibt einige Repositories, die meiner Meinung nach von einer Zusammenführung profitieren würden.

Zusammengeführt? Wie in, sie zu einem Repository machen?
Das ist aus mehreren Gründen keine gute Idee (ich kann das näher ausführen), aber vielleicht verstehe ich das falsch?

Wenn zwei Personen an demselben Repo arbeiten, wäre es eine Frage der Frage, wer der Manager ist und daher für die Aufsicht verantwortlich ist, und wer der Hauptbeitragende ist.

Für komplexere Repos könnte es mehrere geben.

@megoth @justinwb und andere, wer wäre am besten für die folgenden Rollen geeignet?
rdflib-Repository-Manager:

rdflib befindet sich in der linkeddata-Organisation auf Github und fällt daher möglicherweise nicht unter die Arbeit, die als Teil der soliden Organisation auf Github geleistet wird. Es ist jedoch ein wichtiges Paket, daher sollten wir die Leute von linkeddata bitten, ihre Rollen in diesem Repository zu formalisieren.

solid-panes-Repository-Manager:
solid-ui Repository-Manager:
mashlib-Repository-Manager:

Ja, @timbl ist der einzige, der das kann. Vielleicht möchte er delegieren, aber das ist eine andere Diskussion.

Großartig, ein Weg nach vorne besteht darin, Tim wie folgt einen Vorschlag für die Rollenverteilung zu unterbreiten:
node-solid-server Repository-Manager: @kjetilk
solid-auth-client Repository-Manager: @RubenVerborgh
Community-Repository-Manager: @Mitzi-Laszlo
solid-panes-Repository-Manager: @timbl
solid-ui-Repository-Manager: @timbl
mashlib-Repository-Manager: @timbl
Irgendwelche zusätzlichen Vorschläge? Bearbeitungen?

Wer wäre der Repository-Manager für alle Repositorys, die nicht in der obigen Liste aufgeführt sind? Oder hätten sie keinen Repository-Manager? Diese schließen ein:
mavo-fest
webid-oidc-spez
oidc-auth-manager
Solid-Multi-RP-Client
Ordnerbereich
wac-zulassen
Pane-Registrierung
oidc-rs
Schlüsselbund
feste Scheibe
Solid-Benachrichtigungen
Solid-Profil-UI
feste-verbindungen-ui
solid-pane-source
Josef
Solid-Posteingang
oidc-op
solide-tif
Solid-Client
oidc-rp
Ausgabefenster
solide
Solid-IdP-Liste
kvplus-Dateien
Solid-E-Mail
Profil-Betrachter-Reaktion
oidc-web
solid-auth-client
Solide Anmeldung
fester-mitnahme-import
Knoten-Solid-ws
solid-auth-tls
ldflex-spielplatz
Abfrage-ldflex
Reaktionskomponenten
solid-auth-oidc
Besprechungsbereich
Solid-Dips
Solid-Kli
Solid-Web-Client
Solid-Berechtigungen
acl-check

Die folgenden Repositories haben bis jetzt auch keinen Repository-Manager, aber der Inhalt wird im Community-Repo erwähnt und sie beziehen sich auf Governance-Prozesse, daher wäre ich bereit, Repository-Manager-Kandidat für sie zu werden.
Solid-Tutorial-Intro, Solid-Tutorial-Angular, Solid-Tutorial-rdflib.js, Profile-Viewer-Tutorial, Understanding-Linked-Data, Solid-Tutorial-Pastebin, Web-Summit-2018, Intro-to-Solid- Folien, Releases, Solid-Architektur, Benutzerhandbuch, Vokabeln, Solid-Namespace, Solid-Platform, Solid-Spec, Web-Access-Control-Spec, Solid-Apps und Solid.mit.edu
@RubenVerborgh Ja, zusammengeführt, um den Inhalt zu nehmen und ihn in weniger Repos zu einem logisch durchsuchbaren Inhalt zu kombinieren. Der Grund dafür ist, dass Sie als Neuling im Community-Repo landen könnten, um sich zu orientieren und alle Governance-bezogenen Materialien zu finden. Dies wäre eine Orientierung, bevor Sie in die anderen Repos graben (eine Karte wäre hilfreich). Neugierig, Ihre Gedanken zum besten Weg nach vorne zu hören.

Ich denke, dass der Fallback der Project Repository Manager ist.

Sie könnten mich jedoch explizit als Manager für acl-check hinzufügen, da es eindeutig beibehalten wird (es sei denn, @timbl möchte dafür der Repo-Manager sein).

@kjetilk , vorausgesetzt du meinst den Project Release Manager? Eine Alternative zum Ändern der Rollenbeschreibung als Release-Manager als Fallback, wenn kein Repository-Manager vorhanden ist, wäre, Sie als Repository-Manager für alle verbleibenden Repositories aufzuführen. Funktioniert das?

Vielleicht eine Idee, das Gespräch über das Mergen auf einen anderen Pull-Request zu führen.

@megoth möchtest du einige der Repository-Manager-Rollen übernehmen?

Zusammenfassend ist hier der neueste Vorschlag zum Abschluss dieser Ausgabe, die von Tim zusammengeführt werden soll.

mavo-solid, webid-oidc-spec, oidc-auth-manager, solid-multi-rp-client, folder-pane, wac-allow, pane-registry, oidc-rs, keychain, solid-pane, solid-notifications, solid-profile-ui, solid-connections-ui, solid, pane-source, jose, solid-inbox, oidc-op, solid-tif, solid-client, oidc-rp, issue-panes, solid, solid-idp- list, kvplus-files, solid-email, profile-viewer-react, oidc-web, solid-auth-client, solid-sign-up, solid, takeout-import, node-solid-ws, solid-auth-tls, ldflex-Spielplatz, Abfrage-ldflex, Reaktionskomponenten, solid-auth-oidc, Besprechungsbereich, solid-dips, solid-cli, solid-web-client, solid-permissions, acl-check, node-solid-server Repository Manager: @kjetilk

solid-auth-client Repository-Manager: @RubenVerborgh

Community, Solid-Tutorial-Intro, Solid-Tutorial-Winkel, Solid-Tutorial-rdflib.js, Profile-Viewer-Tutorial, Verstehen-verknüpfter-Daten, Solid-Tutorial-Pastebin, Web-Gipfel-2018, Intro-to- solid-slides, releases, solid-architecture, user guide, vocab, solid-namespace, solid-platform, solid-spec, web-access-control-spec, solid-apps und solid.mit.edu Repository-Manager: @Mitzi -Laszlo

solid-panes, solid-ui, mashlib, Repository-Manager: @timbl

Ich denke nur ... gibt es einen bestimmten Grund, warum ich nicht der "Manager" des vocab -Repos bin? Oder allgemeiner gesagt, sollte der Ersteller eines Repos nicht standardmäßig der "Manager" sein (es sei denn, er möchte diese "Rolle" natürlich nicht). Immerhin habe ich das Vocab-Repo vor 3-4 Jahren erstellt und tatsächlich daran und daran gearbeitet.

Ich wäre dafür offen, @timbl wäre die Person, die letztendlich Personen Rollen zuweist

https://github.com/solid/community/issues/32 Ich habe ein paralleles Gespräch über die Informationsstruktur begonnen, das relevant ist, weil Vokabular und solides Wörterbuch sich verdoppeln. @csarven und @RubenVerborgh sind sehr daran interessiert, Ihre Gedanken darüber zu hören, wie wir in dieser Sache vorankommen können.

(Auch https://github.com/solid/community/pull/31 Vorschläge für andere Rollen verflechten sich mit dieser Konversation)

Ich sehe sie nicht als miteinander verflochten. Vokabeln haben, soweit ich das beurteilen kann, einen anderen Zweck als Solid-Wörterbücher. Aber wenn das nicht der Fall ist, warum gibt es überhaupt solid-dictionary? Wäre es nicht besser gewesen, zum Vokabel-Repo beizutragen?

Der Zweck des Vocab-Repos wird vielleicht am besten in diesem Kommentar ausgedrückt: https://github.com/solid/vocab/issues/1#issuecomment -170134584 (zumindest ist das ziemlich nah an dem Grund, warum ich das Repo im ersten erstellt habe Ort). FWIW, zu dieser Zeit verwalteten wir nicht die soliden (RDF-basierten) Vokabulare für die Server und Apps, die wir bauten. Wir brauchten einen Ort, um das, was wir haben und brauchen, besser im Griff zu haben, sowie um einen Konsens zu dokumentieren und zu erreichen.

solid-dictionary scheint eher ein Ort zu sein, an dem Komponenten (z. B. Vokabeln, Protokolle) in der "soliden Welt" verwendet werden oder möglicherweise verwendet werden können. Das ist an und für sich nützlich, aber ich würde sie nicht zusammenführen.

@csarven schrieb:

Ich sehe sie nicht als miteinander verflochten. Vokabeln haben, soweit ich das beurteilen kann, einen anderen Zweck als Solid-Wörterbücher.

Ja, das wäre auch mein Verständnis. Mein Verständnis ist, dass Vocab für RDF ist, solides Wörterbuch ist für Beschreibungen von Begriffen in Prosa, die ausschließlich für den menschlichen Verzehr bestimmt sind.

@Mitzi-Laszlo fragte:

@kjetilk , vorausgesetzt du meinst den Project Release Manager?

Eigentlich dachte ich, dass wir, da wir mit einer einzelnen „Repository Manager“-Rolle begannen und dann Pro-Repo-Rollen bekamen, ein Analogon zum „Project Release Manager“, dh „Project Repositories Manager“, haben würden, das die Verwaltung delegieren würde bestimmter Repositories an andere Personen weitergeben sowie Repositories verwalten, die keine haben.

Wenn es sich hauptsächlich um eine Fallback-Rolle handelt, könnte sie vom Project Release Manager besetzt werden, da zwischen beiden keine wichtigen Checks und Balances stattfinden sollten. Wir überarbeiten die Rollen vielleicht ein bisschen, denke ich, also bin ich offen dafür.

@megoth möchtest du einige der Repository-Manager-Rollen übernehmen?

Ich habe nicht so viel an Repositories außerhalb von node-solid-server gearbeitet, kann also nicht sehen, für welche ich ein Repository-Manager sein sollte. Ich könnte die Verantwortung für einige der Pane-Repositories übernehmen, um @timbl von der Arbeitslast zu entlasten, aber im Allgemeinen denke ich, dass es besser ist, ihn als Repository-Manager für diese zu haben (z. Bereiche, Bereichsquelle, Bereichsregistrierung).

Ich würde auch denken, dass @RubenVerborgh Repository-Manager für die LDflex-bezogenen Projekte sein sollte (dh ldflex-playground und query-ldflex)? Ich würde auch denken, dass er Repository-Manager für Reaktionskomponenten sein sollte?

Ansonsten ist es etwas schwierig, einen Überblick über die Repositories zu bekommen, da es so viele gibt =P Aber andererseits sind diese Rollen nicht in Stein gemeißelt, und wenn wir herausfinden, dass wir früher etwas falsch gemacht haben, sollte es nicht mehr als eine sein bisschen Kommunikation und ein PR weg, um es zu beheben ^_^

Diese brauchen mich als Repo-Manager (ich habe sie vollständig geschrieben):
mavo-fest
wac-zulassen
solid-auth-client
ldflex-spielplatz
Abfrage-ldflex
Reaktionskomponenten
Profil-Betrachter-Reaktion

Ich denke, dieser braucht Tim:
solide

Ist das die Schlussfolgerung, zu der wir gemeinsam gekommen sind?

webid-oidc-spec, oidc-auth-manager, solid-multi-rp-client, folder-pane, pane-registry, oidc-rs, keychain, solid-pane, solid-notifications, solid-profile-ui, solid- connection-ui, solid, pane-source, jose, solid-inbox, oidc-op, solid-tif, solid-client, oidc-rp, issue-panes, solid-idp-list, kvplus-files, solid-email, oidc-web, solid-sign-up, solid, takeout-import, node-solid-ws, solid-auth-tls, solid-auth-oidc, meeting-pane, solid-dips, solid-cli, solid-web- client, solid-permissions, acl-check, node-solid-server Repository-Manager: @kjetilk

solid-auth-client, mavo-solid, wac-allow, solid-auth-client, ldflex-playground, query-ldflex, respond-components, profile-viewer-react Repository-Manager: @RubenVerborgh

Community, Solid-Tutorial-Intro, Solid-Tutorial-Winkel, Solid-Tutorial-rdflib.js, Profile-Viewer-Tutorial, Verstehen-verknüpfter-Daten, Solid-Tutorial-Pastebin, Web-Gipfel-2018, Intro-to- solid-slides, releases, solid-architecture, user guide, solid-namespace, solid-platform, solid-spec, web-access-control-spec, solid-apps und solid.mit.edu Repository-Manager: @Mitzi-Laszlo

Wortschatz @csarven

solid, solid-panes, solid-ui, mashlib, Repository-Manager: @timbl

Praktisch ja, aber ich denke, die meisten Repos, die ich bekomme, dienen nur als Fallback, und die Person mit der Fallback-Rolle sollte auch die Befugnis haben, sie an andere zu delegieren.

Aktualisierte alle Informationen hier https://github.com/solid/community/pull/44 Sie können den Pull-Request gerne weiter kommentieren.