Information: 코드 PR 검토 기간

또한 커뮤니티 중심의 repos, 즉 조직의 변화에 ​​더 가까운 PR을 염두에 두고 프로세스 를 작성했다는 인상도 받았습니다.

동의합니다. 코드는 조직의 작동 방식을 변경하는 규칙을 구현하는 것으로 볼 수 있지만 코드 작성 방식에 대한 엄격한 제한은 불가능합니다. 그것은 실제적인 중단으로 개발을 중단할 것입니다.

코드 PR에 적용되지 않도록 프로세스를 보다 명확하게 만들 수 있습니까?

최대한 빨리? 따라서 풀 리퀘스트나 이슈를 연 후 즉시 병합하는 것이 이상적입니까? 대화의 창이 필요합니까?

나는 즉시 그것이 가능한 것 이상이라고 주장하고 싶습니다. :-) 우리는 리뷰어가 정보에 입각한 리뷰를 할 수 있도록 해야 하지만 이미 그렇게 할 시간이 필요하고 병합을 수행하기 전에 병합이 발생하지 않기 때문에 "즉시"는 가설에 불과합니다.

따라서 논쟁의 여지가 있는 코드 변경이 있기 때문에 프로세스를 코드에 적용할 수 없다는 @megoth 에 전적으로 동의하지 않습니다.

그러나 개정 시스템을 사용하는 요점은 코드 변경을 되돌릴 수 없다는 것입니다. 되돌리기가 실제로 그렇게 크고 더 오랜 시간이 걸린다는 것은 코드 변경이 정식 릴리스로 바뀌기 전의 일이 아닙니다.

여기에서 결론은 각 PR(코드용이든 아니든)이 병합되기 전에 얼마나 오래 유지되어야 하는지에 대한 엄격하고 빠른 규칙은 없다는 것입니다.

많은 코드 변경과 많은 사람이 직면하는 문서 변경은 논쟁의 여지가 없으며 PR 제출과 "수정된 오타"와 같은 항목에 병합 사이에 14일 또는 3일 또는 심지어 3시간 지연을 강요할 이유가 없습니다. , 하이퍼링크에서 하이퍼링크로" ...

PR은 일반적으로 코드 여부에 관계없이 변경되는 사항에 대해 잘 알고 있는 사람이 검토해야 합니다. "w OR ((x 및/또는 y) AND z)가 이 리포지토리/파일/무엇이든에 대한 모든 PR을 검토할 것입니다"와 같은 말을 하는 것이 합리적으로 보입니다. 검토 기간은 검토자의 작업량에 따라 다를 수 있습니다. 순간의 그리고 PR 대상!

어떤 종류의 잠재적으로 논쟁의 여지가 있는 변경 사항이 어떤 종류의 "고위층"을 포함하여 더 광범위한 검토를 요청하도록 신뢰할 수 있어야 하는 검토자가 그러한 변경 사항을 알아 차려야 합니다.

내가 고정된 기간을 선택하는 이유는 1) 문제 및 풀 요청이 충분히 빨리 처리되지 않는 것에 대한 대화가 있었기 때문입니다. 결과적으로 질문이 제기되는 제안. 명시적으로 기록하지 않는다는 것은 Solid에서 오랫동안 작업하는 사람들이 커뮤니티에 참여하는 공개된 투명한 환경이 아닌 암묵적인 참여 규칙을 추측해야 하는 신규 사용자보다 유리하다는 것을 의미합니다.

해결책으로 모든 pull 요청 및 문제가 게시되면 처리되는 데 3일의 기간이 있다고 말해야 합니까?

나는 여전히 "하나의 크기가 모두에게 맞는" 솔루션이라는 문제가 있습니다. 코드 품질과 프로젝트 진행에 여러 가지 해로운 영향을 미칠 것이라고 생각합니다.

우선, 최소 5년 동안 존재하지 않은 암묵적인 참여 규칙은 없으며 수천 개의 프로젝트에서 매우 표준적인 관행입니다. 따라서 전반적으로 개발을 완전히 처음 접하는 경우 불리한 상황에 놓이게 되겠지만, 이는 Solid의 특정 문제 때문이 아닙니다. 새로운 분야에 진입할 때 항상 학습 곡선이 수반됩니다. 내가 말했듯이 Solid는 진입 문턱이 매우 낮은 것이 중요하지만 서버 개발이 사람들이 기술 개발을 시작해야 하는 곳인지, 다른 사람들과 긴밀하게 협력할 필요가 없는 환경인지 확신할 수 없습니다. 동일한 코드 기반의 개발자가 더 적합할 수 있습니다.

