Верно. Теперь у нас есть организационные роли, которые заняты несколькими людьми и не отражены в разрешениях, где предполагается, что люди не будут использовать разрешения, если у них нет понимания с людьми с ролью. Итак, сейчас мы довольно либерально относимся к разрешениям, но я предполагаю, что это приведет нас к тому, что разрешения будут соответствовать ролям, что снова, вероятно, приведет нас к тому, что мы отзовем разрешения для людей, которые внесли свой вклад в прошлом.

Возможно, было бы неплохо немного ужесточить ситуацию, но я не знаю, поможет ли это сообществу. Возможно, есть другие способы?

Один из способов помочь сообществу состоит в том, что вопросы адресованы
правильные люди. Меня часто @-упоминают в вещах, не зависящих от меня. я могу вынести
например, ответственность за solid-auth-client, но не за других.

Я думаю, стоит отметить, что в черновике описания ролей сообщества, который был опубликован несколько месяцев назад, мы использовали подход к описанию основных участников проекта , участников проекта и менеджеров релизов проекта .

Итак, у нас есть существующие определения для конкретных команд проекта (т.е. node-solid-server, solid-auth-client) для этой проблемы. Я думаю, что недостатком является то, что в самом последнем пулл-реквесте не были названы участники проекта, и не было никаких слов о том, почему они не были. ИМО, мы должны, по крайней мере, определить некоторые из проектов с более высоким профилем (например, node-solid-server, solid-auth-client), которые в настоящее время находятся в солидной организации, и предоставить некоторое представление о связанных с ними членах команды.

На самом деле, я думаю, нам нужно определить, что мы подразумеваем под «проектом», «репозиторием» и т. д. На самом деле, у меня не было такого понимания, @justinwb , я интерпретировал «Проект» как очень широкое понятие, как в « Solid Project», а также «Репозиторий» как довольно широкое, т.е. github — это репозиторий, npm — это репозиторий.

Теперь у нас есть проекты и репозитории github, которые мы также используем в работе, поэтому эти термины не очень подходят.

Мы, вероятно, не хотели бы иметь роли менеджера для каждого репо или для каждого пакета, это был бы менеджер с очень узкой областью... Я думаю, что лучше иметь «менеджер бэкэнда», «менеджер инструментов разработки», и т. д. Роль управления бэкэндом будет охватывать, например, NSS и солидные зависимости проекта.

Я все еще думаю, что мы могли бы использовать роль, которая является повседневной операционной ролью, чтобы обеспечить согласованность релизов там, где это необходимо, хотя я думал, что это то, чем должен быть «Менеджер релизов проекта», хотя нам это не нужно иметь эти функции. И, возможно, это слишком много для одного человека в любом случае.

Я думаю, что то, что я выполнял в последнее время, является ролью «Технического руководителя Backend», но это больше роль Inrupt, чем Solid.

Я просто приведу очень узкую перспективу, с моей собственной точки зрения. я
тот, который в настоящее время управляет solid-auth-client. Я хотел бы ясности, такой, что
либо люди знают, что это моя ответственность, либо кто-то другой берет на себя
эта ответственность; т.е. я предпочел бы не иметь недокументированных обязанностей,
потому что это может привести к проблемам в будущем.

Например, когда я еще де-факто был лицом, публикующим
node-solid-server, кто-то временно взял на себя эту ответственность и
случайно опубликовал три неработающих релиза.

Итак, давайте проясним, по крайней мере, для более важных репозиториев, кто может
выпускать и публиковать.

Что вы думаете о холакратии https://www.holacracy.org для управления проектом Solid.
Теоретически он может разделить организацию на круги по группам интересов, каждый круг имеет «причину существования», которая проясняет его, с «референтом» в качестве «первого звена» определяются роли и круги, и их мутация регулируется в функции. потребностей.

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

У меня есть предложение, как это решить..

Распределите следующие роли:

node-solid-server Менеджер репозитория: @kjetilk
Solid-auth-client Менеджер репозитория: @RubenVerborgh
Менеджер репозитория сообщества: @Mitzi-Laszlo

@megoth @justinwb и другие, кто лучше всего подходит на следующие роли?
Менеджер репозитория rdflib:
Solid-panes Менеджер репозитория:
Solid-UI Менеджер репозитория:
Менеджер репозитория mashlib:

