右。 現在、私たちは少数の人々によって占められ、許可に反映されていない組織の役割を持っています。そこでは、役割を持つ人々との理解がない場合、人々は許可を使用しないと想定されています。 ですから、私たちは今、パーミッションにかなり寛大ですが、これは、パーミッションが役割と一致する場所に私たちを導き、おそらく過去に貢献した人々のパーミッションを取り消す場所に私たちを導くでしょう。

少し引き締めるのもいいかもしれませんが、それがコミュニティに役立つかどうかはわかりません。 おそらく他の方法がありますか？

コミュニティに役立つ1つの方法は、質問が
適切な人々。 私は自分の手に負えないことでしばしば@-言及されます。 我慢できる
たとえば、solid-auth-clientの責任ですが、他の責任はありません。

数か月前に公開されたコミュニティの役割の説明のドラフトでは、プロジェクトコアコントリビューター、プロジェクトコントリビューター、およびプロジェクトリリースマネージャーを説明するアプローチを採用したことを指摘する価値があると思います。

したがって、この問題ごとに、プロジェクト固有のチーム（つまり、node-solid-server、solid-auth-client）の既存の定義があります。 欠点は、最近のプルリクエストには、名前が付けられたプロジェクトの貢献者がいなかったことと、彼らがそうでなかった理由についての言葉がなかったことだと思います。 IMO、少なくとも、現在堅実な組織の下にある注目度の高いプロジェクト（node-solid-server、solid-auth-clientなど）のいくつかを特定し、そこに関連するチームメンバーに関する洞察を提供する必要があります。

実際、「プロジェクト」や「リポジトリ」などの意味を定義する必要があると思います。実際、私は同じ理解を持っていませんでした。 @ justinwb 、「プロジェクト」は「プロジェクト」を「 Solid Project」、および「Repository」もかなり広いです。つまり、githubはリポジトリであり、npmはリポジトリです。

現在、githubプロジェクトとリポジトリがあり、これらも運用上使用しているため、これらの用語はあまり適していません。

おそらく、リポジトリごとまたはパッケージごとのマネージャーの役​​割は必要ありません。それは、非常に狭い範囲のマネージャーになります...「バックエンドマネージャー」、「開発ツールマネージャー」、バックエンド管理の役割には、たとえばNSSとソリッドプロジェクトの依存関係が含まれます。

必要に応じてリリースの一貫性を確保するために、日常の運用上の役割を使用できると思います。これは、必要ではないものの、「プロジェクトリリースマネージャー」が必要だと私が考えていたものです。それらの機能を持つために。 そして、おそらくそれはとにかく一人の人には多すぎます。

私が最近行っているのは「TechLeadBackend」の役割だと思いますが、それは堅実な役割というよりは断続的な役割です。

私自身の観点から、非常に狭い視点を持ってきます。 私
現在solid-auth-clientを管理しているもの。 私はそのような明快さを望みます
人々はそれが私の責任であることを知っているか、他の誰かが取っていることを知っています
その責任; つまり、文書化されていない責任を持ちたくないのですが、
それは将来問題につながる可能性があるからです。

例として、私がまだ事実上​​の人であったとき
node-solid-server、他の誰かが一時的にその責任を引き受け、
誤って3つの壊れたリリースを公開しました。

それでは、少なくともより重要なリポジトリについては、明確にしましょう。
リリースして公開します。

Solidプロジェクトを管理するためのホラクラシーhttps://www.holacracy.orgについてどう思いますか。
理論的には、関心のあるグループごとに組織をサークルに分割できます。各サークルには、それを明確にする理由があり、「最初のリンク」としての「指示対象」の役割とサークルが決定され、それらの突然変異は機能で規制されます。ニーズの。

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

これを解決する方法についての提案があります。

次の役割を割り当てます。

node-solid-serverリポジトリマネージャー：@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はすべて、コミュニティリポジトリのresources.mdとマージできます。 さらに、リリース、solid-architecture、user guide、vocab、solid-namespace、solid-platform、solid-spec、web-access-control-spec、solid-apps、solid.mit.eduもコミュニティに統合される可能性がありますレポ。 おそらく、他のリポジトリで発生する可能性のある同様の組み合わせがありますか？

同じレポで作業している2人の人がいる場合、どちらがマネージャーであり、したがって監視の責任者であり、誰が主要な貢献者であるかを判断することが問題になります。

プロジェクトは、コミュニティリポジトリのplan.mdで定義する必要があります。

考え？

node-solid-serverリポジトリマネージャー：@kjetilk
solid-auth-clientリポジトリマネージャー：@RubenVerborgh
コミュニティリポジトリマネージャー：@ Mitzi-Laszlo

はい

rdflibリポジトリマネージャー：
ソリッドペインリポジトリマネージャー：
solid-uiリポジトリマネージャー：
mashlibリポジトリマネージャー：

