Droit. Maintenant, nous avons des rôles organisationnels qui sont occupés par quelques personnes, et non reflétés dans les autorisations, où l'hypothèse est que les gens n'utiliseront pas les autorisations s'ils n'ont pas une entente avec les personnes ayant un rôle. Donc, nous sommes assez libéraux avec les autorisations maintenant, mais cela, je suppose, nous conduirait là où les autorisations correspondent aux rôles, ce qui nous amènerait probablement là où nous révoquons les autorisations pour les personnes qui ont contribué dans le passé.

Ce serait peut-être une bonne chose de resserrer un peu les choses, mais je ne sais pas si cela aidera la communauté. Peut-être existe-t-il d'autres moyens ?

Une façon d'aider la communauté est que les questions ciblent les
les bonnes personnes. Je suis souvent @-mentionné dans des choses hors de mon contrôle. Je peux supporter
responsabilité pour solid-auth-client, par exemple, mais pas pour les autres.

Je pense qu'il vaut la peine de souligner que dans l'ébauche des descriptions de rôle de la communauté qui a été publiée il y a plusieurs mois, nous avons adopté l'approche de décrire Project Core Contributors , Project Contributors et Project Release Managers .

Nous avons donc des définitions existantes pour les équipes spécifiques au projet (c'est-à-dire nœud-solide-serveur, solide-auth-client) pour ce problème. Je pense que la lacune est que dans la demande d'extraction la plus récente, aucun contributeur de projet n'a été nommé, ni aucun langage expliquant pourquoi ils ne l'étaient pas. IMO, nous devrions au moins identifier certains des projets les plus médiatisés (comme node-solid-server, solid-auth-client) qui sont actuellement sous l'organisation solide et fournir des informations sur les membres de l'équipe qui y sont associés.

En fait, je pense que nous devons définir ce que nous entendons par "projet", "dépôt", etc. En fait, je n'avais pas la même compréhension, @justinwb , j'ai interprété "Projet" comme une chose très large, comme dans " Solid Project", et aussi "Repository" comme assez large, c'est-à-dire que github est un référentiel, npm est un référentiel.

Maintenant, nous avons des projets et des référentiels github, que nous utilisons également de manière opérationnelle, donc ces termes ne sont pas vraiment adaptés.

Nous ne voudrions probablement pas non plus avoir des rôles de gestionnaire par dépôt ou par paquet, ce serait un gestionnaire avec une portée très étroite... Je pense qu'il est préférable d'avoir "gestionnaire de backend", "gestionnaire d'outils de développement", etc. Le rôle de gestion backend engloberait NSS et les dépendances de projets solides, par exemple.

Je pense toujours que nous pourrions utiliser un rôle qui est un rôle opérationnel au jour le jour pour assurer la cohérence des versions là où cela est nécessaire, ce que je pensais que "Project Release Manager" devrait être, même si nous n'avons pas eu besoin avoir ces fonctions. Et c'est peut-être trop pour une seule personne de toute façon.

Je pense que ce que j'ai effectué ces derniers temps est un rôle "Tech Lead Backend", mais c'est plus un rôle Inrupt qu'un rôle Solid.

J'apporterai juste une perspective très étroite, de mon propre point de vue. je suis
celui qui gère actuellement solid-auth-client. Je voudrais une clarté telle que
soit les gens savent que c'est ma responsabilité, soit que quelqu'un d'autre prend
cette responsabilité ; c'est-à-dire que je préfère ne pas avoir de responsabilités sans papiers,
car cela pourrait entraîner des problèmes à l'avenir.

Par exemple, lorsque j'étais encore la personne de facto qui publiait
node-solid-server, quelqu'un d'autre a temporairement assumé cette responsabilité et
accidentellement publié trois versions cassées.

Soyons clairs, au moins pour les pensions les plus importantes, qui peut
libérer et publier.

Que pensez-vous de l'holacracy https://www.holacracy.org pour la gestion du projet Solid.
En théorie, il peut scinder l'organisation en cercles par groupe d'intérêt, chaque cercle a une 'raison d'être qui le précise, avec un 'référent' comme 'premier maillon' les rôles et les cercles sont déterminés, et la mutation de ceux-ci est réglée en fonction des besoins.

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

J'ai une suggestion sur la façon de résoudre ce problème..

Attribuez les rôles suivants :

Gestionnaire de référentiel node-solid-server : @kjetilk
Responsable du référentiel solid-auth-client : @RubenVerborgh
Responsable du référentiel communautaire : @Mitzi-Laszlo

@megoth @justinwb et autres, qui serait le mieux adapté aux rôles suivants ?
Gestionnaire de référentiel rdflib :
Gestionnaire de référentiel à panneaux pleins :
Gestionnaire de référentiel solid-ui :
Gestionnaire de référentiel mashlib :

Il y a certains référentiels qui, à mon avis, gagneraient à être fusionnés. Par exemple : 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 pourrait tous fusionner avec resources.md dans le dépôt de la communauté. De plus, les versions, l'architecture solide, le guide de l'utilisateur, le vocabulaire, l'espace de noms solide, la plate-forme solide, la spécification solide, la spécification de contrôle d'accès Web, les applications solides et solid.mit.edu pourraient également fusionner dans la communauté. dépôt. Peut-être y a-t-il des combinaisons similaires qui pourraient se produire avec d'autres repos ?

S'il y a deux personnes travaillant sur le même référentiel, il s'agirait de déterminer qui est le gestionnaire et donc responsable de la surveillance et qui est le principal contributeur.

Les projets doivent être définis dans le plan.md du référentiel communautaire.

Les pensées?

Gestionnaire de référentiel node-solid-server : @kjetilk
Responsable du référentiel solid-auth-client : @RubenVerborgh
Responsable du référentiel communautaire : @Mitzi-Laszlo

Oui

Gestionnaire de référentiel rdflib :
Gestionnaire de référentiel à panneaux pleins :
Gestionnaire de référentiel solid-ui :
Gestionnaire de référentiel mashlib :

Seul @timbl peut le faire je pense.

Il y a certains référentiels qui, à mon avis, gagneraient à être fusionnés.

Fusionné? Comme dans, en faire un référentiel ?
Ce n'est pas une bonne idée pour plusieurs raisons (je peux élaborer), mais peut-être ai-je mal compris?

S'il y a deux personnes travaillant sur le même référentiel, il s'agirait de déterminer qui est le gestionnaire et donc responsable de la surveillance et qui est le principal contributeur.

Il pourrait y en avoir plusieurs pour des dépôts plus complexes.

@megoth @justinwb et autres, qui serait le mieux adapté aux rôles suivants ?
Gestionnaire de référentiel rdflib :

rdflib est dans l'organisation linkeddata sur Github , il se peut donc qu'il ne relève pas du travail effectué dans le cadre d'une organisation solide sur Github. Il s'agit cependant d'un package vital, nous pourrions donc demander aux personnes de linkeddata de formaliser leurs rôles dans ce référentiel.

Gestionnaire de référentiel à panneaux pleins :
Gestionnaire de référentiel solid-ui :
Gestionnaire de référentiel mashlib :

Oui, @timbl est le seul à pouvoir le faire. Il voudra peut-être déléguer, mais c'est une autre discussion.

Génial, donc une voie à suivre consiste à proposer une suggestion d'attribution de rôles à Tim comme suit :
Gestionnaire de référentiel node-solid-server : @kjetilk
Responsable du référentiel solid-auth-client : @RubenVerborgh
Responsable du référentiel communautaire : @Mitzi-Laszlo
Gestionnaire de dépôt à panneaux pleins : @timbl
Responsable du référentiel solid-ui : @timbl
Responsable du référentiel mashlib : @timbl
Des suggestions supplémentaires ? modifications ?

Qui serait le gestionnaire de référentiel pour chacun des référentiels non mentionnés dans la liste ci-dessus ? Ou n'auraient-ils pas de gestionnaire de référentiel ? Ceux-ci inclus:
mavo-solide
webid-oidc-spec
oidc-auth-manager
client solide multi-rp
dossier-volet
wac-autoriser
volet-registre
oidc-rs
porte-clés
vitre pleine
notifications solides
solide-profil-ui
solid-connections-ui
source à panneau plein
José
boîte de réception solide
oidc-op
solide-tif
client solide
oidc-rp
volets-problèmes
solide
solide-idp-list
fichiers-kvplus
email solide
profile-viewer-react
oidc-web
client d'authentification solide
inscription solide
importation solide à emporter
nœud-solide-ws
solide-auth-tls
ldflex-aire de jeux
requête-ldflex
composants de réaction
solide-auth-oidc
volet de réunion
trempettes solides
solide-cli
client-web solide
autorisations solides
ACL-vérifier

Les référentiels suivants n'ont pas encore de gestionnaire de référentiel pour le moment, mais le contenu est mentionné dans le référentiel communautaire et ils sont liés aux processus de gouvernance, donc je serais prêt à devenir candidat gestionnaire de référentiel pour eux.
solide-tutoriel-intro, solide-tutoriel-angular, solide-tutoriel-rdflib.js, profile-viewer-tutorial, compréhension-lié-données, solide-tutoriel-pastebin, web-summit-2018, intro-to-solid- diapositives, versions, solid-architecture, guide de l'utilisateur, vocabulaire, solid-namespace, solid-platform, solid-spec, web-access-control-spec, solid-apps et solid.mit.edu
@RubenVerborgh Oui, fusionné comme dans prendre le contenu et les combiner en un contenu logique interrogeable en moins de repos. La raison étant qu'en tant que débutant, vous pouvez atterrir sur le référentiel communautaire pour vous orienter et trouver tout le matériel lié à la gouvernance. Ce serait une orientation avant de creuser dans les autres dépôts (une carte serait utile). Curieux d'entendre vos réflexions sur la meilleure façon d'avancer.

Je pense que la solution de repli est le Project Repository Manager.

Vous pouvez cependant m'ajouter explicitement en tant que responsable pour acl-check, car il va clairement être maintenu (à moins que @timbl ne veuille être le responsable du dépôt pour cela).

@kjetilk en supposant que vous vouliez dire le Project Release Manager ? Une alternative à la modification de la description du rôle en tant que gestionnaire de version étant la solution de repli lorsqu'il n'y a pas de gestionnaire de référentiel serait de vous répertorier en tant que gestionnaire de référentiel pour tous les référentiels restants. Est-ce que ça marcherait ?

Peut-être une idée de prendre la conversation sur la fusion vers une demande de tirage différente.

@megoth aimeriez -vous assumer certains des rôles de gestionnaire de référentiel ?

En résumé, voici la dernière proposition pour conclure ce numéro à fusionner par Tim.

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-playground, query-ldflex, react-components, solid-auth-oidc, meeting-pane, solid-dips, solid-cli, solid-web-client, solid-permissions, acl-check, node-solid-server Responsable : @kjetilk

Responsable du référentiel solid-auth-client : @RubenVerborgh

community, 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, versions, solid-architecture, guide de l'utilisateur, vocabulaire, solid-namespace, solid-platform, solid-spec, web-access-control-spec, solid-apps et solid.mit.edu Repository Manager : @Mitzi -Laszlo

solid-panes, solid-ui, mashlib, gestionnaire de référentiel : @timbl

Juste en pensant... y a-t-il une raison particulière pour laquelle je ne suis pas le "gestionnaire" du repo vocab ? Ou plus généralement, le créateur d'un dépôt ne devrait-il pas être le "gestionnaire" par défaut (à moins bien sûr qu'il ne veuille pas ce "rôle"). Après tout, j'ai créé le dépôt de vocabulaire il y a 3-4 ans et j'ai travaillé dessus et autour de lui.

