rfcs
1.0.0
버그 수정 및 문서 개선을 포함한 많은 변경 사항은 일반적인 GitHub 끌어오기 요청 워크플로를 통해 구현되고 검토될 수 있습니다.
그러나 일부 변경 사항은 "상당한" 것이므로 우리는 이러한 변경 사항이 약간의 설계 프로세스를 거쳐 React 핵심 팀 간의 합의를 이끌어낼 것을 요청합니다.
"RFC"(의견 요청) 프로세스는 새로운 기능이 프로젝트에 포함될 수 있도록 일관되고 제어된 경로를 제공하기 위한 것입니다.
활성 RFC 목록
귀하의 풀 요청을 수락하려면 CLA를 제출해야 합니다. 이 작업은 한 번만 수행하면 되므로 다른 Facebook 오픈 소스 프로젝트에 대해 이 작업을 수행했다면 그대로 진행하면 됩니다. 처음으로 끌어오기 요청을 제출하는 경우 CLA를 완료했다는 사실을 알려주시면 GitHub 사용자 이름으로 대조 확인할 수 있습니다.
여기에서 CLA를 완료하세요.
React나 해당 문서에 "상당한" 변경을 가하려는 경우 이 프로세스를 사용하는 것을 고려해야 합니다. RFC의 이점을 누릴 수 있는 몇 가지 예는 다음과 같습니다.
새로운 API 노출 영역을 생성하고 도입되는 경우 기능 플래그가 필요한 새로운 기능입니다.
릴리스 채널의 일부로 이미 제공된 기능을 제거합니다.
React 자체에 대한 코드 변경 사항이 포함되지 않더라도 새로운 관용적 사용법이나 규칙이 도입됩니다.
일부 변경에는 RFC가 필요하지 않습니다.
표현 변경, 재구성 또는 리팩토링
경고 추가 또는 제거
객관적이고 수치적인 품질 기준을 엄격하게 개선하는 추가 기능(속도 향상, 브라우저 지원 개선)
추가 사항은 다른 React 구현자 에게만 인식 될 가능성이 높으며 React 사용자에게는 보이지 않습니다.
승인될 RFC를 작성하는 것은 어렵습니다. 그럼에도 불구하고 이것이 당신이 글을 쓰는 것을 방해해서는 안 됩니다.
React는 API 노출 영역이 매우 제한되어 있으며 각 기능은 다른 모든 기능과 원활하게 작동해야 합니다. 매일 React를 풀타임으로 작업하는 팀원들 사이에서도 좋은 RFC를 작성하는 데 충분한 컨텍스트를 얻고 확보하는 데 1년 이상이 걸립니다.
실제로 React RFC는 두 가지 목적으로 사용됩니다.
React Team RFC는 광범위한(때로는 수개월 또는 수년에 걸쳐) 설계, 토론 및 실험을 거친 후 React 팀 구성원이 제출합니다. 실제로는 지금까지 병합된 RFC의 대부분을 구성합니다. 이러한 RFC의 목적은 커뮤니티를 위한 디자인을 미리 보고 피드백 기회를 제공하는 것입니다. 우리는 우리가 게시한 RFC에 대한 모든 의견을 읽고, 질문에 응답하고, 때로는 피드백을 제안서에 통합합니다. 시간이 제한되어 있기 때문에 디자인에 적합하다고 확신하지 않는 한 React 기능에 대한 RFC를 작성하지 않는 경향이 있습니다. 대부분의 React Team RFC가 쉽게 받아들여지는 것처럼 보일 수도 있지만 실제로는 아이디어의 98%가 편집실에 남아 있기 때문입니다. 우리가 매우 확신하고 팀 합의를 갖고 있는 나머지 2%는 커뮤니티 피드백을 위한 RFC로 발표하는 것입니다.
커뮤니티 RFC는 누구나 제출할 수 있습니다. 실제로 대부분의 커뮤니티 RFC는 병합되지 않습니다. 우리가 RFC를 거부하는 가장 일반적인 이유는 상당한 디자인 격차나 결함이 있거나, 다른 모든 기능과 응집력 있게 작동하지 않거나, React의 범위에 대한 우리의 관점에 속하지 않기 때문입니다. 그러나 병합이 RFC의 유일한 성공 기준은 아닙니다. API 디자인이 우리가 원하는 방향과 일치하지 않더라도 RFC 토론은 연구와 영감을 얻는 데 매우 가치가 있다고 생각합니다. 커뮤니티 RFC를 항상 적시에 검토하지는 않지만, 관련 영역에 대한 작업을 시작할 때마다 해당 영역의 RFC를 확인하고 커뮤니티 구성원이 게시한 사용 사례와 우려 사항을 검토합니다. RFC를 보낼 때 주요 목표는 반드시 그대로 React에 병합하는 것이 아니라 커뮤니티 구성원과 풍부한 토론을 생성하는 것입니다. 귀하의 제안이 나중에 승인된다면 정말 좋습니다. 하지만 그렇지 않더라도 헛되지는 않을 것이다. 결과 토론은 커뮤니티에서 왔든 React 팀에서 왔든 동일한 문제 공간의 다음 제안을 알리는 경우가 많습니다. 많은 라이브러리 작성자가 토론을 읽고 있으므로 RFC는 종종 커뮤니티 실험 및 사용자 영역 솔루션으로 이어집니다.
우리는 React Team RFC와 커뮤니티 RFC 모두에 동일한 수준의 엄격함을 적용합니다. 이들 사이의 주요 차이점은 디자인 단계에 있습니다. React Team RFC는 디자인 프로세스가 끝날 때 제출되는 경향이 있는 반면, 커뮤니티 RFC는 시작하기 위한 방법으로 처음에 제출되는 경향이 있습니다.
간단히 말해서, React에 주요 기능을 추가하려면 일반적으로 먼저 RFC를 마크다운 파일로 RFC 저장소에 병합해야 합니다. 그 시점에서 RFC는 '활성' 상태이며 최종적으로 React에 포함된다는 목표로 구현될 수 있습니다.
RFC 저장소 http://github.com/reactjs/rfcs를 포크하십시오.
0000-template.md text/0000-my-feature.md 에 복사합니다(여기서 'my-feature'는 설명입니다. 아직 RFC 번호를 할당하지 마세요).
RFC를 작성합니다. 세부 사항에 주의하세요. 설득력 있는 동기를 제시하지 않거나, 디자인의 영향에 대한 이해를 보여주지 않거나, 단점이나 대안에 대해 솔직하지 않은 RFC는 제대로 받아들여지지 않는 경향이 있습니다 .
끌어오기 요청을 제출하세요. 끌어오기 요청을 통해 RFC는 더 큰 커뮤니티로부터 디자인 피드백을 받게 되며 작성자는 이에 대한 응답으로 이를 수정할 준비를 해야 합니다.
합의를 구축하고 피드백을 통합하세요. 광범위한 지원을 받는 RFC는 아무런 의견도 받지 못하는 RFC보다 진전을 이룰 가능성이 훨씬 더 높습니다.
결국 팀은 RFC가 React에 포함될 후보인지 여부를 결정할 것입니다. 팀 검토에는 시간이 오래 걸릴 수 있으므로 먼저 커뮤니티 구성원에게 검토를 요청하는 것이 좋습니다.
React에 포함될 후보인 RFC는 달력일로 3일 동안 지속되는 "최종 의견 기간"에 들어갑니다. 이 기간의 시작은 RFC 풀 요청에 대한 설명과 태그를 통해 알립니다.
RFC는 팀과 커뮤니티의 피드백을 기반으로 수정될 수 있습니다. 중요한 수정 사항이 있으면 새로운 최종 의견 제시 기간이 시작될 수 있습니다.
공개 토론이 마무리되고 거부 이유를 요약하는 의견이 제시된 후 팀에서 RFC를 거부할 수 있습니다. 그러면 팀 구성원이 RFC 관련 풀 요청을 닫아야 합니다.
RFC는 최종 의견 수렴 기간이 끝나면 승인될 수 있습니다. 팀 구성원은 RFC와 관련된 풀 요청을 병합하며, 이 시점에서 RFC는 '활성' 상태가 됩니다.
RFC가 활성화되면 작성자는 이를 구현하고 해당 기능을 React 저장소에 풀 요청으로 제출할 수 있습니다. '활성화'된다는 것은 고무적인 스탬프가 아니며, 특히 기능이 궁극적으로 병합된다는 의미는 아닙니다. 이는 핵심 팀이 원칙적으로 이에 동의했으며 이를 병합할 수 있음을 의미합니다.
더욱이 특정 RFC가 승인되어 '활성'이라는 사실은 해당 RFC 구현에 어떤 우선순위가 할당되어 있는지 또는 현재 누군가가 작업 중인지 여부를 의미하지 않습니다.
활성 RFC에 대한 수정은 후속 PR에서 수행될 수 있습니다. 우리는 기능의 최종 디자인을 반영하는 방식으로 각 RFC를 작성하려고 노력합니다. 그러나 프로세스의 특성상 병합된 모든 RFC가 다음 주요 릴리스 시점의 최종 결과를 실제로 반영할 것으로 기대할 수는 없습니다. 따라서 우리는 각 RFC 문서를 계획대로 언어 기능과 어느 정도 동기화 상태로 유지하려고 노력하며 문서에 대한 후속 풀 요청을 통해 이러한 변경 사항을 추적합니다.
RFC 작성자는 RFC를 구현할 의무가 없습니다. 물론, RFC 작성자(다른 개발자와 마찬가지로)는 RFC가 승인된 후 검토를 위해 구현을 게시하는 것을 환영합니다.
'활성' RFC 구현 작업에 관심이 있지만 다른 사람이 이미 작업 중인지 확인할 수 없는 경우 언제든지 문의하십시오(예: 관련 문제에 대한 의견을 남겨주세요).
현재 React 팀은 적시에 RFC 검토를 약속할 수 없습니다. RFC를 제출할 때 주요 목표는 커뮤니티 피드백을 요청하고 풍부한 토론을 생성하는 것입니다. React 팀은 몇 달에 한 번씩 현재 프로젝트 목록과 우선순위를 재평가합니다. RFC가 잘 설계되었더라도 즉시 통합할 수 없는 경우가 많습니다. 그러나 우리는 공개 RFC를 몇 달에 한 번씩 다시 방문하여 눈에 띄는 것이 있는지 확인하는 것이 매우 중요하다고 생각합니다. 새로운 문제 공간에 대한 작업을 시작할 때마다 관련 RFC의 이전 작업과 토론을 확인하고 이에 참여합니다.
우리는 제출 후 몇 주 이내에 모든 RFC를 읽었습니다. 디자인이 React에 잘 맞는다고 생각하고, 평가할 준비가 된다면 더 빨리 검토하도록 노력하겠습니다. 디자인에 대해 주저하거나 평가할 정보가 충분하지 않은 경우 충분한 커뮤니티 피드백을 받을 때까지 공개해 두겠습니다. 시기적절한 검토를 받지 못하는 것이 실망스럽다는 것을 알고 있지만 RFC에 쏟은 노력 중 어느 것도 헛되지 않았다는 것을 확신하실 수 있습니다.
React의 RFC 프로세스는 Yarn RFC 프로세스, Rust RFC 프로세스 및 Ember RFC 프로세스에서 영감을 얻었습니다.
과거에는 피드백에 따라 변경했으며, 필요한 경우 다시 변경할 수 있습니다.
