Derecha. Ahora, tenemos roles organizacionales que están ocupados por unas pocas personas y no se reflejan en los permisos, donde se supone que las personas no van a usar los permisos si no tienen un entendimiento con las personas con un rol. Entonces, somos bastante liberales con los permisos ahora, pero supongo que esto nos llevaría a donde los permisos coinciden con los roles, lo que nuevamente probablemente nos llevaría a donde revocamos los permisos para las personas que han contribuido en el pasado.

Podría ser bueno ajustar un poco las cosas, pero no sé si ayudará a la comunidad. ¿Quizás hay otras formas?

Una forma en que ayudará a la comunidad es que las preguntas estén dirigidas a los
La gente correcta. A menudo me @mencionan en cosas que están fuera de mi control. puedo soportar
responsabilidad de solid-auth-client, por ejemplo, pero no de otros.

Creo que vale la pena señalar que en el borrador de las descripciones de roles de la comunidad que se publicó hace varios meses, adoptamos el enfoque de describir a los Colaboradores principales del proyecto, los Colaboradores del proyecto y los Gerentes de lanzamiento del proyecto.

Por lo tanto, tenemos definiciones existentes para equipos específicos del proyecto (es decir, nodo-servidor sólido, cliente de autenticación sólido) según este problema. Creo que la deficiencia es que en la solicitud de extracción más reciente no se nombraron colaboradores del proyecto, ni se mencionó por qué no lo fueron. En mi opinión, al menos deberíamos identificar algunos de los proyectos de perfil más alto (como node-solid-server, solid-auth-client) que se encuentran actualmente en la organización sólida y proporcionar información sobre los miembros del equipo asociados allí.

En realidad, creo que debemos definir qué entendemos por "proyecto", "repositorio", etc. En realidad, no entendí lo mismo, @justinwb , interpreté "Proyecto" como algo muy amplio, como en " Solid Project", y también "Repositorio" como bastante amplio, es decir, github es un repositorio, npm es un repositorio.

Ahora, tenemos proyectos y repositorios de github, que también usamos operativamente, por lo que estos términos no son tan adecuados.

Probablemente tampoco querríamos tener roles de administrador por repositorio o por paquete, sería un administrador con un alcance muy limitado... Creo que es mejor tener "administrador de back-end", "administrador de herramientas de desarrollo", etc. La función de administración de back-end abarcaría NSS y dependencias de proyectos sólidos, por ejemplo.

Sigo pensando que podríamos usar un rol que sea un rol operativo diario para garantizar la coherencia de los lanzamientos cuando sea necesario, que es lo que he estado pensando que debería ser "Project Release Manager", aunque no hemos necesitado tener esas funciones. Y tal vez sea demasiado para una sola persona de todos modos.

Creo que lo que he estado desempeñando últimamente es un rol de "Tech Lead Backend", pero es más un rol de Inrupt que un rol de Solid.

Solo traeré una perspectiva muy estrecha, desde mi propio punto de vista. Yo soy
el que actualmente administra solid-auth-client. Quisiera una claridad tal que
o la gente sabe que es mi responsabilidad, o que alguien más toma
esa responsabilidad; es decir, prefiero no tener responsabilidades indocumentadas,
porque eso podría conducir a problemas en el futuro.

Por ejemplo, cuando todavía era la persona de facto que publicaba
nodo-sólido-servidor, otra persona asumió temporalmente esa responsabilidad y
publicó accidentalmente tres comunicados incompletos.

Dejemos claro, al menos para los repositorios más importantes, quién puede
liberar y publicar.

¿Qué opinas sobre la holocracia https://www.holacracy.org para gestionar el proyecto Solid?
En teoría, se puede dividir la organización en círculos por grupo de interés, cada círculo tiene una 'razón de ser' que lo aclara, con un 'referente' como 'primer eslabón' se determinan roles y círculos, y se regula la mutación de estos en función. de las necesidades

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

Tengo una sugerencia sobre cómo resolver esto ...

Asigne los siguientes roles:

Administrador de repositorio de node-solid-server: @kjetilk
Administrador de repositorio solid-auth-client: @RubenVerborgh
Gerente de repositorio de la comunidad: @Mitzi-Laszlo

@megoth @justinwb y otros, ¿quién sería el más adecuado para los siguientes roles?
Administrador de repositorios rdflib:
Administrador de repositorio de paneles sólidos:
Administrador de repositorio solid-ui:
Administrador de repositorio mashlib:

