Certo. Agora, temos funções organizacionais que são ocupadas por algumas pessoas e não refletidas em permissões, onde a suposição é que as pessoas não usarão permissões se não tiverem um entendimento com as pessoas com uma função. Portanto, somos bastante liberais com as permissões agora, mas isso, suponho, nos levaria a onde as permissões correspondem às funções, o que provavelmente nos levaria a onde revogamos permissões para pessoas que contribuíram no passado.

Pode ser bom apertar um pouco as coisas, mas não sei se vai ajudar a comunidade. Talvez existam outras maneiras?

Uma maneira de ajudar a comunidade é que as perguntas sejam direcionadas ao
pessoas certas. Muitas vezes sou @-mencionado em coisas fora do meu controle. eu posso suportar
responsabilidade por solid-auth-client, por exemplo, mas não outros.

Acho que vale a pena ressaltar que no rascunho das descrições de funções da comunidade que foi publicado há vários meses, adotamos a abordagem de descrever os principais colaboradores do projeto , os colaboradores do projeto e os gerentes de versão do projeto .

Portanto, temos definições existentes para equipes específicas do projeto (ou seja, node-solid-server, solid-auth-client) para este problema. Eu acho que a falha é que no pull request mais recente não havia contribuidores do projeto nomeados, nem qualquer linguagem sobre por que eles não foram. IMO, devemos pelo menos identificar alguns dos projetos de perfil mais alto (como node-solid-server, solid-auth-client) que estão atualmente sob a organização sólida e fornecer algumas informações sobre os membros da equipe associados.

Na verdade, acho que precisamos definir o que queremos dizer com "projeto", "repositório", etc. Na verdade, não tive o mesmo entendimento, @justinwb , interpretei "Projeto" como uma coisa muito ampla, como em " Solid Project", e também "Repository" como bastante amplo, ou seja, github é um repositório, npm é um repositório.

Agora, temos projetos e repositórios do github, que também usamos operacionalmente, então esses termos não são tão adequados.

Provavelmente também não gostaríamos de ter funções de gerente por repositório ou por pacote, isso seria um gerente com um escopo muito estreito... Acho que é melhor ter "gerenciador de backend", "gerenciador de ferramentas de desenvolvimento", etc. A função de gerenciamento de back-end abrangeria NSS e dependências de projeto sólido, por exemplo.

Ainda acho que poderíamos usar uma função que é uma função operacional do dia-a-dia para garantir a coerência dos lançamentos quando necessário, que é o que eu tenho pensado que "Gerente de Lançamento de Projetos" deveria ser, embora não precisemos ter essas funções. E talvez seja demais para uma única pessoa de qualquer maneira.

Acho que o que tenho desempenhado ultimamente é um papel de "Tech Lead Backend", mas é mais um papel de Inrupt do que de Solid.

Vou apenas trazer uma perspectiva muito estreita, do meu próprio ponto de vista. Eu estou
aquele que atualmente gerencia solid-auth-client. Eu gostaria de clareza tal que
ou as pessoas sabem que é minha responsabilidade, ou que outra pessoa assume
essa responsabilidade; ou seja, prefiro não ter responsabilidades não documentadas,
porque isso pode levar a problemas no futuro.

Por exemplo, quando eu ainda era a pessoa de fato publicando
node-solid-server, outra pessoa assumiu temporariamente essa responsabilidade e
publicou acidentalmente três lançamentos quebrados.

Vamos deixar claro, pelo menos para os repos mais importantes, quem pode
liberar e publicar.

O que você acha da holocracia https://www.holacracy.org para gerenciar o projeto Solid.
Em teoria, ele pode dividir a organização em círculos por grupo de interesse, cada círculo tem uma 'razão de ser que o esclarece, com um 'referente' como 'primeiro elo' papéis e círculos são determinados, e a mutação desses é regulada em função das necessidades.

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

Tenho uma sugestão de como resolver isso..

Aloque os seguintes papéis:

Gerenciador de repositório node-solid-server: @kjetilk
Gerenciador de repositório solid-auth-client: @RubenVerborgh
Community Repository Manager: @Mitzi-Laszlo

@megoth @justinwb e outros, quem seria mais adequado para os seguintes papéis?
Gerenciador de repositório rdflib:
Gerenciador de Repositório de painéis sólidos:
Gerenciador de repositório solid-ui:
Gerenciador de repositório mashlib:

Existem alguns repositórios que eu sinto que se beneficiariam de serem mesclados. Por exemplo: 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 podem ser mesclados com resources.md no repositório da comunidade. Além disso, versões, arquitetura sólida, guia do usuário, vocabulário, namespace sólido, plataforma sólida, especificação sólida, especificação de controle de acesso à web, aplicativos sólidos e solid.mit.edu também podem se fundir à comunidade repo. Talvez existam combinações semelhantes que possam acontecer com outros repositórios?

Se houver duas pessoas trabalhando no mesmo repo, seria uma questão de descobrir quem é o gerente e, portanto, responsável pela supervisão e quem é o principal colaborador.

