오른쪽. 이제 우리는 권한에 반영되지 않은 소수의 사람들이 차지하는 조직 역할을 가지고 있습니다. 여기서 사람들은 역할이 있는 사람들과 이해가 없으면 권한을 사용하지 않을 것이라고 가정합니다. 따라서 우리는 현재 권한에 대해 상당히 자유로우지만, 이는 권한이 역할과 일치하는 위치로 우리를 이끌 것이며, 이는 다시 과거에 기여한 사람들에 대한 권한을 취소하는 위치로 다시 이어질 것이라고 가정합니다.

좀 타이트하게 하는 게 좋을지 모르지만 커뮤니티에 도움이 될지는 모르겠습니다. 아마도 다른 방법이 있습니까?

커뮤니티에 도움이 되는 한 가지 방법은 질문이
올바른 사람들. 나는 통제할 수 없는 일에서 종종 @-언급됩니다. 견딜 수 있어
예를 들어 solid-auth-client에 대한 책임은 있지만 다른 사람은 그렇지 않습니다.

몇 달 전에 게시된 커뮤니티 역할 설명 초안에서 프로젝트 핵심 기여자 , 프로젝트 기여자 및 프로젝트 릴리스 관리자 를 설명하는 접근 방식을 취했다는 점을 지적할 가치가 있다고 생각합니다.

따라서 이 문제에 대해 프로젝트별 팀(예: node-solid-server, solid-auth-client)에 대한 기존 정의가 있습니다. 단점은 가장 최근의 풀 리퀘스트에는 이름이 지정된 프로젝트 기여자가 없었고 그들이 왜 그렇지 않았는지에 대한 언어가 없다는 것입니다. IMO, 우리는 현재 견고한 조직 아래에 있는 상위 프로필 프로젝트(예: node-solid-server, solid-auth-client)를 최소한 식별하고 관련 팀 구성원에 대한 통찰력을 제공해야 합니다.

사실, "프로젝트", "리포지토리" 등의 의미를 정의해야 한다고 생각합니다. 사실 저는 @justinwb 같은 이해가 없었습니다. "프로젝트"를 " Solid Project" 및 "Repository"는 꽤 광범위합니다. 즉, github은 저장소이고 npm은 저장소입니다.

이제 우리는 운영상으로도 사용하는 github 프로젝트와 리포지토리를 가지고 있으므로 이러한 용어는 실제로 적합하지 않습니다.

우리는 아마도 repo당 또는 패키지당 관리자 역할을 원하지 않을 것입니다. 그것은 매우 좁은 범위의 관리자가 될 것입니다... "backend manager", "dev tools manager", 등. 백엔드 관리 역할은 예를 들어 NSS 및 견고한 프로젝트 종속성을 포함합니다.

나는 여전히 우리가 필요한 경우 릴리스의 일관성을 보장하기 위해 일상적인 운영 역할인 역할을 사용할 수 있다고 생각합니다. 이것이 필요하지는 않지만 "프로젝트 릴리스 관리자"가 되어야 한다고 생각했던 것입니다. 그 기능을 갖기 위해. 그리고 아마도 1인분에게는 너무 많은 양일 것입니다.

제가 최근에 하고 있는 역할이 '기술 리드 백엔드' 역할인 것 같은데, 솔리드 역할보다는 방해 역할에 더 가깝습니다.

나는 내 자신의 관점에서 매우 좁은 관점을 가져갈 것입니다. 나는
현재 solid-auth-client를 관리하는 것. 나는 그런 명확성을 원한다.
사람들은 그것이 내 책임이라는 것을 알고 있거나 다른 사람이
그 책임; 즉, 문서화되지 않은 책임을 지고 싶지 않습니다.
나중에 문제가 발생할 수 있기 때문입니다.

예를 들어 내가 아직 출판계의 사실상의 사람이었을 때
node-solid-server, 다른 누군가가 일시적으로 그 책임과
실수로 세 개의 깨진 릴리스를 게시했습니다.

따라서 더 중요한 저장소에 대해 누가
출시 및 출판.