Есть несколько репозиториев, которые, как мне кажется, выиграют от слияния. Например: solid-tutorial-intro, solid-tutorial-angular, solid-tutorial-rdflib.js, profile-viewer-tutorial, понимание связанных данных, solid-tutorial-pastebin, web-summit-2018, intro-to. -solid-slides можно объединить с resources.md в репозитории сообщества. Кроме того, релизы, архитектура solid, руководство пользователя, словарь, пространство имен solid, платформа Solid, спецификация Solid, спецификация контроля веб-доступа, Solid Apps и solid.mit.edu также потенциально могут объединиться в сообщество. репо. Возможно, есть аналогичные комбинации, которые могут произойти с другими репозиториями?

Если над одним и тем же репо работают два человека, возникает вопрос, кто является менеджером и, следовательно, несет ответственность за надзор, а кто является основным участником.

Проекты должны быть определены в plan.md репозитория сообщества.

Мысли?

node-solid-server Менеджер репозитория: @kjetilk
Solid-auth-client Менеджер репозитория: @RubenVerborgh
Менеджер репозитория сообщества: @Mitzi-Laszlo

да

Менеджер репозитория rdflib:
Solid-panes Менеджер репозитория:
Solid-UI Менеджер репозитория:
Менеджер репозитория mashlib:

Только @timbl может сделать это, я думаю.

Есть несколько репозиториев, которые, как мне кажется, выиграют от слияния.

Объединены? Например, сделать их одним хранилищем?
Это не очень хорошая идея по нескольким причинам (я могу уточнить), но, возможно, я неправильно понимаю?

Если над одним и тем же репо работают два человека, возникает вопрос, кто является менеджером и, следовательно, несет ответственность за надзор, а кто является основным участником.

Для более сложных репозиториев их может быть несколько.

@megoth @justinwb и другие, кто лучше всего подходит на следующие роли?
Менеджер репозитория rdflib:

rdflib находится в организации linkeddata на Github , поэтому может не подпадать под работу, проделанную в рамках надежной организации на Github. Тем не менее, это жизненно важный пакет, поэтому мы можем попросить людей из linkeddata формализовать свои роли в этом репозитории.

Solid-panes Менеджер репозитория:
Solid-UI Менеджер репозитория:
Менеджер репозитория mashlib:

Да, @timbl — единственный, кто может это сделать. Он может захотеть делегировать полномочия, но это другой разговор.

Отлично, поэтому путь вперед состоит в том, чтобы выдвинуть предложение о распределении ролей для Тима следующим образом:
node-solid-server Менеджер репозитория: @kjetilk
Solid-auth-client Менеджер репозитория: @RubenVerborgh
Менеджер репозитория сообщества: @Mitzi-Laszlo
Solid-panes Менеджер репозитория: @timbl
Solid-UI Менеджер репозитория: @timbl
Менеджер репозитория mashlib: @timbl
Любые дополнительные предложения? правки?

Кто будет менеджером репозитория для каждого из репозиториев, не упомянутых в списке выше? Или у них не будет репозитория? Это включает:
маво-солид
webid-oidc-спецификация
oidc-auth-менеджер
твердый мульти-RP-клиент
папка-панель
wac-разрешить
панель-реестр
oidc-rs
Брелок
сплошная панель
сплошные уведомления
сплошной профиль пользовательского интерфейса
твердые соединения-пользовательский интерфейс
сплошная панель-источник
Хосе
сплошной почтовый ящик
oidc-op
твердый-тиф
солидный клиент
oidc-rp
панели задач
твердый
твердый список idp
kvplus-файлы
твердая электронная почта
профиль-зритель-реагировать
oidc-веб
клиент с твердой авторизацией
сплошная регистрация
твердый-вынос-импорт
узел-твердых-WS
твердая аутентификация-TLS
ldflex-детская площадка
запрос-ldflex
реактивные компоненты
твердая авторизация-oidc
панель собрания
сплошные провалы
твердый кли
твердый веб-клиент
твердые разрешения
acl-проверка

В следующих репозиториях также пока нет менеджера репозитория, однако содержимое упоминается в репозитории сообщества, и они связаны с процессами управления, поэтому я был бы готов стать кандидатом на роль менеджера репозитория для них.
Solid-tutorial-intro, Solid-tutorial-Angular, Solid-tutorial-rdflib.js, Profile-Viewer-tutorial, Понимание связанных данных, Solid-tutorial-pastebin, web-summit-2018, Intro-to-solid- слайды, релизы, твердая архитектура, руководство пользователя, словарный запас, твердое пространство имен, твердая платформа, твердая спецификация, спецификация веб-управления доступом, твердые приложения и solid.mit.edu
@RubenVerborgh Да, объединено, например, взять контент и объединить его в логически доступный для поиска контент в меньшем количестве репозиториев. Причина в том, что как новичок вы можете попасть в репозиторий сообщества, чтобы сориентироваться и найти все материалы, связанные с управлением. Это было бы ориентацией, прежде чем копаться в других репозиториях (карта была бы полезна). Любопытно услышать ваши мысли о лучшем пути вперед.

