Quy trình TensorFlow RFC

Mọi tính năng TensorFlow mới đều bắt đầu hoạt động dưới dạng Yêu cầu Nhận xét (RFC).

RFC là một tài liệu mô tả một yêu cầu và những thay đổi được đề xuất để giải quyết nó. Cụ thể, RFC sẽ:

• Được định dạng theo mẫu RFC .
• Được gửi dưới dạng yêu cầu kéo tới thư mục cộng đồng/rfcs .
• Có thể thảo luận và họp xem xét trước khi chấp nhận.

Mục đích của Yêu cầu nhận xét (RFC) của TensorFlow là để thu hút cộng đồng TensorFlow vào quá trình phát triển, bằng cách nhận phản hồi từ các bên liên quan và chuyên gia, đồng thời truyền đạt các thay đổi thiết kế một cách rộng rãi.

Cách gửi RFC

1. Trước khi gửi RFC, hãy thảo luận về mục tiêu của bạn với những người đóng góp và bảo trì dự án và nhận phản hồi sớm. Sử dụng danh sách gửi thư của nhà phát triển cho dự án liên quan (developers@tensorflow.org hoặc danh sách dành cho SIG có liên quan).

2. Dự thảo RFC của bạn.

   • Đọc tiêu chí đánh giá thiết kế
   • Thực hiện theo mẫu RFC .
   • Đặt tên tệp RFC của bạn YYYYMMDD-descriptive-name.md , trong đó YYYYMMDD là ngày gửi và descriptive-name liên quan đến tiêu đề RFC của bạn. (Ví dụ: nếu RFC của bạn có tiêu đề Parallel Widgets API , bạn có thể sử dụng tên tệp 20180531-parallel-widgets.md .
   • Nếu bạn có hình ảnh hoặc các tệp phụ trợ khác, hãy tạo một thư mục có dạng YYYYMMDD-descriptive-name để lưu trữ các tệp đó.

   Sau khi viết bản nháp RFC, hãy nhận phản hồi từ những người bảo trì và cộng tác viên trước khi gửi nó.

   Viết mã triển khai không phải là một yêu cầu bắt buộc nhưng nó có thể giúp thiết kế các cuộc thảo luận.

3. Tuyển dụng một nhà tài trợ.

   • Nhà tài trợ phải là người duy trì dự án.
   • Xác định nhà tài trợ trong RFC trước khi đăng PR.

   Bạn có thể đăng RFC mà không có nhà tài trợ, nhưng nếu trong vòng một tháng kể từ khi đăng bài PR mà vẫn không có nhà tài trợ thì nó sẽ bị đóng.

4. Gửi RFC của bạn dưới dạng yêu cầu kéo tới tensorflow/community/rfcs .

   Bao gồm bảng tiêu đề và nội dung của phần Mục tiêu trong nhận xét về yêu cầu kéo của bạn bằng cách sử dụng Markdown. Để biết ví dụ, vui lòng xem ví dụ RFC này . Bao gồm tên GitHub của đồng tác giả, người đánh giá và nhà tài trợ.

   Ở đầu phần PR xác định thời gian bình luận sẽ kéo dài bao lâu. Việc này phải mất tối thiểu hai tuần kể từ khi đăng PR.

5. Gửi email cho danh sách gửi thư của nhà phát triển kèm theo mô tả ngắn gọn, liên kết tới PR và yêu cầu xem xét. Thực hiện theo định dạng của các thư trước đó, như bạn có thể thấy trong ví dụ này .

6. Nhà tài trợ sẽ yêu cầu một cuộc họp ủy ban đánh giá, không sớm hơn hai tuần sau khi RFC PR được đăng. Nếu cuộc thảo luận sôi nổi, hãy đợi cho đến khi nó ổn định trước khi xem xét. Mục tiêu của cuộc họp rà soát là giải quyết các vấn đề nhỏ; cần đạt được sự đồng thuận trước về các vấn đề quan trọng.

7. Cuộc họp có thể phê duyệt RFC, từ chối hoặc yêu cầu thay đổi trước khi có thể xem xét lại. Các RFC được phê duyệt sẽ được hợp nhất thành cộng đồng/rfcs và các RFC bị từ chối sẽ bị đóng PR.

người tham gia RFC

Nhiều người tham gia vào quá trình RFC:

• Tác giả RFC - một hoặc nhiều thành viên cộng đồng viết RFC và cam kết ủng hộ nó trong suốt quá trình

• Nhà tài trợ RFC - nhà bảo trì tài trợ cho RFC và sẽ hướng dẫn nó thông qua quá trình xem xét RFC

• ủy ban đánh giá - một nhóm người bảo trì có trách nhiệm đề xuất áp dụng RFC

• Bất kỳ thành viên cộng đồng nào cũng có thể trợ giúp bằng cách cung cấp phản hồi về việc liệu RFC có đáp ứng được nhu cầu của họ hay không.

nhà tài trợ RFC

Nhà tài trợ là người duy trì dự án chịu trách nhiệm đảm bảo kết quả tốt nhất có thể của quy trình RFC. Điêu nay bao gôm:

• Vận động cho thiết kế được đề xuất.
• Hướng dẫn RFC tuân thủ các quy ước về phong cách và thiết kế hiện có.
• Hướng dẫn hội đồng xét duyệt đi đến thống nhất hiệu quả.
• Nếu ủy ban đánh giá yêu cầu thay đổi, hãy đảm bảo những thay đổi này được thực hiện và xin phê duyệt sau đó từ các thành viên ủy ban.
• Nếu RFC chuyển sang triển khai:
  • Đảm bảo việc thực hiện đề xuất tuân thủ thiết kế.
  • Phối hợp với các bên thích hợp để thực hiện đất đai thành công.

Ủy ban đánh giá RFC

Ủy ban đánh giá quyết định trên cơ sở đồng thuận về việc chấp thuận, từ chối hay yêu cầu thay đổi. Họ chịu trách nhiệm về:

• Đảm bảo rằng các nội dung phản hồi quan trọng của công chúng đã được tính đến.
• Thêm ghi chú cuộc họp của họ làm nhận xét cho bài PR.
• Cung cấp lý do cho quyết định của họ.

Cơ cấu của ủy ban đánh giá có thể thay đổi tùy theo phong cách quản lý và lãnh đạo cụ thể của từng dự án. Đối với TensorFlow cốt lõi, ủy ban sẽ bao gồm những người đóng góp cho dự án TensorFlow, những người có chuyên môn trong lĩnh vực miền liên quan.

Các thành viên cộng đồng và quy trình RFC

Mục đích của RFC là đảm bảo cộng đồng được đại diện tốt và được phục vụ bởi những thay đổi mới đối với TensorFlow. Trách nhiệm của các thành viên cộng đồng là tham gia đánh giá RFC khi họ quan tâm đến kết quả.

Các thành viên cộng đồng quan tâm đến RFC nên:

• Cung cấp phản hồi càng sớm càng tốt để có đủ thời gian xem xét.
• Đọc kỹ RFC trước khi đưa ra phản hồi.
• Hãy văn minh và mang tính xây dựng .

Triển khai các tính năng mới

Khi RFC đã được phê duyệt, việc triển khai có thể bắt đầu.

Nếu bạn đang làm việc với mã mới để triển khai RFC:

• Đảm bảo bạn hiểu tính năng và thiết kế được phê duyệt trong RFC. Đặt câu hỏi và thảo luận về cách tiếp cận trước khi bắt đầu công việc.
• Các tính năng mới phải bao gồm các bài kiểm tra đơn vị mới để xác minh tính năng này hoạt động như mong đợi. Bạn nên viết những bài kiểm tra này trước khi viết mã.
• Làm theo Hướng dẫn về kiểu mã TensorFlow
• Thêm hoặc cập nhật tài liệu API có liên quan. Tham khảo RFC trong tài liệu mới.
• Thực hiện theo bất kỳ nguyên tắc nào khác được trình bày trong tệp CONTRIBUTING.md trong kho lưu trữ dự án mà bạn đang đóng góp.
• Chạy thử nghiệm đơn vị trước khi gửi mã của bạn.
• Làm việc với nhà tài trợ RFC để nhận được mã mới thành công.

Giữ thanh cao

Mặc dù chúng tôi khuyến khích và tôn vinh mọi người đóng góp nhưng tiêu chuẩn chấp nhận RFC vẫn được cố tình duy trì ở mức cao. Một tính năng mới có thể bị từ chối hoặc cần sửa đổi đáng kể ở bất kỳ giai đoạn nào sau đây:

• Cuộc trò chuyện thiết kế ban đầu trên danh sách gửi thư có liên quan.
• Không tuyển được nhà tài trợ.
• Những phản đối quan trọng trong giai đoạn phản hồi.
• Không đạt được sự đồng thuận trong quá trình xem xét thiết kế.
• Những lo ngại nảy sinh trong quá trình triển khai (ví dụ: không có khả năng đạt được khả năng tương thích ngược, lo ngại về việc bảo trì).

Nếu quá trình này hoạt động tốt, RFC dự kiến ​​sẽ thất bại ở các giai đoạn sớm hơn thay vì muộn hơn. RFC được phê duyệt không đảm bảo cho cam kết thực hiện và việc chấp nhận triển khai RFC được đề xuất vẫn phải tuân theo quy trình xem xét mã thông thường.

Nếu bạn có bất kỳ câu hỏi nào về quy trình này, vui lòng hỏi trong danh sách gửi thư của nhà phát triển hoặc gửi vấn đề trong tensorflow/community .