Solid 프로젝트 관리를 위한 holacracy 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도 잠재적으로 커뮤니티에 병합될 수 있습니다. 레포. 아마도 다른 repos에서 발생할 수 있는 유사한 조합이 있습니까?

동일한 리포지토리에서 작업하는 두 사람이 있는 경우 누가 관리자이고 따라서 감독을 담당하고 누가 핵심 기여자인지 파악하는 문제가 될 것입니다.

프로젝트는 커뮤니티 리포지토리의 plan.md에서 정의해야 합니다.

생각?

node-solid-server 저장소 관리자: @kjetilk
solid-auth-client 저장소 관리자: @RubenVerborgh
커뮤니티 저장소 관리자: @Mitzi-Laszlo

네

rdflib 저장소 관리자:
솔리드 창 리포지토리 관리자:
solid-ui 저장소 관리자:
mashlib 저장소 관리자:

@timbl 만이 이것을 할 수 있다고 생각합니다.

병합하면 도움이 될 것 같은 저장소가 몇 개 있습니다.

병합? 에서와 같이 하나의 저장소로 만드시겠습니까?
그것은 몇 가지 이유로 좋은 생각이 아니지만(자세히 설명할 수 있음), 아마도 내가 오해하고 있는 것일까요?

동일한 리포지토리에서 작업하는 두 사람이 있는 경우 누가 관리자이고 따라서 감독을 담당하고 누가 핵심 기여자인지 파악하는 문제가 될 것입니다.

더 복잡한 리포지토리에는 여러 개가 있을 수 있습니다.

@megoth @justinwb 외, 누가 다음 역할에 가장 적합할까요?
rdflib 저장소 관리자:

rdflib는 Github의 linkeddata 조직에 있으므로 Github 에서 견고한 조직의 일부로 수행된 작업에 속하지 않을 수 있습니다. 하지만 중요한 패키지이므로, linkeddata의 사람들에게 해당 저장소에서 자신의 역할을 공식화하도록 요청할 수 있습니다.

솔리드 창 리포지토리 관리자:
solid-ui 저장소 관리자:
mashlib 저장소 관리자:

예, @timbl 만이 이것을 할 수 있습니다. 그는 위임하고 싶을 수도 있지만 그것은 또 다른 토론입니다.

좋습니다. 앞으로의 경로는 다음과 같이 Tim에게 역할 할당을 제안하는 것입니다.
node-solid-server 저장소 관리자: @kjetilk
solid-auth-client 저장소 관리자: @RubenVerborgh
커뮤니티 저장소 관리자: @Mitzi-Laszlo
솔리드 창 저장소 관리자: @timbl
solid-ui 저장소 관리자: @timbl
mashlib 저장소 관리자: @timbl
추가 제안 사항이 있습니까? 편집?

위 목록에 언급되지 않은 각 저장소의 저장소 관리자는 누구입니까? 아니면 저장소 관리자가 없을까요? 여기에는 다음이 포함됩니다.
마보 솔리드
webid-oidc-spec
oidc 인증 관리자
솔리드 멀티 rp 클라이언트
폴더 창
wac 허용
창 등록
oidc-rs
키체인
단색 창
고체 알림
솔리드 프로파일 UI
솔리드 연결 UI
솔리드 창 소스
호세
솔리드 인박스
oidc-op
솔리드 티프
솔리드 클라이언트
oidc-rp
문제 창
단단한
solid-idp-list
kvplus 파일
솔리드 이메일
프로필 뷰어 반응
oidc-web
솔리드 인증 클라이언트
확실한 가입
고체 테이크 아웃 수입
node-solid-ws
solid-auth-tls
ldflex 놀이터
쿼리 ldflex
반응 구성 요소
solid-auth-oidc
회의 창
솔리드 딥
솔리드 cli
솔리드 웹 클라이언트
솔리드 퍼미션
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.mit.edu
@RubenVerborgh 예, 내용을 병합하고 더 적은 수의 저장소에서 논리적으로 검색 가능한 내용으로 결합합니다. 그 이유는 초보자로서 커뮤니티 리포지토리에 착륙하여 모든 거버넌스 관련 자료를 찾고 찾을 수 있기 때문입니다. 이것은 다른 저장소를 파헤치기 전에 방향이 될 것입니다(지도가 도움이 될 것입니다). 앞으로의 최선의 방법에 대한 귀하의 생각이 궁금합니다.