Os projetos precisam ser definidos no plan.md do repositório da comunidade.

Pensamentos?

Gerenciador de repositório node-solid-server: @kjetilk
Gerenciador de repositório solid-auth-client: @RubenVerborgh
Community Repository Manager: @Mitzi-Laszlo

sim

Gerenciador de repositório rdflib:
Gerenciador de Repositório de painéis sólidos:
Gerenciador de repositório solid-ui:
Gerenciador de repositório mashlib:

Apenas @timbl pode fazer isso, eu acho.

Existem alguns repositórios que eu sinto que se beneficiariam de serem mesclados.

Mesclado? Tipo, torná-los um repositório?
Essa não é uma boa ideia por algumas razões (posso elaborar), mas talvez eu esteja entendendo mal?

Se houver duas pessoas trabalhando no mesmo repo, seria uma questão de descobrir quem é o gerente e, portanto, responsável pela supervisão e quem é o principal colaborador.

Pode haver vários para repositórios mais complexos.

@megoth @justinwb e outros, quem seria mais adequado para os seguintes papéis?
Gerenciador de repositório rdflib:

rdflib está na organização linkeddata no Github , portanto, pode não se enquadrar no trabalho feito como parte da organização sólida no Github. No entanto, é um pacote vital, então podemos pedir às pessoas no linkeddata para formalizar suas funções nesse repositório.

Gerenciador de Repositório de painéis sólidos:
Gerenciador de repositório solid-ui:
Gerenciador de repositório mashlib:

Sim, @timbl é o único que pode fazer isso. Ele pode querer delegar, mas isso é outra discussão.

Ótimo, então um caminho a seguir é apresentar uma sugestão de alocação de funções para Tim da seguinte forma:
Gerenciador de repositório node-solid-server: @kjetilk
Gerenciador de repositório solid-auth-client: @RubenVerborgh
Community Repository Manager: @Mitzi-Laszlo
Gerenciador de repositório de painéis sólidos: @timbl
Gerenciador de repositório solid-ui: @timbl
Gerenciador de repositório mashlib: @timbl
Alguma sugestão adicional? Editar% s?

Quem seria o gerenciador de repositório para cada um dos repositórios não mencionados na lista acima? Ou eles não teriam gerenciador de repositórios? Esses incluem:
mavo-sólido
webid-oidc-spec
oidc-auth-manager
solid-multi-rp-client
painel de pastas
wac-permitir
painel-registro
oidc-rs
chaveiro
painel sólido
notificações sólidas
solid-profile-ui
solid-connections-ui
fonte de painel sólido
Jose
caixa de entrada sólida
oidc-op
solid-tif
cliente sólido
oidc-rp
painéis de problemas
sólido
solid-idp-list
arquivos kvplus
e-mail sólido
perfil-visualizador-reage
oidc-web
solid-auth-client
cadastro sólido
importação sólida para retirada
nó-sólido-ws
solid-auth-tls
ldflex-playground
consulta-ldflex
componentes de reação
solid-auth-oidc
painel de reunião
mergulhos sólidos
solid-cli
solid-web-client
permissões sólidas
acl-check

Os repositórios a seguir também não possuem gerenciador de repositório ainda, porém o conteúdo é mencionado no repositório da comunidade e eles estão relacionados a processos de governança, então eu estaria disposto a me tornar candidato a gerente de repositório para eles.
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, lançamentos, arquitetura sólida, guia do usuário, vocabulário, namespace sólido, plataforma sólida, especificação sólida, especificação de controle de acesso à web, aplicativos sólidos e solid.mit.edu
@RubenVerborgh Sim, mesclado como em pegar o conteúdo e combiná-lo em um conteúdo lógico pesquisável em menos repositórios. A razão é que, como um novato, você pode acessar o repositório da comunidade para orientar e encontrar todo o material relacionado à governança. Esta seria uma orientação antes de explorar os outros repositórios (um mapa seria útil). Curioso para ouvir seus pensamentos sobre o melhor caminho a seguir.

Eu acho que o fallback é o Project Repository Manager.

Você poderia me adicionar explicitamente como gerente para acl-check, pois claramente será mantido (a menos que @timbl queira ser o gerente de repositório para isso).

@kjetilk assumindo que você quer dizer o Gerente de Liberação do Projeto? Uma alternativa para alterar a descrição da função como o gerenciador de versão sendo o fallback quando não há gerenciador de repositório seria listá-lo como o gerenciador de repositório para todos os repositórios restantes. Isso funcionaria?

Talvez uma ideia para levar a conversa sobre a fusão para um pull request diferente.

@megoth você gostaria de assumir algumas das funções de gerenciador de repositório?

Resumindo, aqui está a última proposta para concluir esta questão a ser incorporada pela 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 Repository Gerente: @kjetilk

Gerenciador de repositório 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, releases, solid-architecture, user guide, vocab, solid-namespace, solid-platform, solid-spec, web-access-control-spec, solid-apps e solid.mit.edu Repository Manager: @Mitzi -Laszlo

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