대부분은 아니지만 많은 PR은 검토자의 가용성에 따라 자연스럽게 3일 이상의 검토 기간을 갖게 됩니다. 하지만 우리는 자연스럽게 검토하기 쉬운 상대적으로 작은 PR을 위해 노력합니다. 그렇게 하는 것이 좋은 습관이므로 초기 피드백을 받고 검토자에게 너무 부담이 되지 않습니다. 그러나 이는 종종 더 큰 작업을 해결하는 데 여러 증분 PR이 필요하다는 것을 의미합니다. 각 PR에 3일의 검토 기간이 필요한 경우 개발 속도가 크게 느려집니다. 그것이 정책이라면 우리 개발자들은 결국 작은 PR을 작성하지 않고 하나의 큰 PR을 작성하여 각각에 대해 3일의 검토 기간을 기다릴 필요가 없을 것이라고 생각합니다.

그러면 검토하기 어려운 더 큰 PR이 생성되고, 애자일 개발에서 벗어나고, 더 큰 위험 실수가 검토 프로세스를 통해 잠입하게 됩니다.

이와 관련하여 다른 대규모 프로젝트가 무엇을 하고 있는지 매우 듣고 싶지만 모든 상황에 적용할 수 있는 접근 방식은 바람직하지도 않고 달성할 수도 없습니다.

제가 릴리스 관리자이기 때문에 말씀 드리기 어렵지만 @TallTed 가 지원할 것이라고 생각합니다. 프로세스는 상당 부분 릴리스 관리자의 재량에 달려 있어야 합니다. 릴리스 관리자는 가장 적합한 리뷰어가 있는지, 문제에 따라 적절한 수의 리뷰어가 있는지, 적절한 수의 리뷰어가 승인에 응답하기 전에 병합이 일어나지 않도록 해야 합니다. 변경 요청이 있는 경우, 검토 프로세스를 시행하기 위해 오른쪽 분기가 잠겨 있는 경우, 잠재적으로 논쟁의 여지가 있는 PR이 일부 알림 수단을 통해 커뮤니티 리더의 주의를 끌 수 있는 경우, 그리고 실제로 다른 리뷰어가 그렇게 하는 것을 가장 환영하는 경우에는 발생하지 않습니다. 또한.

커뮤니티 지원 회의 대화의 메모를 포함하고 싶었습니다. 솔리드 팀 내 여러 사람들이 다음과 같은 점을 지적했습니다.

• 3일의 검토 기간으로 인해 작업 속도가 느려질 수 있습니다.
• 기간의 실질적인 이점은 무엇입니까? 실질적인 이점은 이해하고 다시 참조할 수 있는 투명한 의사 결정 프로세스를 통해 보다 개방적이고 포괄적인 환경을 만드는 것입니다.
• 우리가 해결하려는 문제는 무엇입니까? 그것을 해결할 다른 방법이 있습니까? 우리가 정말로 해결하려고 하는 것은 변화가 있을 때 제약이 있고 그들의 관점을 제공할 기회가 없다는 것입니다. 시간 제한은 기회를 제공하는 방법입니다. 포용성을 유도하는 또 다른 접근 방식은 제안을 사람들이 확인할 수 있는 환경(예: 확고한/제안)에 게시하도록 하는 것입니다.
  – 뿌리가 아닌 차별의 부작용.
• 포용성과 효율성 사이의 경계는 어디입니까? Do-ocracy는 일을 하는 사람들이 결정하도록 해야 합니다. 자율성이 거의 없다는 것은 우리가 가지 말아야 할 또 다른 극단입니다. Metirocracy – do-ocracy. 이러한 이상을 실행하는 것은 소수자에게 해로울 수 있습니다.

• 최전선에 서도록 노력합시다. 우리는 실수로부터 무엇을 배울 수 있습니까? 모든 것을 예전처럼 하지 말자. 왜 우리가 하고 있는 일을 하는지 반성해보자. 사양을 자연어로 번역하는 작업을 합니다. 특히 사양이 진화할 때 최신 상태를 유지하기가 어렵습니다. 그것은 매우 길 수 있고 사람들이 읽기에 더 쉬울 수 있고 씹기에는 너무 많을 수 있습니다. 사양 내에서 주제를 찾으려고 제안합니다. 사양을 보는 방법을 배포하는 방법을 찾으십시오. 다양한 문제를 해결하기 위해 더 많은 자습서를 작성하십시오. 사양의 요소를 설명하는 블로그 게시물을 위한 공간도 있습니다. 씹을 수 있는 가슴살로 만들어보세요.

• 커밋을 제거할 수 있으며 되돌릴 수 있지만 되돌릴 수 있습니까? 커뮤니티를 되돌리면 커밋이 느려지므로 되돌리는 데 훨씬 더 오래 걸립니다. 항목이 이전 결정 위에 구축되었기 때문에 서버에서 되돌리기가 더 어렵습니다.

