<!-- vale gitlab.FutureTense = NO -->

이 문서는 진행 중인 작업이며, 셀 디자인의 매우 초기 상태를 나타냅니다. 중요한 측면들이 문서화되지 않았지만, 우리는 향후 이를 추가할 것으로 예상합니다. 이것은 하나의 셀 아키텍처이며, 이를 구현할 접근 방법을 결정하기 전에 이를 다른 방법과 대조할 것입니다. 우리가 이 접근 방식을 선택하지 않기로 결정하더라도, 접근 방식을 선택하지 않은 이유를 문서화할 수 있도록 이 문서는 보관됩니다.

# Cells: Contributions: Forks

[forking workflow](../../../../user/project/repository/forking_workflow.md)은 사용자가 기존 프로젝트 소스를 자신이 선택한 네임스페이스(개인 또는 그룹)로 복사할 수 있는 워크플로우입니다.

## 1. 정의

[forking workflow](../../../../user/project/repository/forking_workflow.md)은 다양한 사용 패턴을 가진 일반적인 워크플로우입니다:

- 사용자가 upstream 프로젝트로 다시 기여할 수 있습니다.
- 저장소를 개인 네임스페이스에 유지합니다.
- 사용자는 프로젝트를 복사하여 변경하고 수정된 프로젝트로 릴리스할 수 있습니다.

포크는 부모 프로젝트에 쓰기 액세스 권한이 없는 사용자도 변경을 가할 수 있게 합니다. 포킹 워크플로우는 오픈 소스 커뮤니티에서 다시 공개 프로젝트로 기여하는 데 특히 중요합니다. 그러나 책임을 엄격하게 분리하고 더 엄격한 액세스 제어를 선호하는 일부 회사에서도 동일하게 중요합니다. 프로젝트 액세스는 지정된 개발자 목록으로 제한됩니다.

포크는 다음을 가능하게 합니다:

- upstream 프로젝트를 수정할 수 있는 사용자를 더 엄격하게 제어합니다.
- 책임을 분리합니다: 부모 프로젝트는 프로덕션 시스템에 연결된 CI 구성을 사용할 수 있습니다.
- 포크에서 CI 파이프라인을 더 제한적인 환경에서 실행합니다.
- 모든 포크를 심사하지 않은 것으로 간주하여 프로젝트에 묶여있는 비밀이나 기타 정보의 유출 위험을 줄입니다.

셀 아키텍처에서 포킹 모델은 다음 이유로 문제가 됩니다:

- 포크는 기존 저장소의 복제본입니다. 포크는 다른 조직, 셀 및 Gitaly 샤드에 걸쳐 생성될 수 있습니다.
- 사용자는 병합 요청을 생성하고 upstream 프로젝트로 기여할 수 있습니다. 그러나 이 upstream 프로젝트는 다른 조직 및 셀에 있을 수 있습니다.
- 병합 요청 CI 파이프라인은 소스 프로젝트의 컨텍스트에서 실행되지만 대상 프로젝트의 위치에서 표시됩니다.

## 2. 데이터 탐색