폴백은 프로젝트 리포지토리 관리자라고 생각합니다.

@timbl 이 저장소 관리자가 되기를 원하지 않는 한 분명히 유지 관리될 것이기 때문에 명시적으로 나를 cl-check의 관리자로 추가할 수 있습니다.

@kjetilk 프로젝트 릴리스 관리자를 의미한다고 가정합니까? 저장소 관리자가 없을 때 대체가 되는 릴리스 관리자로 역할 설명을 변경하는 대안은 나머지 모든 저장소에 대한 저장소 관리자로 나열하는 것입니다. 그게 효과가 있을까요?

아마도 다른 풀 리퀘스트로 병합하는 것에 대한 대화를 나누는 아이디어일 것입니다.

@megoth 저장소 관리자 역할을 맡으시겠습니까?

요약하자면, 이 문제를 Tim이 병합하기로 결론짓는 최신 제안이 있습니다.

mavo-solid, webid-oidc-spec, oidc-auth-manager, solid-multi-rp-client, 폴더 창, wac-allow, 창 레지스트리, oidc-rs, 키체인, 솔리드 창, 솔리드 알림, solid-profile-ui, solid-connections-ui, solid, 창 소스, jose, solid-inbox, oidc-op, solid-tif, solid-client, oidc-rp, 문제 창, solid, solid-idp- list, kvplus-files, solid-email, profile-viewer-react, oidc-web, solid-auth-client, solid-sign-up, solid, 테이크아웃 가져오기, 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, 이해 연결 데이터, solid-tutorial-pastebin, web-summit-2018, intro-to- solid-slides, 릴리스, solid-architecture, 사용자 가이드, 어휘, solid-namespace, solid-platform, solid-spec, web-access-control-spec, solid-apps 및 solid.mit.edu 저장소 관리자: @Mitzi -라즐로

solid-panes, solid-ui, mashlib, 저장소 관리자: @timbl

생각해보면... 내가 vocab 저장소의 "관리자"가 아닌 특별한 이유가 있습니까? 또는 더 일반적으로 저장소 작성자가 기본적으로 "관리자"가 되어서는 안 됩니다(물론 해당 "역할"을 원하지 않는 경우 제외). 결국, 나는 3-4년 전에 vocab repo를 만들었고 실제로 그 주변에서 일했습니다.

나는 그것에 대해 열려 있습니다. @timbl 은 궁극적으로 개인을 역할에 할당하는 사람이 될 것입니다.

https://github.com/solid/community/issues/32 vocab과 solid-dictionary가 중복되기 때문에 관련된 정보 구조에 대한 병렬 대화를 시작했습니다. @csarven 과 @RubenVerborgh 는 이에 대한 귀하의 생각을 듣고 싶어합니다.

