正确的。 现在，我们有由少数人占据的组织角色，并且没有反映在权限中，其中假设人们如果不了解具有角色的人就不会使用权限。 因此，我们现在对权限非常自由，但是我认为这将引导我们到达权限匹配角色的位置，这可能又会导致我们撤销对过去做出贡献的人的权限。

稍微收紧一点可能是件好事，但我不知道这是否会对社区有所帮助。 也许还有其他方法？

帮助社区的一种方式是问题针对
对的人。 我经常在我无法控制的事情中被@-提及。 我能承受
例如，对solid-auth-client 负责，但对其他人不负责。

我认为值得指出的是，在几个月前发布的社区角色描述草案中，我们采取了描述项目核心贡献者、项目贡献者和项目发布经理的方式。

因此，对于这个问题，我们有针对项目特定团队（即 node-solid-server、solid-auth-client）的现有定义。 我认为缺点是在最近的拉取请求中没有提到项目贡献者，也没有任何语言说明他们为什么没有。 IMO，我们至少应该确定一些目前在实体组织下的更高知名度的项目（如 node-solid-server、solid-auth-client），并提供一些关于那里相关团队成员的见解。

实际上，我认为我们需要定义“项目”，“存储库”等的含义。实际上，我没有相同的理解， @justinwb ，我将“项目”解释为一个非常广泛的东西，例如“ Solid Project”，以及相当广泛的“Repository”，即 github 是一个存储库，npm 是一个存储库。

现在，我们有 github 项目和存储库，我们也在操作上使用它们，所以这些术语并不是那么合适。

我们可能也不希望拥有每个 repo 或每个包的管理器角色，那将是一个范围非常狭窄的管理器......我认为最好有“后端管理器”、“开发工具管理器”、等等。例如，后端管理角色将包括 NSS 和可靠的项目依赖项。

我仍然认为我们可以使用一个日常运营角色来确保在需要的地方发布的一致性，这就是我一直认为的“项目发布经理”应该是，尽管我们不需要拥有这些功能。 无论如何，对于一个人来说，这可能太多了。

我认为我最近一直在扮演“Tech Lead Backend”角色，但这更像是一个 Inrupt 角色而不是一个 Solid 角色。

我只是从我自己的角度提出一个非常狭隘的观点。 我是
当前管理solid-auth-client的那个。 我想要这样的清晰
要么人们知道这是我的责任，要么是别人承担
该责任； 即，我宁愿没有无证的责任，
因为这可能会导致将来出现问题。

举个例子，当我还是事实上的出版人时
node-solid-server，其他人暂时承担了责任和
不小心发布了三个损坏的版本。

所以让我们明确一点，至少对于更重要的回购，谁可以
发布和发布。

你如何看待 Holacracy https://www.holacracy.org来管理 Solid 项目。
从理论上讲，它可以将组织按兴趣组划分成圈子，每个圈子都有一个明确的“理由”，以“参照物”作为“第一环节”的角色和圈子是确定的，而这些圈子的变异在功能上受到调节的需求。

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

我有一个关于如何解决这个问题的建议..

分配以下角色：

节点固体服务器存储库管理器：@kjetilk
solid-auth-client 存储库管理器：@RubenVerborgh
社区存储库经理：@Mitzi-Laszlo

@megoth @justinwb和其他人，谁最适合以下角色？
rdflib 存储库管理器：
实体窗格存储库管理器：
solid-ui 存储库管理器：
mashlib 存储库管理器：

我觉得有些存储库会从合并中受益。 例如：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 都可以与社区 repo 中的 resources.md 合并。 此外，发布、solid-architecture、用户指南、vocab、solid-namespace、solid-platform、solid-spec、web-access-control-spec、solid-apps 和 solid.mit.edu 也可能会合并到社区中回购。 也许其他回购可能会发生类似的组合？

如果有两个人在同一个 repo 上工作，那将是一个问题，即谁是经理，因此负责监督，谁是核心贡献者。

项目需要在社区 repo 的 plan.md 中定义。

想法？

节点固体服务器存储库管理器：@kjetilk
solid-auth-client 存储库管理器：@RubenVerborgh
社区存储库经理：@Mitzi-Laszlo

是的

