กระบวนการ TensorFlow RFC
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
คุณสมบัติ TensorFlow ใหม่ทั้งหมดเริ่มต้นชีวิตด้วยการขอความคิดเห็น (RFC)
RFC เป็นเอกสารที่อธิบายข้อกำหนดและการเปลี่ยนแปลงที่เสนอซึ่งจะช่วยแก้ไขได้ โดยเฉพาะอย่างยิ่ง RFC จะ:
วัตถุประสงค์ของคำขอความคิดเห็น (RFC) ของ TensorFlow คือเพื่อดึงดูดชุมชน 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 แล้ว ให้รับคำติชมจากผู้ดูแลและผู้มีส่วนร่วมก่อนส่ง
การเขียนโค้ดการใช้งานไม่ใช่ข้อกำหนด แต่อาจช่วยในการออกแบบการอภิปรายได้
รับสมัครสปอนเซอร์.
- ผู้สนับสนุนจะต้องเป็นผู้ดูแลโครงการ
- ระบุผู้สนับสนุนใน RFC ก่อนที่จะโพสต์ PR
คุณ สามารถ โพสต์ RFC ได้โดยไม่ต้องมีผู้สนับสนุน แต่หากภายในหนึ่งเดือนหลังจากโพสต์ PR ยังไม่มีผู้สนับสนุน จะมีการปิดตัวลง
ส่ง RFC ของคุณเป็นคำขอดึงไปที่ tensorflow/community/rfcs
รวมตารางส่วนหัวและเนื้อหาของส่วน วัตถุประสงค์ ในความคิดเห็นของคำขอดึงของคุณโดยใช้ Markdown สำหรับตัวอย่าง โปรดดู ตัวอย่างนี้ RFC รวมการจัดการ GitHub ของผู้เขียนร่วม ผู้ตรวจสอบ และผู้สนับสนุน
ที่ด้านบนของ PR ระบุระยะเวลาแสดงความคิดเห็น ซึ่งควรใช้ เวลาอย่างน้อยสองสัปดาห์ นับจากการโพสต์ PR
ส่งอีเมลถึงรายชื่อผู้รับอีเมลของนักพัฒนาพร้อมคำอธิบายสั้นๆ ลิงก์ไปยัง PR และคำขอให้ตรวจสอบ ทำตามรูปแบบการส่งจดหมายครั้งก่อนๆ ดังที่คุณเห็นใน ตัวอย่างนี้
ผู้สนับสนุนจะขอให้มีการประชุมคณะกรรมการพิจารณาภายในไม่เกินสองสัปดาห์หลังจากโพสต์ RFC PR หากการพูดคุยเป็นไปอย่างมีชีวิตชีวา ให้รอจนกว่าจะคลี่คลายก่อนจึงจะเริ่มทบทวน เป้าหมายของการประชุมทบทวนคือการแก้ไขปัญหาเล็กๆ น้อยๆ ควรบรรลุฉันทามติในประเด็นสำคัญล่วงหน้า
ที่ประชุมอาจอนุมัติ RFC ปฏิเสธ หรือกำหนดให้มีการเปลี่ยนแปลงก่อนจึงจะได้รับการพิจารณาอีกครั้ง RFC ที่ได้รับการอนุมัติจะถูกรวมเข้ากับ community/rfcs และ RFC ที่ถูกปฏิเสธจะถูกปิด PR
ผู้เข้าร่วม RFC
หลายคนมีส่วนร่วมในกระบวนการ RFC:
ผู้เขียน RFC — สมาชิกชุมชนตั้งแต่หนึ่งคนขึ้นไปที่เขียน RFC และมุ่งมั่นที่จะสนับสนุน RFC ผ่านกระบวนการนี้
ผู้สนับสนุน RFC — ผู้ดูแลที่สนับสนุน RFC และจะดูแลผ่านกระบวนการตรวจสอบ RFC
คณะกรรมการตรวจสอบ - กลุ่มผู้ดูแลที่มีหน้าที่แนะนำการนำ RFC มาใช้
สมาชิกในชุมชน อาจช่วยเหลือโดยการให้ข้อเสนอแนะว่า RFC จะตอบสนองความต้องการของพวกเขาหรือไม่
ผู้สนับสนุนคือผู้ดูแลโครงการที่รับผิดชอบในการรับรองผลลัพธ์ที่ดีที่สุดของกระบวนการ RFC ซึ่งรวมถึง:
- การสนับสนุนสำหรับการออกแบบที่นำเสนอ
- ชี้แนะ RFC ให้ปฏิบัติตามแบบแผนการออกแบบและสไตล์ที่มีอยู่
- ชี้แนะคณะกรรมการพิจารณาเพื่อให้ได้ฉันทามติที่มีประสิทธิผล
- หากคณะกรรมการพิจารณาร้องขอการเปลี่ยนแปลง ตรวจสอบให้แน่ใจว่าได้ทำการเปลี่ยนแปลงแล้วและขออนุมัติในภายหลังจากสมาชิกคณะกรรมการ
- หาก RFC ย้ายไปใช้งาน:
- ตรวจสอบให้แน่ใจว่าการดำเนินการที่นำเสนอเป็นไปตามการออกแบบ
- ประสานงานกับฝ่ายที่เหมาะสมเพื่อดำเนินการที่ดินให้สำเร็จ
คณะกรรมการตรวจสอบ RFC
คณะกรรมการตรวจสอบจะตัดสินใจบนพื้นฐานที่เป็นเอกฉันท์ว่าจะอนุมัติ ปฏิเสธ หรือร้องขอการเปลี่ยนแปลง พวกเขามีความรับผิดชอบสำหรับ:
- ตรวจสอบให้แน่ใจว่ารายการสำคัญของผลตอบรับสาธารณะได้รับการนำมาพิจารณา
- การเพิ่มบันทึกการประชุมเป็นความคิดเห็นต่อ PR
- การให้เหตุผลในการตัดสินใจของพวกเขา
รัฐธรรมนูญของคณะกรรมการพิจารณาอาจมีการเปลี่ยนแปลงตามรูปแบบการกำกับดูแลและความเป็นผู้นำของแต่ละโครงการ สำหรับ TensorFlow หลัก คณะกรรมการจะประกอบด้วยผู้ร่วมโครงการ TensorFlow ที่มีความเชี่ยวชาญในด้านโดเมนที่เกี่ยวข้อง
สมาชิกชุมชนและกระบวนการ RFC
วัตถุประสงค์ของ RFC คือเพื่อให้แน่ใจว่าชุมชนได้รับการนำเสนออย่างดีและให้บริการโดยการเปลี่ยนแปลงใหม่ใน TensorFlow เป็นความรับผิดชอบของสมาชิกชุมชนในการมีส่วนร่วมในการทบทวน RFCs ที่พวกเขาสนใจในผลลัพธ์
สมาชิกชุมชนที่สนใจ RFC ควร:
- ให้ข้อเสนอแนะ โดยเร็วที่สุดเพื่อให้มีเวลาเพียงพอในการพิจารณา
- อ่าน RFC อย่างละเอียดก่อนแสดงความคิดเห็น
- เป็น พลเมืองและสร้างสรรค์
การใช้คุณสมบัติใหม่
เมื่อ RFC ได้รับการอนุมัติแล้ว การดำเนินการก็สามารถเริ่มต้นได้
หากคุณกำลังทำงานกับโค้ดใหม่เพื่อใช้ RFC:
- ตรวจสอบให้แน่ใจว่าคุณเข้าใจคุณลักษณะและการออกแบบที่ได้รับอนุมัติใน RFC ถามคำถามและหารือแนวทางก่อนเริ่มงาน
- คุณลักษณะใหม่จะต้องมีการทดสอบหน่วยใหม่ที่ตรวจสอบคุณลักษณะการทำงานตามที่คาดไว้ เป็นความคิดที่ดีที่จะเขียนการทดสอบเหล่านี้ก่อนที่จะเขียนโค้ด
- ปฏิบัติตาม คำแนะนำสไตล์โค้ด TensorFlow
- เพิ่มหรืออัปเดตเอกสาร API ที่เกี่ยวข้อง อ้างอิง RFC ในเอกสารประกอบใหม่
- ปฏิบัติตามแนวทางอื่นๆ ที่กำหนดไว้ในไฟล์
CONTRIBUTING.md ใน repo โปรเจ็กต์ที่คุณมีส่วนร่วม - รันการทดสอบหน่วยก่อนส่งโค้ดของคุณ
- ทำงานร่วมกับผู้สนับสนุน RFC เพื่อลงรหัสใหม่ให้สำเร็จ
รักษาบาร์ให้สูง
แม้ว่าเราจะสนับสนุนและเฉลิมฉลองผู้มีส่วนร่วมทุกคน แต่เกณฑ์การยอมรับ RFC ก็ยังคงอยู่ในระดับสูง คุณลักษณะใหม่อาจถูกปฏิเสธหรือต้องมีการแก้ไขที่สำคัญในขั้นตอนใดขั้นตอนหนึ่งต่อไปนี้:
- การสนทนาเกี่ยวกับการออกแบบเบื้องต้นในรายชื่อผู้รับจดหมายที่เกี่ยวข้อง
- ล้มเหลวในการรับสมัครสปอนเซอร์
- การคัดค้านอย่างมีวิจารณญาณในระหว่างขั้นตอนการตอบรับ
- ความล้มเหลวในการบรรลุฉันทามติในระหว่างการทบทวนการออกแบบ
- ข้อกังวลที่เกิดขึ้นระหว่างการใช้งาน (เช่น การไม่สามารถบรรลุความเข้ากันได้แบบย้อนหลัง ความกังวลเกี่ยวกับการบำรุงรักษา)
หากกระบวนการนี้ทำงานได้ดี RFC คาดว่าจะล้มเหลวในระยะก่อนหน้า แทนที่จะเกิดขึ้นในภายหลัง RFC ที่ได้รับอนุมัติไม่รับประกันถึงข้อผูกพันในการดำเนินการ และการยอมรับการนำ RFC ที่นำเสนอไปใช้ยังคงอยู่ภายใต้กระบวนการตรวจสอบโค้ดตามปกติ
หากคุณมีคำถามใดๆ เกี่ยวกับกระบวนการนี้ โปรดสอบถามจากรายชื่ออีเมลของนักพัฒนาหรือแจ้งปัญหาใน tensorflow/community
เนื้อหาของหน้าเว็บนี้ได้รับอนุญาตภายใต้ใบอนุญาตที่ต้องระบุที่มาของครีเอทีฟคอมมอนส์ 4.0 และตัวอย่างโค้ดได้รับอนุญาตภายใต้ใบอนุญาต Apache 2.0 เว้นแต่จะระบุไว้เป็นอย่างอื่น โปรดดูรายละเอียดที่นโยบายเว็บไซต์ Google Developers Java เป็นเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2023-12-01 UTC
[null,null,["อัปเดตล่าสุด 2023-12-01 UTC"],[],[],null,["# The TensorFlow RFC process\n\n\u003cbr /\u003e\n\nEvery new TensorFlow feature begins life as a Request for Comment (RFC).\n\nAn RFC is a document that describes a requirement and the proposed changes that\nwill solve it. Specifically, the RFC will:\n\n- Be formatted according to the [RFC template](https://github.com/tensorflow/community/blob/master/rfcs/yyyymmdd-rfc-template.md).\n- Be submitted as a pull request to the [community/rfcs](https://github.com/tensorflow/community/tree/master/rfcs) directory.\n- Be subject to discussion and a review meeting prior to acceptance.\n\nThe purpose of a TensorFlow Request for Comments (RFC) is to engage the\nTensorFlow community in development, by getting feedback from stakeholders and\nexperts, and communicating design changes broadly.\n\nHow to submit an RFC\n--------------------\n\n1. Before submitting an RFC, discuss your aims with project contributors and\n maintainers and get early feedback. Use the developer mailing list for the\n project concerned (developers@tensorflow.org, or the list for the relevant\n SIG).\n\n2. Draft your RFC.\n\n - Read the [design review criteria](https://github.com/tensorflow/community/blob/master/governance/design-reviews.md)\n - Follow the [RFC template](https://github.com/tensorflow/community/blob/master/rfcs/yyyymmdd-rfc-template.md).\n - Name your RFC file `YYYYMMDD-descriptive-name.md`, where `YYYYMMDD` is the date of submission, and `descriptive-name` relates to the title of your RFC. (For instance, if your RFC is titled *Parallel Widgets API* , you might use the filename `20180531-parallel-widgets.md`.\n - If you have images or other auxiliary files, create a directory of the form `YYYYMMDD-descriptive-name` in which to store those files.\n\n After writing the RFC draft, get feedback from maintainers and contributors\n before submitting it.\n\n Writing implementation code is not a requirement, but it may help design\n discussions.\n3. Recruit a sponsor.\n\n - A sponsor must be a maintainer of the project.\n - Identify the sponsor in the RFC, before posting the PR.\n\n You *may* post an RFC without a sponsor, but if within a month of posting\n the PR there is still no sponsor, it will be closed.\n4. Submit your RFC as a pull request to\n [tensorflow/community/rfcs](https://github.com/tensorflow/community/tree/master/rfcs).\n\n Include the header table and the contents of the *Objective* section in the\n comment of your pull request, using Markdown. For an example, please see\n [this example RFC](https://github.com/tensorflow/community/pull/5). Include\n the GitHub handles of co-authors, reviewers, and sponsors.\n\n At the top of the PR identify how long the comment period will be. This\n should be a *minimum of two weeks* from posting the PR.\n5. Email the developer mailing list with a brief description, a link to the PR\n and a request for review. Follow the format of previous mailings, as you can\n see in\n [this example](https://groups.google.com/a/tensorflow.org/forum/#!topic/developers/PIChGLLnpTE).\n\n6. The sponsor will request a review committee meeting, no sooner than two\n weeks after the RFC PR is posted. If discussion is lively, wait until it has\n settled before going to review. The goal of the review meeting is to resolve\n minor issues; consensus should be reached on major issues beforehand.\n\n7. The meeting may approve the RFC, reject it, or require changes before it can\n be considered again. Approved RFCs will be merged into\n [community/rfcs](https://github.com/tensorflow/community/tree/master/rfcs),\n and rejected RFCs will have their PRs closed.\n\nRFC participants\n----------------\n\nMany people are involved in the RFC process:\n\n- **RFC author** --- one or more community members who write an RFC and are\n committed to championing it through the process\n\n- **RFC sponsor** --- a maintainer who sponsors the RFC and will shepherd it\n through the RFC review process\n\n- **review committee** --- a group of maintainers who have the responsibility of\n recommending the adoption of the RFC\n\n- Any **community member** may help by providing feedback on whether the RFC\n will meet their needs.\n\n### RFC sponsors\n\nA sponsor is a project maintainer responsible for ensuring the best possible\noutcome of the RFC process. This includes:\n\n- Advocating for the proposed design.\n- Guiding the RFC to adhere to existing design and style conventions.\n- Guiding the review committee to come to a productive consensus.\n- If changes are requested by the review committee, ensure these are made and seek subsequent approval from the committee members.\n- If the RFC moves to implementation:\n - Ensuring proposed implementation adheres to the design.\n - Coordinate with appropriate parties to successfully land implementation.\n\n### RFC review committees\n\nThe review committee decides on a consensus basis whether to approve, reject, or\nrequest changes. They are responsible for:\n\n- Ensuring that substantive items of public feedback have been accounted for.\n- Adding their meeting notes as comments to the PR.\n- Providing reasons for their decisions.\n\nThe constitution of a review committee may change according to the particular\ngovernance style and leadership of each project. For core TensorFlow, the\ncommittee will consist of contributors to the TensorFlow project who have\nexpertise in the domain area concerned.\n\n### Community members and the RFC process\n\nThe purpose of RFCs is to ensure the community is well represented and served by\nnew changes to TensorFlow. It is the responsibility of community members to\nparticipate in reviewing RFCs where they have an interest in the outcome.\n\nCommunity members who are interested in an RFC should:\n\n- **Provide feedback** as soon as possible to allow adequate time for consideration.\n- **Read RFCs** thoroughly before providing feedback.\n- Be **civil and constructive**.\n\nImplementing new features\n-------------------------\n\nOnce an RFC has been approved, implementation can begin.\n\nIf you are working on new code to implement an RFC:\n\n- Make sure you understand the feature and the design approved in the RFC. Ask questions and discuss the approach before beginning work.\n- New features must include new unit tests that verify the feature works as expected. It's a good idea to write these tests before writing the code.\n- Follow the [TensorFlow Code Style Guide](#tensorflow_code_style_guide)\n- Add or update relevant API documentation. Reference the RFC in the new documentation.\n- Follow any other guidelines laid out in the `CONTRIBUTING.md` file in the project repo you're contributing to.\n- Run unit tests before submitting your code.\n- Work with the RFC sponsor to successfully land the new code.\n\nKeeping the bar high\n--------------------\n\nWhile we encourage and celebrate every contributor, the bar for RFC acceptance\nis kept intentionally high. A new feature may be rejected or need significant\nrevision at any one of these stages:\n\n- Initial design conversations on the relevant mailing list.\n- Failure to recruit a sponsor.\n- Critical objections during the feedback phase.\n- Failure to achieve consensus during the design review.\n- Concerns raised during implementation (for example: inability to achieve backwards compatibility, concerns about maintenance).\n\nIf this process is functioning well, RFCs are expected to fail in the earlier,\nrather than later, stages. An approved RFC is no guarantee of a commitment to\nimplement, and acceptance of a proposed RFC implementation is still subject to\nthe usual code review process.\n\nIf you have any questions about this process, feel free to ask on the developers\nmailing list or file an issue in\n[tensorflow/community](https://github.com/tensorflow/community/tree/master/rfcs)."]]