[데이터 탐색](https://gitlab.com/gitlab-data/product-analytics/-/issues/1380)에서 다음과 같은 기존 포크에 대한 정보를 검색했습니다:

- 현재 GitLab.com에는 대략 180만 개의 포크가 있습니다.
- 대부분의 포크는 개인 네임스페이스에 속합니다(82%).
- 동일한 최상위 그룹 및/또는 조직 내부에서 포크를 최소한으로 사용할 것으로 예상했습니다. 포킹은 프로젝트에 액세스할 권한이 없는 사용자를 위해만 필요합니다. 회사 내부에서는 팀 구성원 간에 권한이 다른 경우에만 포킹 워크플로우를 크게 사용하지 않을 것으로 예상합니다. 그러나 데이터에 따르면 9% 만이 일치하는 최상위 부모 네임스페이스 식별자(최상위 그룹 및 개인 네임스페이스)를 가지는 포크 관계가 있었습니다. 나머지 91%의 포크 관계는 다른 최상위 네임스페이스를 가로지르는 포크였습니다. 최상위 그룹을 식별 가능한 회사에 매칭하려고 시도했을 때:
  - 활동이 있는 최상위 그룹의 9% (95,000 개)가 포크 관계를 가진 프로젝트를 가졌습니다. 반면, 활동이 없는 최상위 그룹의 5% (91,000 개)가 지난 12개월 동안 활동이 없었습니다. 이러한 최상위 그룹이 Cells에 의해 영향을 받을 것으로 예상합니다.

## 3. 제안

### 3.1. 포크는 현재 조직의 전용 기여 공간에 생성됩니다

조직을 가리키는 전체를 설정하기 때문에 새로운 프로젝트를 생성할 필요 없이 해당 조직 내의 전용 기여 공간에 포크를 만들 수 있습니다.
기여 공간은 기본 조직 내부에 존재하는 개인 네임스페이스와 비슷하지만, 기여하려는 조직 내부에 존재합니다.
예를 들면:
- 어떤 사용자라도 조직을 볼 수 있는(User는 모든 공개 조직을 볼 수 있음) 경우, 사용자는 그 조직에서 기여 공간을 만들 수 있습니다. 이것은 해당 조직 내의 프로젝트를 포크할 수 있는 전용 네임스페이스로, 예를 들어 `Produce Inc.`의 경우 `gitlab.com/organization/produce-inc/@ayufan`일 수 있습니다.
- 기여 공간을 생성하기 위해 사용자에게 그 조직의 멤버십을 요구하지 않습니다. 그렇지 않으면 사용자가 그룹이나 프로젝트에 초대되지 않고도 포킹 및 병합 요청을 만들 수 있는 오픈 소스 워크플로우가 방해될 것이기 때문입니다. 우리는 엄격하게 가시성을 존중하기 때문에 사용자는 초대 없이 비공개 조직에 포크를 만들 수 없습니다.
- 사용자가 프로젝트를 포크할 때 사용자가 해당 조직 내의 그룹에서만 포크를 만들 수 있도록 제시합니다. 또한 사용자에게 기여 공간을 만들고 포크를 거기에 넣을 옵션을 제공합니다. 현재 포크를 만들 때도 새로운 그룹을 만들 수 있는 "그룹 만들기" 옵션이 있습니다. 이 기능 또한 새로운 포크를 저장할 조직 내의 새 그룹을 만드는 데로 제한될 것입니다.
- 기여를 하지 않고 포크를 만들고 싶어하는 사용자를 지원하기 위해, 권한이 있는 네임스페이스에 [연결되지 않은 포크](../../../../user/project/repository/forking_workflow.md#unlink-a-fork)를 만들 수 있는 옵션을 고려할 수 있습니다.
- 사용자는 기여하는 조직의 기여 공간 수만큼 가질 수 있습니다.
- 사용자는 기여 공간 내에 추가적인 개인 프로젝트를 만들 수 없습니다. 개인 프로젝트는 여전히 개인 네임스페이스에 만들 수 있습니다.
- 조직은 기여 공간을 방지하거나 비활성화할 수 있습니다. 이는 그 조직 내의 그룹에 속하지 않은 사람이 포크를 만들 수 없도록 합니다.
- 현재 포크는 사용자의 조직 내의 기여 공간으로 이동됩니다. 포크가 상위 프로젝트 외부 데이터로 링크되어 있는 경우, 데이터 손실이 발생할 수 있으므로 해당 개인 프로젝트를 보관하고 포크 관계를 제거할 것입니다.
- 모든 포크는 조직의 일부입니다.
- 포크는 연방 기능이 아닙니다.
- 기여 공간 및 포크된 프로젝트는 부모 프로젝트와 구성을 공유하지 않습니다.
- 만약 조직이 삭제되면, 포크를 포함하는 프로젝트는 기본 조직으로 이동하거나, 구체적으로 이전 조직의 유령 조직을 만들어 그 안에 들어갈 것입니다.
- 고객 사용량 관점에서 고객 사용 기여 공간의 데이터는 기여하지 않습니다.
- 우리는 현재 조직 범위의 러너를 가지고 있지 않지만, 그들이 구현된다면 기여 공간 프로젝트에서 어떻게 또는 왜 사용될 수 있는 특별한 설정이 필요할 것으로 예상됩니다.