@timblだけがこれらを行うことができると思います。

マージすることでメリットが得られると思うリポジトリがいくつかあります。

マージしましたか？ のように、それらを1つのリポジトリにしますか？
これはいくつかの理由で良い考えではありませんが（詳しく説明できます）、おそらく私は誤解していますか？

同じレポで作業している2人の人がいる場合、どちらがマネージャーであり、したがって監視の責任者であり、誰が主要な貢献者であるかを判断することが問題になります。

より複雑なリポジトリの場合は複数存在する可能性があります。

@megoth @justinwbと他の人、次の役割に最も適しているのは誰ですか？
rdflibリポジトリマネージャー：

rdflibはGithubのlinkeddata組織に含まれているため、Githubの強固な組織の一部として行われる作業に該当しない可能性があります。 ただし、これは重要なパッケージであるため、linkeddataの担当者に、そのリポジトリでの役割を形式化するよう依頼することをお勧めします。

ソリッドペインリポジトリマネージャー：
solid-uiリポジトリマネージャー：
mashlibリポジトリマネージャー：

はい、これを実行できるのは@timblだけです。 彼は委任したいかもしれませんが、それは別の議論です。

すばらしいので、次のように、ティムへの役割の割り当ての提案を提案することが前進の道です。
node-solid-serverリポジトリマネージャー：@kjetilk
solid-auth-clientリポジトリマネージャー：@RubenVerborgh
コミュニティリポジトリマネージャー：@ Mitzi-Laszlo
ソリッドペインリポジトリマネージャー：@timbl
solid-uiリポジトリマネージャー：@timbl
mashlibリポジトリマネージャー：@timbl
追加の提案はありますか？ 編集？

上記のリストに記載されていない各リポジトリのリポジトリマネージャは誰ですか？ それとも、リポジトリマネージャーがいないのでしょうか。 これらには以下が含まれます：
mavo-solid
webid-oidc-spec
oidc-auth-manager
solid-multi-rp-client
フォルダペイン
wac-allow
ペインレジストリ
oidc-rs
キーホルダー
ソリッドペイン
ソリッド通知
solid-profile-ui
solid-connections-ui
ソリッドペインソース
ホセ
ソリッド受信トレイ
oidc-op
solid-tif
ソリッドクライアント
oidc-rp
問題-ペイン
個体
solid-idp-list
kvplus-ファイル
しっかりしたメール
プロファイル-ビューア-反応
oidc-web
solid-auth-client
しっかりしたサインアップ
ソリッドテイクアウト-インポート
node-solid-ws
solid-auth-tls
ldflex-遊び場
query-ldflex
反応成分
solid-auth-oidc
ミーティングペイン
ソリッドディップ
solid-cli
solid-web-client
堅実な許可
acl-チェック

以下のリポジトリにもまだリポジトリマネージャがありませんが、内容はコミュニティリポジトリに記載されており、ガバナンスプロセスに関連しているので、リポジトリマネージャ候補になりたいと思います。
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-スライド、リリース、solid-architecture、ユーザーガイド、vocab、solid-namespace、solid-platform、solid-spec、web-access-control-spec、solid-apps、solid.mit.edu
@RubenVerborghはい、コンテンツを取得して、より少ないリポジトリで論理的に検索可能なコンテンツに結合するようにマージされました。 理由は、初心者として、コミュニティリポジトリにアクセスして、ガバナンスに関連するすべての資料を方向付けて見つけることができるからです。 これは、他のリポジトリを掘り下げる前のオリエンテーションになります（マップが役立ちます）。 今後の最善の方法についてのあなたの考えを聞きたいです。

フォールバックはプロジェクトリポジトリマネージャーだと思います。

ただし、acl-checkのマネージャーとして明示的に追加することはできます。これは、明らかに維持されるためです（ @timblがそのリポジトリマネージャーになりたい場合を除く）。

@kjetilkは、プロジェクトリリースマネージャーを意味すると仮定しますか？ リポジトリマネージャーがない場合のフォールバックであるリリースマネージャーとしての役割の説明を変更する代わりに、残りのすべてのリポジトリのリポジトリマネージャーとしてあなたをリストすることもできます。 それはうまくいくでしょうか？

おそらく、別のプルリクエストへのマージについて話し合うアイデアです。

@megothは、リポジトリマネージャの役割のいくつかを引き受けたいですか？

要約すると、これがこの問題をティムによって統合されると結論付けるための最新の提案です。

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リポジトリマネージャー：@kjetilk

solid-auth-clientリポジトリマネージャー：@RubenVerborgh

コミュニティ、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、solid.mit.eduリポジトリマネージャー：@Mitzi -Laszlo

solid-panes、solid-ui、mashlib、リポジトリマネージャー：@timbl