(또한 https://github.com/solid/community/pull/31 다른 역할에 대한 제안이 이 대화와 얽혀 있습니다)

나는 그것들이 서로 얽혀 있다고 보지 않습니다. 내가 말할 수 있는 한 vocab은 solid-dictionary와 다른 목적을 가지고 있습니다. 그런데 그게 아니라면 처음부터 입체사전이 존재하는 이유는 무엇일까요? vocab repo에 기여했다면 더 좋지 않았을까요?

vocab repo의 목적은 아마도 https://github.com/solid/vocab/issues/1#issuecomment -170134584(적어도 내가 처음에 repo를 만든 이유에 꽤 가깝습니다. 장소). FWIW, 그 당시 우리는 우리가 구축하고 있던 서버와 앱에 대한 견고한(RDF 기반) 어휘를 관리하지 않았습니다. 우리는 우리가 갖고 있고 필요로 하는 것을 더 잘 다룰 수 있는 곳이 필요했습니다. 뿐만 아니라 문서화하고 합의에 도달할 수 있는 곳이 필요했습니다.

solid-dictionary는 구성 요소(예: 어휘, 프로토콜)가 사용되거나 "고체 세계"에서 잠재적으로 사용될 수 있는 장소와 더 비슷해 보입니다. 그것은 그 자체로 유용하지만 나는 그것들을 혼합하지 않을 것입니다.

@csarven 은 다음과 같이 썼습니다.

나는 그것들이 서로 얽혀 있다고 보지 않습니다. 내가 말할 수 있는 한 vocab은 solid-dictionary와 다른 목적을 가지고 있습니다.

네, 그것도 이해가 됩니다. 내 이해는 vocab은 RDF를 위한 것이고 solid-dictionary는 순전히 인간 소비를 위한 전문 용어의 설명을 위한 것입니다.

@Mitzi-Laszlo는 다음과 같이 질문했습니다.

@kjetilk 프로젝트 릴리스 관리자를 의미한다고 가정합니까?

사실, 저는 우리가 단일 "리포지토리 관리자" 역할로 시작한 다음 리포지토리별 역할을 얻었기 때문에 관리를 위임하는 "프로젝트 릴리스 관리자", 즉 "프로젝트 리포지토리 관리자"와 유사한 역할을 할 것이라고 생각했습니다. 특정 리포지토리를 다른 사람에게 양도하고 리포지토리가 없는 리포지토리를 관리합니다.

대부분이 대체 역할인 경우 둘 사이에 중요한 견제와 균형이 없어야 하므로 프로젝트 릴리스 관리자가 그 역할을 맡을 수 있습니다. 우리는 역할을 약간 과도하게 엔지니어링하고 있을 수 있으므로 허용합니다.

@megoth 저장소 관리자 역할을 맡으시겠습니까?

나는 node-solid-server 외부의 리포지토리에 대해 그렇게 많은 작업을 하지 않았으므로 어떤 리포지토리 관리자가 되어야 하는지 알 수 없습니다. @timbl 의 작업 부하를 덜어주기 위해 일부 창 저장소에 대한 책임을 맡을 수도 있지만 일반적으로 그를 저장소 관리자로 두는 것이 더 낫다고 생각합니다(예: 폴더 창, 솔리드 창, 문제- 창, 창 소스, 창 레지스트리).

또한 @RubenVerborgh 가 LDflex 관련 프로젝트(예: ldflex-playground 및 query-ldflex)의 저장소 관리자여야 한다고 생각합니까? 또한 그가 반응 구성 요소의 저장소 관리자여야 한다고 생각합니까?

그렇지 않으면 =P가 너무 많기 때문에 리포지토리에 대한 개요를 얻는 것이 약간 어렵습니다. 그러나 다시 이러한 역할은 고정되어 있지 않으며, 우리가 더 일찍 뭔가 잘못한 것을 발견하면 약간의 의사 소통과 PR을 통해 수정하십시오 ^_^

이것들은 리포지토리 관리자가 필요합니다(완전히 작성했습니다).
마보 솔리드
wac 허용
솔리드 인증 클라이언트
ldflex 놀이터
쿼리 ldflex
반응 구성 요소
프로필 뷰어 반응

나는 이것이 Tim이 필요하다고 생각합니다.
단단한

이것이 우리가 함께 내린 결론입니까?

webid-oidc-spec, oidc-auth-manager, solid-multi-rp-client, 폴더 창, 창 레지스트리, oidc-rs, 키체인, solid-pane, solid-notifications, solid-profile-ui, solid- 연결 UI, 솔리드, 창 소스, jose, solid-inbox, oidc-op, solid-tif, solid-client, oidc-rp, 문제 창, 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-dip, 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, 릴리스, solid-architecture, 사용자 가이드, 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

실제로는 그렇습니다. 하지만 제가 얻는 repos의 대부분은 그냥 fallback이고, fallback 역할을 하는 사람은 다른 사람에게 위임할 권한도 있어야 한다고 생각합니다.

https://github.com/solid/community/pull/44 에서 모든 정보를 업데이트했습니다. 풀 리퀘스트에 대해 자유롭게 의견을 말해주세요.