rdflib 存储库管理器：
实体窗格存储库管理器：
solid-ui 存储库管理器：
mashlib 存储库管理器：

我认为只有@timbl可以做到这些。

我觉得有些存储库会从合并中受益。

合并？ 例如，让它们成为一个存储库？
出于几个原因，这不是一个好主意（我可以详细说明），但也许我误解了？

如果有两个人在同一个 repo 上工作，那将是一个问题，即谁是经理，因此负责监督，谁是核心贡献者。

可能有多个更复杂的回购。

@megoth @justinwb和其他人，谁最适合以下角色？
rdflib 存储库管理器：

rdflib 位于 Github 上的linkeddata 组织中，因此可能不属于 Github 上作为可靠组织的一部分所做的工作。 不过，它是一个至关重要的软件包，因此我们可能希望要求linkeddata 的人员正式确定他们在该存储库中的角色。

实体窗格存储库管理器：
solid-ui 存储库管理器：
mashlib 存储库管理器：

是的， @timbl是唯一可以做到这一点的人。 他可能想授权，但这是另一个讨论。

太好了，所以前进的道路是向蒂姆提出角色分配建议，如下所示：
节点固体服务器存储库管理器：@kjetilk
solid-auth-client 存储库管理器：@RubenVerborgh
社区存储库经理：@Mitzi-Laszlo
实体窗格存储库管理器：@timbl
solid-ui 存储库管理器：@timbl
mashlib 存储库管理器：@timbl
有什么额外的建议吗？ 编辑？

谁将是上面列表中未提及的每个存储库的存储库管理员？ 还是他们没有存储库管理器？ 这些包括：
马沃固体
webid-oidc 规范
oidc 身份验证管理器
固体多RP客户端
文件夹窗格
允许
窗格注册表
oidc-rs
钥匙链
实心窗格
实体通知
实体配置文件-ui
固体连接-ui
实体窗格源
何塞
固定收件箱
oidc-op
固体tif
固客户端
oidc-rp
问题窗格
坚硬的
固体 idp 列表
kvplus 文件
固体电子邮件
个人资料查看器反应
oidc 网络
可靠的身份验证客户端
稳固注册
固体外卖进口
节点固体ws
可靠的授权 tls
ldflex 游乐场
查询-ldflex
反应组件
固体认证 oidc
会议窗格
固浸
固体cli
固体网络客户端
固体权限
acl检查

以下存储库目前还没有存储库管理器，但是社区存储库中提到了内容并且它们与治理流程相关，因此我愿意成为它们的存储库管理器候选人。
solid-tutorial-intro、solid-tutorial-angular、solid-tutorial-rdflib.js、profile-viewer-tutorial、理解链接数据、solid-tutorial-pastebin、web-summit-2018、intro-to-solid-幻灯片、发布、solid-architecture、用户指南、vocab、solid-namespace、solid-platform、solid-spec、web-access-control-spec、solid-apps 和 solid.mit.edu
@RubenVerborgh是的，合并为获取内容并将它们组合成逻辑可搜索的内容，在更少的存储库中。 原因是作为新手，您可以登陆社区回购以定位和查找所有与治理相关的材料。 这将是在深入研究其他存储库之前的一个方向（地图会很有帮助）。 很想听听您对最佳前进方式的看法。

我认为后备是项目存储库管理器。

不过，您可以明确地将我添加为 acl-check 的经理，因为它显然会被维护（除非@timbl想成为它的 repo 经理）。

@kjetilk假设您的意思是项目发布经理？ 当没有存储库管理员时，将角色描述更改为作为后备​​的发布管理员的替代方法是将您列为所有剩余存储库的存储库管理员。 那行得通吗？

也许是一个想法来讨论合并到不同的拉取请求。

@megoth您想担任一些存储库管理员角色吗？

总而言之，这是结束此问题的最新提案，将由 Tim 合并。

mavo-solid、webid-oidc-spec、oidc-auth-manager、solid-multi-rp-client、文件夹窗格、wac-allow、pane-registry、oidc-rs、钥匙串、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-列表，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、会议窗格、solid-dips、solid-cli、solid-web-client、solid-permissions、acl-check、node-solid-server 存储库经理：@kjetilk

solid-auth-client 存储库管理器：@RubenVerborgh