Я думаю, что запасным вариантом является Менеджер репозитория проектов.

Вы можете явно добавить меня в качестве менеджера для проверки acl, так как он явно будет поддерживаться (если только @timbl не захочет быть менеджером репо для этого).

@kjetilk , если вы имеете в виду менеджера по выпуску проекта? Альтернативой изменению описания роли менеджера релизов в качестве запасного варианта, когда нет менеджера репозитория, может быть указание вас в качестве менеджера репозитория для всех оставшихся репозиториев. Будет ли это работать?

Возможно, идея перенести разговор о слиянии в другой пулл-реквест.

@megoth , не хотел бы ты взять на себя некоторые роли менеджера репозитория?

Подводя итог, вот последнее предложение по завершению этого выпуска, которое Тим должен объединить.

mavo-solid, webid-oidc-spec, oidc-auth-manager, solid-multi-rp-client, панель папок, wac-allow, панель-реестр, oidc-rs, цепочка для ключей, сплошная панель, сплошные уведомления, Solid-Profile-UI, Solid-Connections-UI, Solid, Панель-источник, Хосе, Solid-Inbox, oidC-OP, Solid-Tif, Solid-Client, oidC-RP, Проблема Панели, Solid, Solid-IDP- список, kvplus-файлы, сплошная электронная почта, средство просмотра профиля, реакция, oidc-веб, твердая авторизация-клиент, сплошная регистрация, твердая, импорт-вынос, узел-твердая-ws, твердая-аутентификация-TLS, ldflex-playground, query-ldflex, react-components, solid-auth-oidc, панель встреч, solid-dips, solid-cli, solid-web-client, solid-permissions, acl-check, node-solid-server Repository Менеджер: @kjetilk

Solid-auth-client Менеджер репозитория: @RubenVerborgh

сообщество, Solid-tutorial-intro, Solid-tutorial-Angular, Solid-tutorial-rdflib.js, Profile-Viewer-tutorial, понимание связанных данных, Solid-tutorial-pastebin, веб-саммит-2018, введение-в- Solid-слайды, релизы, Solid-архитектура, руководство пользователя, Vocab, Solid-Namespace, Solid-Platform, Solid-Spec, Web-Access-Control-Spec, Solid-Apps и Solid.mit.edu Менеджер репозитория: @Mitzi -Ласло

сплошные панели, сплошной интерфейс, mashlib, менеджер репозитория: @timbl

Просто задумался... есть ли особая причина, по которой я не "менеджер" репозитория vocab ? Или, в более общем плане, не должен ли создатель репо быть «менеджером» по умолчанию (если, конечно, он не хочет эту «роль»). В конце концов, я создал репозиторий словарей 3-4 года назад и фактически работал над ним и вокруг него.

Я был бы открыт для этого, @timbl был бы человеком, который в конечном итоге распределяет людей по ролям.

https://github.com/solid/community/issues/32 Я начал параллельный разговор об информационной структуре, которая актуальна, потому что словарь и словарь солида удваиваются. @csarven и @RubenVerborgh хотят услышать ваши мысли о том, как двигаться дальше.