Hay algunos repositorios que creo que se beneficiarían de la fusión. Por ejemplo: solid-tutorial-intro, solid-tutorial-angular, solid-tutorial-rdflib.js, profile-viewer-tutorial, listening-linked-data, solid-tutorial-pastebin, web-summit-2018, intro-to -las diapositivas sólidas podrían fusionarse con resources.md en el repositorio de la comunidad. Además, los lanzamientos, la arquitectura sólida, la guía del usuario, el vocabulario, el espacio de nombres sólido, la plataforma sólida, las especificaciones sólidas, las especificaciones de control de acceso web, las aplicaciones sólidas y solid.mit.edu también podrían fusionarse potencialmente en la comunidad. repositorio ¿Quizás hay combinaciones similares que podrían ocurrir con otros repositorios?

Si hay dos personas trabajando en el mismo repositorio, sería cuestión de averiguar quién es el administrador y, por lo tanto, responsable de la supervisión y quién es el contribuyente principal.

Los proyectos deben definirse en el plan.md del repositorio de la comunidad.

¿Pensamientos?

Administrador de repositorio de node-solid-server: @kjetilk
Administrador de repositorio solid-auth-client: @RubenVerborgh
Gerente de repositorio de la comunidad: @Mitzi-Laszlo

sí

Administrador de repositorios rdflib:
Administrador de repositorio de paneles sólidos:
Administrador de repositorio solid-ui:
Administrador de repositorio mashlib:

Solo @timbl puede hacer esto, creo.

Hay algunos repositorios que creo que se beneficiarían de la fusión.

fusionado? Como en, ¿hacerlos un repositorio?
Esa no es una buena idea por un par de razones (puedo dar más detalles), pero tal vez estoy malinterpretando.

Si hay dos personas trabajando en el mismo repositorio, sería cuestión de averiguar quién es el administrador y, por lo tanto, responsable de la supervisión y quién es el contribuyente principal.

Podría haber múltiples para repositorios más complejos.

@megoth @justinwb y otros, ¿quién sería el más adecuado para los siguientes roles?
Administrador de repositorios rdflib:

rdflib está en la organización de datos vinculados en Github , por lo que es posible que no se incluya en el trabajo realizado como parte de una organización sólida en Github. Sin embargo, es un paquete vital, por lo que podríamos pedirle a la gente de linkeddata que formalice sus roles en ese repositorio.

Administrador de repositorio de paneles sólidos:
Administrador de repositorio solid-ui:
Administrador de repositorio mashlib:

Sí, @timbl es el único que puede hacer esto. Puede que quiera delegar, pero esa es otra discusión.

Genial, entonces un camino a seguir es presentar una sugerencia de asignación de roles a Tim de la siguiente manera:
Administrador de repositorio de node-solid-server: @kjetilk
Administrador de repositorio solid-auth-client: @RubenVerborgh
Gerente de repositorio de la comunidad: @Mitzi-Laszlo
Administrador de repositorio de paneles sólidos: @timbl
Administrador de repositorio solid-ui: @timbl
Administrador de repositorio mashlib: @timbl
¿Alguna sugerencia adicional? ediciones?

¿Quién sería el administrador del repositorio para cada uno de los repositorios no mencionados en la lista anterior? ¿O no tendrían administrador de repositorio? Éstos incluyen:
mavo-sólido
webid-oidc-spec
oidc-auth-manager
sólido-multi-rp-cliente
panel de carpetas
WAC-permitir
panel-registro
oidc-rs
llavero
panel sólido
notificaciones sólidas
interfaz de usuario de perfil sólido
conexiones-sólidas-ui
fuente de panel sólido
José
bandeja de entrada sólida
oidc-op
sólido-tif
cliente sólido
oidc-rp
paneles de problemas
sólido
sólido-idp-lista
archivos kvplus
correo electrónico sólido
perfil-visor-reaccionar
oidc-web
sólido-autorización-cliente
registro sólido
sólido-para-llevar-importación
nodo-sólido-ws
sólido-autorización-TLS
ldflex-patio de recreo
consulta-ldflex
componentes de reacción
solid-auth-oidc
panel de reunión
inmersiones sólidas
sólido-cli
sólido-web-cliente
permisos sólidos
verificación de ACL