Apenas pensando... existe uma razão particular pela qual eu não sou o "gerente" do vocab ? Ou, mais geralmente, o criador de um repositório não deveria ser o "gerente" por padrão (a menos, é claro, que eles não queiram esse "papel"). Afinal, eu criei o repositório de vocabulário 3-4 anos atrás e trabalhei nele e em torno dele.

Eu estaria aberto a isso, @timbl seria a pessoa que, em última análise, aloca indivíduos para funções

https://github.com/solid/community/issues/32 Comecei uma conversa paralela sobre a estrutura da informação que é relevante porque o vocabulário e o dicionário sólido dobram. @csarven e @RubenVerborgh ansiosos para ouvir seus pensamentos sobre como avançar nisso.

(Além disso, https://github.com/solid/community/pull/31 sugestões para outras funções se entrelaçam com esta conversa)

Não os vejo entrelaçados. vocab tem um propósito diferente do dicionário sólido, tanto quanto posso dizer. Mas se não for esse o caso, por que o dicionário sólido existe para começar? Não teria sido melhor contribuir para o repositório de vocabulário?

O propósito do repositório de vocab talvez seja melhor expresso neste comentário: https://github.com/solid/vocab/issues/1#issuecomment -170134584 (pelo menos isso é bem próximo do motivo pelo qual criei o repositório no primeiro Lugar, colocar). FWIW, naquela época, não estávamos gerenciando os vocabulários sólidos (baseados em RDF) para os servidores e aplicativos que estávamos construindo. Precisávamos de um lugar para ter um melhor controle sobre o que temos e precisávamos.. , bem como para documentar e chegar a algum consenso.

solid-dictionary parece mais um lugar onde componentes (por exemplo, vocabulários, protocolos) são usados ​​ou podem potencialmente ser usados ​​no "mundo sólido". Isso é útil por si só, mas eu não os confundiria.

@csarven escreveu:

Não os vejo entrelaçados. vocab tem um propósito diferente do dicionário sólido, tanto quanto posso dizer.

Sim, esse seria o meu entendimento também. Meu entendimento é que vocab é para RDF, solid-dictionary é para descrições de termos em prosa, puramente destinados ao consumo humano.

@Mitzi-Laszlo perguntou:

@kjetilk assumindo que você quer dizer o Gerente de Liberação do Projeto?

Na verdade, eu estava pensando que desde que começamos com uma única função de "Gerente de Repositório" e depois adquirimos funções por repositório, teríamos um análogo ao "Gerente de Liberação de Projeto", ou seja, "Gerente de Repositório de Projeto", que delegaria o gerenciamento de certos repositórios para outras pessoas, bem como gerenciar repositórios que não possuem um.

Se for principalmente uma função de reserva, pode ser ocupada pelo Gerente de Liberação do Projeto, pois não deve haver verificações e equilíbrios importantes entre os dois. Podemos estar fazendo um pouco de engenharia nos papéis, eu acho, então estou aberto a isso.

@megoth você gostaria de assumir algumas das funções de gerenciador de repositório?

Eu não fiz muito trabalho em repositórios fora do node-solid-server , então não consigo ver para qual eu deveria ser um gerenciador de repositório. Eu posso assumir a responsabilidade por alguns dos repositórios de painel para ajudar a descarregar a carga de trabalho para @timbl , mas em geral acho melhor tê-lo como gerenciador de repositório para eles (ou seja, painel de pasta, painel sólido, problema- painéis, fonte do painel, registro do painel).

Eu também acho que @RubenVerborgh deve ser o gerenciador de repositório para os projetos relacionados ao LDflex (ou seja, ldflex-playground e query-ldflex)? Eu também acho que ele deveria ser o gerenciador de repositório para react-components?

Caso contrário, é um pouco difícil obter uma visão geral dos repositórios, pois existem muitos =P Mas, novamente, esses papéis não são definidos e, se descobrirmos que fizemos algo errado antes, não deve ser mais do que um pouco de comunicação e um PR de distância para corrigi-lo ^_^

Eles precisam de mim como gerente de repo (eu os escrevi completamente):
mavo-sólido
wac-permitir
solid-auth-client
ldflex-playground
consulta-ldflex
componentes de reação
perfil-visualizador-reage

Acho que este precisa de Tim:
sólido

Essa é a conclusão a que chegamos juntos?

webid-oidc-spec, oidc-auth-manager, solid-multi-RP-client, folder-pane, painel-registry, oidc-rs, keychain, solid-pane, solid-notifications, solid-profile-ui, solid- conexões-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 Repository Manager: @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, releases, solid-architecture, user guide, solid-namespace, solid-platform, solid-spec, web-access-control-spec, solid-apps e solid.mit.edu Repository Manager: @Mitzi-Laszlo

vocabulário @csarven

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

Praticamente, sim, mas acho que a maioria dos repositórios que recebo são apenas um substituto, e a pessoa que tem a função de substituto também deve ter autoridade para delegá-los a outras pessoas.

Atualizado todas as informações aqui https://github.com/solid/community/pull/44 fique à vontade para comentar mais sobre o pull request.