Je serais ouvert à cela, @timbl serait la personne qui, en fin de compte, attribue des rôles aux individus

https://github.com/solid/community/issues/32 J'ai entamé une conversation parallèle sur la structure de l'information qui est pertinente car le vocabulaire et le dictionnaire solide se doublent. @csarven et @RubenVerborgh désireux d'entendre vos réflexions sur la façon d'aller de l'avant à ce sujet.

(De plus, https://github.com/solid/community/pull/31 suggestions pour d'autres rôles s'entremêlent avec cette conversation)

Je ne les vois pas comme liés. vocab a un objectif différent de solid-dictionary pour autant que je sache. Mais si ce n'est pas le cas, pourquoi le dictionnaire solide existe-t-il pour commencer ? N'aurait-il pas été préférable de contribuer au dépôt de vocabulaire ?

Le but du dépôt de vocabulaire est peut-être mieux exprimé dans ce commentaire : https://github.com/solid/vocab/issues/1#issuecomment -170134584 (du moins c'est assez proche de la raison pour laquelle j'ai créé le dépôt dans le premier lieu). FWIW, à cette époque, nous ne gérions pas les vocabulaires solides (basés sur RDF) pour les serveurs et les applications que nous construisions. Nous avions besoin d'un endroit pour avoir une meilleure idée de ce que nous avons et de ce dont nous avions besoin, ainsi que pour documenter et parvenir à un consensus.

solid-dictionary ressemble plus à un endroit où des composants (par exemple des vocabulaires, des protocoles) sont utilisés ou peuvent potentiellement être utilisés dans le "monde solide". C'est utile en soi, mais je ne les confondrais pas.

@csarven a écrit :

Je ne les vois pas comme liés. vocab a un objectif différent de solid-dictionary pour autant que je sache.

Ouais, ce serait ma compréhension aussi. Ma compréhension est que vocab est pour RDF, solid-dictionary est pour les descriptions de termes en prosa, purement destinés à la consommation humaine.

@Mitzi-Laszlo a demandé :

@kjetilk en supposant que vous vouliez dire le Project Release Manager ?

En fait, je pensais que puisque nous avons commencé avec un seul rôle "Repository Manager" et ensuite obtenu des rôles par dépôt, nous aurions un analogue au "Project Release Manager", c'est-à-dire "Project Repositories Manager", qui déléguerait la gestion de certains référentiels à d'autres personnes ainsi que la gestion des référentiels qui n'en ont pas.

S'il s'agit principalement d'un rôle de secours, il pourrait être occupé par le Project Release Manager, car il ne devrait pas y avoir de freins et contrepoids importants entre les deux. Nous sur-concevons peut-être un peu les rôles, je suppose, donc je suis ouvert à cela.

@megoth aimeriez -vous assumer certains des rôles de gestionnaire de référentiel ?

Je n'ai pas beaucoup travaillé sur les référentiels en dehors de node-solid-server , donc je ne vois pas pour lequel je devrais être un gestionnaire de référentiel. Je pourrais assumer la responsabilité de certains des référentiels de volets pour aider à décharger la charge de travail de @timbl , mais en général, je pense qu'il est préférable de l'avoir comme gestionnaire de référentiels pour ceux-ci (c'est-à-dire volet de dossiers, volet solide, problème- volets, volet-source, volet-registre).