Los siguientes repositorios tampoco tienen un administrador de repositorios hasta el momento, sin embargo, el contenido se menciona en el repositorio de la comunidad y están relacionados con los procesos de gobierno, por lo que estaría dispuesto a convertirme en candidato a administrador de repositorios para ellos.
solid-tutorial-intro, solid-tutorial-angular, solid-tutorial-rdflib.js, profile-viewer-tutorial, comprensión-de-datos vinculados, solid-tutorial-pastebin, web-summit-2018, intro-to-solid- diapositivas, lanzamientos, arquitectura sólida, guía del usuario, vocabulario, espacio de nombres sólido, plataforma sólida, especificación sólida, especificación de control de acceso web, aplicaciones sólidas y solid.mit.edu
@RubenVerborgh Sí, combinado como en tomar el contenido y combinarlo en un contenido de búsqueda lógico en menos repositorios. La razón es que, como novato, puede aterrizar en el repositorio de la comunidad para orientarse y encontrar todo el material relacionado con la gobernanza. Esta sería una orientación antes de profundizar en los otros repositorios (un mapa sería útil). Curiosidad por escuchar sus pensamientos sobre el mejor camino a seguir.

Creo que la alternativa es el Project Repository Manager.

Sin embargo, podría agregarme explícitamente como administrador de acl-check, ya que claramente se mantendrá (a menos que @timbl quiera ser el administrador de repositorios para eso).

@kjetilk suponiendo que te refieres al Project Release Manager? Una alternativa a cambiar la descripción de la función como administrador de versiones, que es el respaldo cuando no hay un administrador de repositorio, sería incluirlo como administrador de repositorio para todos los repositorios restantes. Funcionaría eso?

Tal vez una idea para llevar la conversación sobre la fusión a una solicitud de extracción diferente.

@megoth , ¿le gustaría asumir algunos de los roles de administrador del repositorio?

Resumiendo, aquí está la última propuesta para concluir este tema que será fusionada por Tim.

mavo-solid, webid-oidc-spec, oidc-auth-manager, solid-multi-rp-client, panel de carpetas, wac-allow, panel-registry, oidc-rs, llavero, panel sólido, notificaciones sólidas, solid-profile-ui, solid-connections-ui, solid, panel-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 Repositorio Gerente: @kjetilk

Administrador de repositorio solid-auth-client: @RubenVerborgh

comunidad, solid-tutorial-intro, solid-tutorial-angular, solid-tutorial-rdflib.js, profile-viewer-tutorial, comprensión-de-datos vinculados, solid-tutorial-pastebin, web-summit-2018, intro-to- solid-slides, releases, solid-architecture, guía del usuario, vocabulario, solid-namespace, solid-platform, solid-spec, web-access-control-spec, solid-apps y solid.mit.edu Administrador del repositorio: @Mitzi -Laszlo

solid-panes, solid-ui, mashlib, administrador de repositorio: @timbl

Solo pensando... ¿hay alguna razón en particular por la que no soy el "administrador" del repositorio vocab ? O, de manera más general, el creador de un repositorio no debería ser el "administrador" de forma predeterminada (a menos, por supuesto, que no quieran ese "rol"). Después de todo, creé el repositorio de vocabulario hace 3 o 4 años, y realmente he trabajado en él y en torno a él.

Estaría abierto a eso, @timbl sería la persona que finalmente asigna a las personas a los roles.

https://github.com/solid/community/issues/32 Comencé una conversación paralela sobre la estructura de la información que es relevante porque el vocabulario y el diccionario sólido se duplican. @csarven y @RubenVerborgh ansiosos por escuchar sus pensamientos sobre cómo avanzar en esto.