• 우리는 다른 프로젝트와 다르게 아무것도 하지 않습니다. 기간을 설정하는 것은 기존 관행과 다르지만, 우리가 하려는 것은 다른 모델을 구축하는 것이며, 이전 모델은 동질적인 그룹에 의해 지배되었으므로 과거 관행을 사용하거나 가장자리에 노력하려는 것입니다. 생각의? 이전 예에서 동일한 함정에 빠지지 않는 방법을 배우고 무엇이 효과가 있었는지 분석할 수 있습니까? 우리는 다를 것을 약속합니다. 과거에 효과가 있었던 것이 효과가 없었습니다.

• repos를 구별할 수 있습니까? 그렇다면 어떻게?

• 코드가 규칙과 다른가요? 노드 솔리드 서버는 커뮤니티 저장소 및 솔리드 사양과 마찬가지로 사회에 영향을 미칩니다. 그럼 어떻게 구별할까요? 특히 평가를 수행하는 전문가가 해석할 수 있는 언어가 아니기 때문에 정보에 액세스할 수 없는 경우에는 사회적 영향을 평가하기 어렵습니다.
• 솔리드 서버는 사회에 막대한 영향을 미치는 규범적인 소프트웨어이므로 코드 결정이 큰 영향을 미칩니다.
• 개별 pull 요청은 해당 속성이 없는 아주 작은 변경 사항입니다. 그것들은 우리의 마음을 감싸기 위해 변화를 점진적으로 만들기 위해 존재합니다. 질적으로나 양적으로 동일하지 않기 때문에 사회적 변화와 동일하지 않습니다.
• 3개의 사양 리포지토리와 커뮤니티 리포지토리는 정의된 최소 검토 기간 및 할당된 검토자와 같은 더 엄격한 프로세스를 가져야 합니다. 사양은 큰 규범적 영향을 미칩니다. 일반적으로 가질 수 있는 규범적 효과로 repos를 구별하는 좋은 방법입니다. 커뮤니티 리포지토리 및 견고한 사양이 해당 범주에 있습니다. 따라서 투명한 병합이 있으면 좋을 것입니다.

• 변경 사항이 사양에서 벗어나면 더 긴 검토 시간이 필요하다고 말하는 노드-고체-서버에 대한 하이브리드 규칙 세트가 있을 수 있습니다. 사양에서 벗어나 코드에서 사양을 구현하는 경우에도 프로세스가 중요합니다.

• 워크플로 및 단계가 문서화되어 있지 않습니다.

• 엔지니어는 엔지니어가 아닌 사람보다 파이프라인을 더 신뢰합니다. 어쩌면 우리는 이것을 믿고 있습니다. 어쩌면 요점이 있습니다. 개발자 문화의 인구 통계는 아마도 그래야 하는 방식이라고 생각하기 때문일 것입니다.
• 주요 결정은 실제로 기술적인 것 이상으로 막대한 영향을 미칠 때 기술적인 것으로 위장합니다.
• 코드는 사회에 엄청난 영향을 미칠 수 있으므로 영향을 이해하고 사람들이 참여할 수 있도록 하는 것이 중요합니다.
• 자연어 – 사양은 어떤 경우에도 약간의 상쾌함을 사용할 수 있습니다. 그렇게 하면 더 나은 설명 방법이 있습니다. 기술적인 요소를 비기술적인 것으로 다시 작성하는 것까지는 하지 않을 것입니다. 사양이 맞는지 확인하기 위해 사양의 가독성을 향상시킬 수 있는 기회가 있습니다. 테크니컬한 면모를 빼낸다는 반발이 거세다.
  
  
  
  • 우리는 모두가 받아들일 수 있고 이해할 수 있는 것을 만들어야 합니다.
  
  

@TallTed 이전 댓글의 회의록에 대해 의견이 있으신가요?

앞으로의 방법으로 다음을 제안합니다.

다음 repos와 관련된 pull 요청 및 문제는 최소 3일 동안 열려 있어야 합니다.
https://github.com/solid/solid-spec
https://github.com/solid/web-access-control-spec
https://github.com/solid/webid-oidc-spec
https://github.com/solid/community

다른 모든 repos와 관련된 pull 요청 및 문제는 즉시 닫을 수 있으며 최소 3일 동안 열어야 하는 사양에서 벗어나지 않는 한 열려 있어야 하는 최소 시간이 없습니다.

이의가 있으신가요?

나를 위해 작동합니다. 또한 릴리스 관리자의 역할 설명에 텍스트를 추가하여 나머지 리포지토리로 수행해야 하는 작업을 설명할 수도 있습니다.

이 솔루션도 마음에 듭니다. :smile_cat: 추론을 어딘가에 적어 두어 사람들이 그 뒤에 있는 우리의 생각을 이해할 수 있도록 합시다.

@kjetilk 예, https://github.com/solid/community/pull/44 에 메모를 추가하겠습니다.

@megoth ok는 커뮤니티 리포지토리 추가 정보에 간략한 설명을 포함합니다.

https://github.com/solid/community/blob/master/README.md