考えているだけです...私がvocabリポジトリの「マネージャー」ではない特別な理由はありますか？ または、より一般的には、レポの作成者をデフォルトで「マネージャー」にするべきではありません（もちろん、その「役割」を望まない場合を除きます）。 結局のところ、私は3〜4年前に語彙レポを作成し、実際にその周辺で作業してきました。

@timblは、最終的に個人を役割に割り当てる人になります。

https://github.com/solid/community/issues/32語彙と固体辞書が倍増するため、関連する情報構造について並行して会話を始めました。 @csarvenと@RubenVerborghは、これを前進させる方法についてのあなたの考えを聞きたがっています。

（また、https：//github.com/solid/community/pull/31他の役割に関する提案がこの会話と絡み合っています）

私はそれらが絡み合っているとは思わない。 私の知る限り、語彙は固体辞書とは異なる目的を持っています。 しかし、そうでない場合、そもそもなぜ固体辞書が存在するのでしょうか。 語彙リポジトリに貢献したほうがよかったのではないでしょうか。

語彙リポジトリの目的は、おそらくこのコメントで最もよく表現されています： https ://github.com/solid/vocab/issues/1#issuecomment -170134584（少なくとも、最初にリポジトリを作成した理由にかなり近いです場所）。 FWIWは、当時、構築中のサーバーとアプリの堅実な（RDFベースの）語彙を管理していませんでした。 私たちは、私たちが持っているものと必要なものをよりよく処理し、文書化してコンセンサスに達するための場所を必要としていました。

solid-dictionaryは、コンポーネント（たとえば、ボーカブ、プロトコル）が使用されている場所、または「固体の世界」で使用できる可能性のある場所のように見えます。 それ自体は便利ですが、私はそれらを混同しません。

@csarvenは書いた：

私はそれらが絡み合っているとは思わない。 私の知る限り、語彙は固体辞書とは異なる目的を持っています。

ええ、それも私の理解です。 私の理解では、語彙はRDF用であり、堅実な辞書は散文の用語の説明用であり、純粋に人間の消費を目的としています。

@ Mitzi-Laszloは尋ねました：

@kjetilkは、プロジェクトリリースマネージャーを意味すると仮定しますか？

実際、私たちは単一の「リポジトリマネージャー」の役割から始めて、リポジトリごとの役割を取得したので、管理を委任する「プロジェクトリリースマネージャー」、つまり「プロジェクトリポジトリマネージャー」に類似していると思っていました。特定のリポジトリを他の人に提供するだけでなく、リポジトリを持たないリポジトリを管理します。

それが主にフォールバックの役割である場合、2つの間に重要なチェックとバランスがないはずなので、プロジェクトリリースマネージャーによって占有される可能性があります。 私たちは役割を少し過剰に設計しているかもしれないと思うので、私はそれを受け入れています。

@megothは、リポジトリマネージャの役割のいくつかを引き受けたいですか？

node-solid-serverの外部のリポジトリでそれほど多くの作業を行っていないため、どちらのリポジトリマネージャを使用すべきかがわかりません。 @timblの作業負荷を軽減するために、いくつかのペインリポジトリの責任を負う可能性がありますが、一般的には、それらのリポジトリマネージャとして彼を持っている方が良いと思います（つまり、フォルダペイン、ソリッドペイン、問題-ペイン、ペインソース、ペインレジストリ）。

また、@ RubenVerborghはLDflex関連のプロジェクト（つまり、ldflex-playgroundとquery- ldflex ）のリポジトリマネージャーである必要があると思いますか？ また、彼はreact-componentsのリポジトリマネージャーになるべきだと思いますか？

そうしないと、= Pが非常に多いため、リポジトリの概要を把握するのが少し難しくなります。しかし、繰り返しになりますが、これらの役割は明確ではありません。以前に何か間違ったことをしたことがわかった場合、それはちょっとしたコミュニケーションとそれを修正するためのPR^_ ^

これらはレポマネージャーとして私を必要とします（私はそれらを完全に書きました）：
mavo-solid
wac-allow
solid-auth-client
ldflex-遊び場
query-ldflex
反応成分
プロファイル-ビューア-反応

これにはティムが必要だと思います。
個体

これは私たちが一緒にした結論ですか？

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-接続-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リポジトリマネージャー：@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、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、solid.mit.eduリポジトリマネージャー：@ Mitzi-Laszlo

語彙@csarven

solid、solid-panes、solid-ui、mashlib、リポジトリマネージャー：@timbl

実際にはそうですが、私が取得するリポジトリのほとんどはフォールバックと同じであり、フォールバックの役割を持つ人は、それらを他の人に委任する権限も持っている必要があります。

ここですべての情報を更新しましたhttps://github.com/solid/community/pull/44プルリクエストについてさらにコメントしてください。