社区，solid-tutorial-intro，solid-tutorial-angular，solid-tutorial-rdflib.js，profile-viewer-tutorial，理解链接数据，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 和 solid.mit.edu 存储库管理器：@Mitzi -拉斯洛

solid-panes、solid-ui、mashlib、存储库管理器：@timbl

只是在想……我不是vocab回购的“经理”有什么特别的原因吗？ 或者更一般地说，默认情况下，repo 的创建者不应该是“经理”（当然，除非他们不想要那个“角色”）。 毕竟，我在 3 到 4 年前创建了 vocab repo，并且实际上一直在研究它并围绕它工作。

我对此持开放态度， @timbl将是最终将个人分配给角色的人

https://github.com/solid/community/issues/32我已经开始了关于信息结构的并行对话，这是相关的，因为 vocab 和 solid-dictionary 加倍。 @csarven和@RubenVerborgh很想听听您对如何推进这一点的想法。

（此外，https://github.com/solid/community/pull/31 对其他角色的建议与此对话交织在一起）

我不认为它们是相互交织的。 据我所知，词汇的用途与实体词典不同。 但如果不是这样的话，为什么一开始就存在solid-dictionary呢？ 为词汇库做出贡献不是更好吗？

vocab repo 的目的可能最好在此评论中表达： https ://github.com/solid/vocab/issues/1#issuecomment -170134584（至少这与我在第一个创建 repo 的原因非常接近地方）。 FWIW，当时，我们没有为我们正在构建的服务器和应用程序管理可靠的（基于 RDF）词汇表。 我们需要一个地方来更好地处理我们拥有和需要的东西......，以及记录和达成一些共识。

solid-dictionary 似乎更像是在“实体世界”中使用或可能使用组件（例如词汇、协议）的地方。 这本身很有用，但我不会将它们混为一谈。

@csarven写道：

我不认为它们是相互交织的。 据我所知，词汇的用途与实体词典不同。

是的，这也是我的理解。 我的理解是 vocab 用于 RDF，solid-dictionary 用于描述散文中的术语，纯粹用于人类消费。

@Mitzi-Laszlo 问：

@kjetilk假设您的意思是项目发布经理？

实际上，我在想，由于我们从一个单一的“存储库经理”角色开始，然后获得了每个存储库的角色，我们将有一个类似于“项目发布经理”的类似物，即“项目存储库经理”，它将委派管理将某些存储库分发给其他人，以及管理没有存储库的存储库。

如果它主要是一个后备角色，它可以由项目发布经理占据，因为两者之间不应该有任何重要的制衡。 我猜我们可能对角色进行了过度设计，所以我对此持开放态度。

@megoth您想担任一些存储库管理员角色吗？

我没有在node-solid-server之外的存储库上做太多工作，所以看不出我应该成为哪个存储库管理器。 我可能会负责一些窗格存储库，以帮助减轻@timbl的工作量，但总的来说，我认为最好让他担任这些的存储库管理员（即文件夹窗格、实体窗格、问题-窗格、窗格源、窗格注册表）。

我还认为@RubenVerborgh应该是 LDflex 相关项目（即 ldflex-playground 和 query-ldflex）的存储库经理？ 我还认为他应该是反应组件的存储库经理？

否则，要了解存储库有点困难，因为有这么多 =P 但是话又说回来，这些角色并不是一成不变的，如果我们发现我们之前做错了什么，它不应该超过一个一点沟通和公关来解决它^_^

这些需要我作为回购经理（我完全写了它们）：
马沃固体
允许
可靠的身份验证客户端
ldflex 游乐场
查询-ldflex
反应组件
个人资料查看器反应

我认为这个需要蒂姆：
坚硬的

这是我们一起得出的结论吗？

webid-oidc-spec、oidc-auth-manager、solid-multi-rp-client、文件夹窗格、窗格注册表、oidc-rs、钥匙串、solid-pane、solid-notifications、solid-profile-ui、solid-连接 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、会议窗格、solid-dips、solid-cli、solid-web-客户端、solid-permissions、acl-check、node-solid-server 存储库管理器：@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-slides、releases、solid-architecture、user guide、solid-namespace、solid-platform、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随时对拉取请求发表进一步评论。