(Кроме того, https://github.com/solid/community/pull/31 предложения для других ролей переплетаются с этим разговором)

Я не вижу их взаимосвязанными. Насколько я могу судить, vocab имеет другую цель, чем solid-dictionary. Но если это не так, то почему вообще существует solid-dictionary? Не лучше ли внести свой вклад в репозиторий словарного запаса?

Цель репозитория vocab, пожалуй, лучше всего выражена в этом комментарии: https://github.com/solid/vocab/issues/1#issuecomment -170134584 (по крайней мере, это довольно близко к причине, по которой я создал репозиторий в первом место). FWIW, в то время мы не управляли надежными (основанными на RDF) словарями для серверов и приложений, которые мы создавали. Нам нужно было место, чтобы иметь лучшее представление о том, что у нас есть и что нам нужно... , а также для документирования и достижения консенсуса.

solid-dictionary больше похож на место, где компоненты (например, словари, протоколы) используются или потенциально могут использоваться в «твердом мире». Это полезно само по себе, но я бы не стал их объединять.

@csarven написал:

Я не вижу их взаимосвязанными. Насколько я могу судить, vocab имеет другую цель, чем solid-dictionary.

Да, это тоже было бы моим пониманием. Насколько я понимаю, vocab предназначен для RDF, а solid-dictionary — для описания терминов в прозе, предназначенной исключительно для человеческого потребления.

@ Митци-Ласло спросил:

@kjetilk , если вы имеете в виду менеджера по выпуску проекта?

На самом деле, я думал, что, поскольку мы начали с одной роли «Менеджер репозиториев», а затем получили роли для каждого репо, у нас будет аналог «Менеджера релизов проекта», т.е. «Менеджер репозиториев проекта», который будет делегировать управление определенных репозиториев другим людям, а также управлять репозиториями, у которых их нет.

Если это в основном резервная роль, ее может занять менеджер по выпуску проекта, поскольку между ними не должно быть никаких важных сдержек и противовесов. Думаю, мы можем немного переусложнить роли, так что я открыт для этого.

@megoth , не хотел бы ты взять на себя некоторые роли менеджера репозитория?

Я не так много работал над репозиториями вне node-solid-server , поэтому не вижу, для какого репозитория я должен быть менеджером. Я мог бы взять на себя ответственность за некоторые из репозиториев панели, чтобы помочь разгрузить @timbl рабочую нагрузку, но в целом я думаю, что лучше, чтобы он был менеджером репозитория для них (т.е. панели, панель-источник, панель-реестр).

Я также думаю, что @RubenVerborgh должен быть менеджером репозитория для проектов, связанных с LDflex (например, ldflex-playground и query-ldflex)? Я также думаю, что он должен быть менеджером репозитория для реактивных компонентов?

В противном случае немного сложно получить обзор репозиториев, так как их так много =P Но опять же, эти роли не высечены на камне, и если мы обнаружим, что сделали что-то не так ранее, это не должно быть больше, чем немного общения и пиара, чтобы исправить это ^_^

Они нужны мне как менеджеру репо (я их полностью написал):
маво-солид
wac-разрешить
клиент с твердой авторизацией
ldflex-детская площадка
запрос-ldflex
реактивные компоненты
профиль-зритель-реагировать

Я думаю, что этому нужен Тим:
твердый

Это тот вывод, к которому мы пришли вместе?

webid-oidc-spec, oidc-auth-manager, solid-multi-rp-client, панель папок, панель реестра, oidc-rs, цепочка для ключей, сплошная панель, сплошные уведомления, твердый профиль-пользовательский интерфейс, твердый- соединения-пользовательский интерфейс, твердый, панель-источник, Хосе, твердый-входящие, oidc-op, твердый-tif, твердый-клиент, oidc-rp, проблемные панели, твердый-idp-список, kvplus-файлы, твердая-электронная почта, oidc-web, сплошная регистрация, сплошная, импорт-вынос, узел-твердая-ws, твердая-аутентификация-TLS, твердая-аутентификация-oidc, панель встреч, сплошные-провалы, сплошная-cli, сплошная-веб- клиент, солид-разрешения, acl-проверка, узел-солид-сервер Менеджер репозитория: @kjetilk

Solid-auth-client, mavo-solid, wac-allow, solid-auth-client, ldflex-playground, query-ldflex, react-components, profile-viewer-react Менеджер репозитория: @RubenVerborgh

сообщество, Solid-tutorial-Intro, Solid-tutorial-Angular, Solid-Tutorial-rdflib.js, Profile-Viewer-tutorial, Понимание-связанных-данных, Solid-tutorial-Pastebin, Web-summit-2018, Intro-to- Solid-слайды, выпуски, Solid-архитектура, руководство пользователя, Solid-пространство имен, Solid-платформа, Solid-Spec, Web-Access-Control-Spec, Solid-Apps и Solid.mit.edu Менеджер репозитория: @Mitzi-Laszlo

словарь @csarven

solid, solid-panes, solid-ui, mashlib, менеджер репозитория: @timbl

Практически да, но я думаю, что большинство репозиториев, которые я получаю, просто резервные, и человек, выполняющий резервную роль, также должен иметь право делегировать их другим.

Обновлена ​​вся информация здесь https://github.com/solid/community/pull/44 , не стесняйтесь комментировать запрос на вытягивание.