(Además, https://github.com/solid/community/pull/31 sugerencias para otros roles se entrelazan con esta conversación)

No los veo entrelazados. vocab tiene un propósito diferente al de solid-dictionary por lo que puedo decir. Pero si ese no es el caso, ¿por qué existe un diccionario sólido para empezar? ¿No hubiera sido mejor contribuir al repositorio de vocabulario?

El propósito del repositorio de vocabulario quizás se exprese mejor en este comentario: https://github.com/solid/vocab/issues/1#issuecomment -170134584 (al menos eso es bastante parecido a la razón por la que creé el repositorio en la primera lugar). FWIW, en ese momento, no estábamos administrando los vocabularios sólidos (basados ​​en RDF) para los servidores y las aplicaciones que estábamos creando. Necesitábamos un lugar para tener un mejor manejo de lo que tenemos y necesitábamos... , así como para documentar y llegar a algún consenso.

solid-dictionary parece más un lugar donde los componentes (por ejemplo, vocabularios, protocolos) se usan o se pueden usar potencialmente en el "mundo sólido". Eso es útil en sí mismo, pero no los confundiría.

@csarven escribió:

No los veo entrelazados. vocab tiene un propósito diferente al de solid-dictionary por lo que puedo decir.

Sí, ese sería mi entendimiento también. Tengo entendido que el vocabulario es para RDF, el diccionario sólido es para descripciones de términos en prosa, destinados exclusivamente al consumo humano.

@Mitzi-Laszlo preguntó:

@kjetilk suponiendo que te refieres al Project Release Manager?

En realidad, estaba pensando que dado que comenzamos con un solo rol de "Administrador de repositorios" y luego obtuvimos roles por repositorio, tendríamos un análogo al "Administrador de versiones de proyectos", es decir, "Administrador de repositorios de proyectos", que delegaría la administración de ciertos repositorios a otras personas, así como administrar repositorios que no tienen uno.

Si se trata principalmente de un rol alternativo, podría ser ocupado por el Gerente de lanzamiento del proyecto, ya que no debería haber controles ni equilibrios importantes entre los dos. Quizás estemos sobredimensionando un poco los roles, supongo, así que estoy abierto a eso.

@megoth , ¿le gustaría asumir algunos de los roles de administrador del repositorio?

No he trabajado tanto en repositorios fuera de node-solid-server , por lo que no puedo ver para cuál debo ser un administrador de repositorio. Podría asumir la responsabilidad de algunos de los repositorios de paneles para ayudar a descargar la carga de trabajo de @timbl , pero en general creo que es mejor tenerlo como administrador de repositorios para esos (es decir, panel de carpetas, panel sólido, problema- paneles, panel-fuente, panel-registro).

También creo que @RubenVerborgh debería ser el administrador del repositorio para los proyectos relacionados con LDflex (es decir, ldflex-playground y query-ldflex). ¿También pensaría que debería ser administrador de repositorio para componentes de reacción?

De lo contrario, es un poco difícil obtener una descripción general de los repositorios, ya que hay tantos =P Pero, de nuevo, estos roles no están escritos en piedra, y si descubrimos que hicimos algo mal antes, no debería ser más que un un poco de comunicación y relaciones públicas para arreglarlo ^_^

Estos me necesitan como administrador de repositorios (los escribí completamente):
mavo-sólido
WAC-permitir
sólido-autorización-cliente
ldflex-patio de recreo
consulta-ldflex
componentes de reacción
perfil-visor-reaccionar

Creo que este necesita a Tim:
sólido

¿Es esta la conclusión a la que hemos llegado juntos?

webid-oidc-spec, oidc-auth-manager, solid-multi-rp-client, carpeta-panel, panel-registro, oidc-rs, llavero, panel sólido, notificaciones sólidas, perfil sólido-ui, sólido- conexiones-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, panel de reunión, solid-dips, solid-cli, solid-web- cliente, permisos sólidos, verificación de acl, nodo-servidor sólido Administrador de repositorio: @kjetilk

solid-auth-client, mavo-solid, wac-allow, solid-auth-client, ldflex-playground, query-ldflex, react-components, profile-viewer-react Administrador de repositorio: @RubenVerborgh

comunidad, solid-tutorial-intro, solid-tutorial-angular, solid-tutorial-rdflib.js, profile-viewer-tutorial, comprensión-de-datos vinculados, solid-tutorial-pastebin, web-summit-2018, intro-to- solid-slides, releases, solid-architecture, guía del usuario, solid-namespace, solid-platform, solid-spec, web-access-control-spec, solid-apps y solid.mit.edu Administrador del repositorio: @Mitzi-Laszlo

vocabulario @csarven

solid, solid-panes, solid-ui, mashlib, Administrador de repositorio: @timbl

En la práctica, sí, pero creo que la mayoría de los repositorios que obtengo son solo como respaldo, y la persona que tiene el rol de respaldo también debería tener la autoridad para delegarlos a otros.

Se actualizó toda la información aquí https://github.com/solid/community/pull/44 Siéntase libre de comentar más sobre la solicitud de extracción.