새로운 TensorFlow 특성은 언제나 Request for Comment(RFC)로 시작합니다.
RFC는 요구 사항과 이를 해결하기 위해 제안된 변경 사항을 설명하는 문서입니다. 구체적으로 RFC는 다음과 같이 사용됩니다.
- RFC 템플릿의 형식을 따릅니다.
- community/rfcs 디렉토리에 풀 요청으로 제출합니다.
- 수락하기 전에 토론 및 검토 회의를 거칩니다.
TensorFlow RFC의 목적은 이해 관계자 및 전문가로부터 피드백을 받고 설계 변경을 광범위하게 전달함으로써 TensorFlow 커뮤니티를 개발에 참여시키는 것입니다.
RFC를 제출하는 방법
RFC를 제출하기 전에 프로젝트 기여자 및 관리자와 목표를 논의하고 초기 피드백을 받습니다. 해당 프로젝트에 대한 개발자 메일 그룹(developers@tensorflow.org 또는 관련 SIG 목록)를 사용합니다.
RFC 초안을 작성합니다.
- RFC 템플릿을 따릅니다.
- RFC 파일 이름을
YYYYMMDD-descriptive-name.md로 지정합니다. 여기서YYYYMMDD는 제출 날짜이고descriptive-name은 RFC 제목과 관련됩니다. 예를 들어, RFC의 제목이 Parallel Widgets API인 경우20180531-parallel-widgets.md의 파일 이름을 사용할 수 있습니다. - 이미지 또는 다른 보조 파일이 있는 경우 해당 파일을 저장할
YYYYMMDD-descriptive-name형식의 디렉토리를 만듭니다.
RFC 초안을 작성한 후 제출하기 전에 관리자 및 기여자로부터 피드백을 받습니다.
구현 코드 작성은 필수 사항은 아니지만 설계 토론에 도움이 될 수 있습니다.
스폰서를 모집합니다.
- 스폰서는 프로젝트의 관리자여야 합니다.
- PR을 게시하기 전에 RFC에 스폰서를 나타냅니다.
스폰서 없이 RFC를 게시할 수는 있지만 PR을 게시하고 한 달이 지나도 스폰서가 없으면 PR이 닫힙니다.
tensorflow/community/rfcs에 풀 요청으로 RFC를 제출합니다.
Markdown을 사용하여 풀 요청의 주석에 헤더 테이블과 목표 섹션의 내용을 포함합니다. 예를 들어, 이 RFC 예를 참조하세요. 공동 저자, 검토자 및 스폰서의 GitHub 핸들을 포함시킵니다.
PR의 맨 위에 주석 기간이 얼마나 걸리는지 나타냅니다. 이 기간은 PR 게시 후 최소 2주는 되어야 합니다.
간략한 설명, PR 링크 및 검토 요청과 함께 개발자 메일 그룹에 이메일을 보냅니다. 이 예에서 볼 수 있듯이 이전 메일 형식을 따릅니다.
스폰서는 RFC PR이 게시되고 최소 2주가 지난 후에 검토 위원회 회의를 요청합니다. 토론이 활발할 경우 안정화된 다음에 검토 과정으로 넘어갑니다. 검토 회의의 목표는 사소한 문제를 해결하는 것입니다. 주요 문제에 대해서는 사전에 합의에 도달해야 합니다.
회의에서 RFC를 승인하거나 거부하거나, 변경을 요청한 후에 다시 고려 수 있습니다. 승인된 RFC는 community/rfcs로 병합되며 거부된 RFC는 해당 PR이 닫힙니다.
RFC 참가자
많은 사람들이 RFC 프로세스에 참여합니다.
RFC 저자 — RFC를 작성하고 프로세스를 통해 RFC를 옹호하는 한 명 이상의 커뮤니티 구성원입니다.
RFC 스폰서 — RFC를 후원하고 RFC 검토 프로세스를 통해 RFC를 관리하는 관리자입니다.
검토 위원회 — RFC 채택을 권고하는 일을 담당한 관리자 그룹입니다.
모든 커뮤니티 구성원은 RFC가 필요성을 충족하는지 여부에 대한 피드백을 제공함으로써 도움을 줄 수 있습니다.
RFC 스폰서
스폰서는 RFC 프로세스에서 최상의 결과를 보장하는 일을 담당한 프로젝트 관리자입니다. 주요 작업 내용은 다음과 같습니다.
- 제안된 설계를 옹호합니다.
- 기존 설계와 스타일 규칙을 준수하도록 RFC를 이끕니다.
- 검토 위원회가 생산적인 합의에 도달하도록 유도합니다.
- 검토 위원회가 변경을 요청하는 경우 변경이 이루어졌는지 확인하고 위원회 구성원의 후속 승인을 받습니다.
- RFC가 구현 단계로 이동하는 경우:
- 제안된 구현이 설계를 준수하도록 합니다.
- 성공적인 구현에 이를 수 있게 해당 당사자들과 협력합니다.
RFC 검토 위원회
검토 위원회는 RFC를 승인 또는 거부할지, 아니면 변경을 요청할지 여부를 만장일치로 결정합니다. 구체적으로 다음과 같은 작업을 수행합니다.
- 실질적인 대중적 피드백 항목이 고려되도록 합니다.
- PR에 주석으로 회의록을 추가합니다.
- 결정에 대한 이유를 제공합니다.
검토 위원회의 구성은 각 프로젝트의 특정 관리 스타일과 리더십에 따라 달라질 수 있습니다. 핵심 TensorFlow의 경우, 위원회는 관련 분야에서 전문성을 가진 TensorFlow 프로젝트 기여자로 구성됩니다.
커뮤니티 구성원 및 RFC 프로세스
RFC의 목적은 TensorFlow의 새로운 변경 사항이 커뮤니티에 잘 제시 및 제공되도록 하는 것입니다. 결과에 관심이 있는 RFC 검토에 참여하는 것은 커뮤니티 구성원의 책임입니다.
RFC에 관심이 있는 커뮤니티 구성원은 다음을 수행해야 합니다.
- 적시에 고려될 수 있게 가능한 빠르게 피드백을 제공합니다.
- 피드백을 제공하기 전에 RFC를 자세히 읽습니다.
- 공민 의식을 가지고 건설적인 자세를 갖습니다.
새로운 특성 구현하기
RFC가 승인되면 구현을 시작할 수 있습니다.
RFC를 구현하기 위해 새 코드를 작성하는 경우:
- RFC에서 승인된 특성과 설계를 이해해야 합니다. 작업을 시작하기 전에 질문하고 접근 방식에 대해 논의합니다.
- 새로운 특성에는 특성이 예상대로 작동하는지 확인하는 새로운 단위 테스트가 포함되어야 합니다. 코드를 작성하기 전에 이러한 테스트를 작성하는 것이 좋습니다.
- TensorFlow 코드 스타일 가이드를 따릅니다.
- 관련 API 문서를 추가하거나 업데이트합니다. 새 문서에서 RFC를 참조합니다.
- 기여하고 있는 프로젝트 리포지토리의
CONTRIBUTING.md파일에 나와 있는 다른 지침을 따릅니다. - 코드를 제출하기 전에 단위 테스트를 실행합니다.
- RFC 스폰서와 협력하여 새 코드를 성공적으로 도입합니다.
기준을 높게 잡기
모든 기여자를 격려하고 칭찬해 주어야 하겠지만 이와 동시에 RFC 승인 기준은 의도적으로 높게 유지됩니다. 다음 단계 중 하나에서 새로운 특성이 거부되거나 상당한 개정이 필요할 수 있습니다.
- 관련 메일 그룹에서 이루어지는 초기 설계 대화
- 스폰서 모집에 실패
- 피드백 단계 중 중대한 이의가 제기됨
- 설계 검토 중 합의에 도달하지 못함
- 구현 중 우려 사항 제기(예: 이전 버전과 호환되지 않음, 유지관리의 문제점)
이 프로세스가 제대로 작동하면 RFC는 이후 단계가 아닌 초기 단계에서 거부될 것으로 예상됩니다. RFC가 승인되었더라도 구현이 된다는 보장은 없으며 제안된 RFC의 구현이 승인되어도 여전히 일반적인 코드 검토 프로세스를 거쳐야 합니다.
이 프로세스에 대한 질문이 있으면 개발자 메일 그룹에 자유롭게 질문하거나 tensorflow/community에서 관련 사안을 제출하세요.