Je pense également que @RubenVerborgh devrait être le gestionnaire de référentiel pour les projets liés à LDflex (c'est-à-dire ldflex-playground et query-ldflex) ? Je penserais aussi qu'il devrait être gestionnaire de référentiel pour les composants de réaction?

Sinon, il est un peu difficile d'avoir une vue d'ensemble des référentiels, car il y a tellement de =P Mais encore une fois, ces rôles ne sont pas gravés dans le marbre, et si nous découvrons que nous avons fait quelque chose de mal plus tôt, cela ne devrait pas être plus d'un peu de communication et un PR loin pour le réparer ^ _ ^

Ceux-ci ont besoin de moi en tant que gestionnaire de dépôt (je les ai entièrement écrits):
mavo-solide
wac-autoriser
client d'authentification solide
ldflex-aire de jeux
requête-ldflex
composants de réaction
profile-viewer-react

Je pense que celui-ci a besoin de Tim :
solide

Est-ce la conclusion à laquelle nous sommes parvenus ensemble ?

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- connections-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, react-components, profile-viewer-react Gestionnaire de référentiel : @RubenVerborgh

community, 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, versions, solid-architecture, guide de l'utilisateur, solid-namespace, solid-platform, solid-spec, web-access-control-spec, solid-apps et solid.mit.edu Repository Manager : @Mitzi-Laszlo

vocabulaire @csarven

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

Pratiquement, oui, mais je pense que la plupart des dépôts que je reçois sont simplement une solution de secours, et la personne ayant le rôle de solution de secours devrait également avoir le pouvoir de les déléguer à d'autres.

Mise à jour de toutes les informations ici https://github.com/solid/community/pull/44 n'hésitez pas à commenter davantage la demande de tirage.