כל תכונה חדשה של TensorFlow מתחילה את החיים בתור בקשה להערה (RFC).
RFC הוא מסמך המתאר דרישה ואת השינויים המוצעים שיפתרו אותה. באופן ספציפי, ה-RFC יבצע:
- להיות מעוצב לפי תבנית RFC .
- הוגש כבקשת משיכה לספריית הקהילה/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, קבל משוב מתחזקים ותורמים לפני שליחתו.
כתיבת קוד יישום אינה דרישה, אך היא עשויה לסייע בעיצוב דיונים.
גייס נותן חסות.
- נותן החסות חייב להיות מתחזק של הפרויקט.
- זהה את נותן החסות ב-RFC, לפני פרסום ה-PR.
אתה יכול לפרסם RFC ללא ספונסר, אבל אם תוך חודש מפרסום ה-PR עדיין אין נותן חסות, הוא ייסגר.
שלח את ה-RFC שלך כבקשת משיכה ל- tensorflow/community/rfcs .
כלול את טבלת הכותרות ואת התוכן של קטע המטרה בהערה של בקשת המשיכה שלך, באמצעות Markdown. לדוגמא, ראה RFC לדוגמה זו . כלול את נקודות האחיזה של GitHub של מחברים, סוקרים ונותני חסות.
בחלק העליון של יחסי הציבור ציין כמה זמן תהיה תקופת ההערות. זה צריך להיות לפחות שבועיים מפרסום יחסי הציבור.
דוא"ל לרשימת התפוצה של המפתחים עם תיאור קצר, קישור ליח"צ ובקשה לבדיקה. עקוב אחר הפורמט של דיוור קודמות, כפי שניתן לראות בדוגמה זו .
נותן החסות יבקש ישיבת ועדת בדיקה, לא מוקדם משבועיים לאחר פרסום ה-RFC PR. אם הדיון ער, המתן עד שיסתיים לפני שתעבור לסקירה. מטרת פגישת הביקורת היא לפתור בעיות קטנות; יש להגיע להסכמה בנושאים מרכזיים מראש.
הפגישה עשויה לאשר את ה-RFC, לדחות אותו או לדרוש שינויים לפני שניתן יהיה לשקול אותו שוב. RFCs שאושרו ימוזגו לקהילה/rfcs , ו-RFC שנדחו יסגרו את ה-PRs שלהם.
משתתפי RFC
אנשים רבים מעורבים בתהליך ה-RFC:
מחבר RFC - אחד או יותר מחברי הקהילה שכותבים RFC ומחויבים לקדם אותו במהלך התהליך
נותן חסות ל-RFC - מתחזק שנותן חסות ל-RFC ויעביר אותו דרך תהליך סקירת ה-RFC
ועדת ביקורת - קבוצה של מתחזקים שיש להם אחריות להמליץ על אימוץ ה-RFC
כל חבר בקהילה עשוי לעזור על ידי מתן משוב אם ה-RFC יענה על צרכיו.
נותני חסות RFC
נותן חסות הוא מנהל פרויקט שאחראי להבטיח את התוצאה הטובה ביותר של תהליך ה-RFC. זה כולל:
- תמיכה בתכנון המוצע.
- הנחיית ה-RFC לדבוק במוסכמות העיצוב והסגנון הקיימות.
- הנחיית ועדת הבדיקה להגיע להסכמה פורה.
- אם תתבקשו שינויים על ידי ועדת הביקורת, וודאו כי הם יתבצעו ובקשו אישור לאחר מכן מחברי הוועדה.
- אם ה-RFC עובר ליישום:
- הבטחת היישום המוצע תואם את התכנון.
- תיאום עם גורמים מתאימים כדי להצליח ביישום הקרקע.
ועדות ביקורת RFC
ועדת הבדיקה מחליטה על בסיס הסכמה אם לאשר, לדחות או לבקש שינויים. הם אחראים על:
- הבטחת כי פריטים מהותיים של משוב ציבורי נלקחו בחשבון.
- הוספת הערות הפגישה שלהם כהערות ליחסי הציבור.
- מתן נימוקים להחלטותיהם.
חוקתה של ועדת בדיקה עשויה להשתנות בהתאם לסגנון הממשל והמנהיגות המיוחדים של כל פרויקט. עבור TensorFlow הליבה, הוועדה תהיה מורכבת מתורמים לפרויקט TensorFlow שיש להם מומחיות בתחום הנוגע בדבר.
חברי קהילה ותהליך RFC
מטרת RFCs היא להבטיח שהקהילה מיוצגת היטב ומשרתת על ידי שינויים חדשים ב- TensorFlow. באחריות חברי הקהילה להשתתף בבדיקת RFCs כאשר יש להם עניין בתוצאה.
חברי קהילה המעוניינים ב-RFC צריכים:
- ספק משוב בהקדם האפשרי כדי לאפשר זמן הולם לשיקול דעת.
- קרא RFCs ביסודיות לפני מתן משוב.
- היה אזרחי ובונה .
הטמעת תכונות חדשות
לאחר אישור RFC, ניתן להתחיל ביישום.
אם אתה עובד על קוד חדש ליישום RFC:
- ודא שאתה מבין את התכונה ואת העיצוב המאושר ב-RFC. שאל שאלות ודון בגישה לפני תחילת העבודה.
- תכונות חדשות חייבות לכלול בדיקות יחידות חדשות המוודאות שהתכונה פועלת כצפוי. כדאי לכתוב את המבחנים הללו לפני כתיבת הקוד.
- עקוב אחר מדריך סגנון קוד TensorFlow
- הוסף או עדכן תיעוד API רלוונטי. עיין ב-RFC בתיעוד החדש.
- עקוב אחר כל ההנחיות האחרות המפורטות בקובץ
CONTRIBUTING.mdבמאגר הפרויקט שאתה תורם לו. - הפעל בדיקות יחידה לפני שליחת הקוד שלך.
- עבוד עם נותן החסות של RFC כדי להצליח להנחות את הקוד החדש.
שומרים על רף גבוה
בעוד אנו מעודדים וחוגגים כל תורם, הרף לקבלת RFC נשמר גבוה בכוונה. תכונה חדשה עשויה להידחות או להזדקק לעדכון משמעותי בכל אחד מהשלבים הבאים:
- שיחות עיצוב ראשוניות ברשימת התפוצה הרלוונטית.
- אי גיוס נותן חסות.
- התנגדויות קריטיות בשלב המשוב.
- אי השגת קונצנזוס במהלך סקירת העיצוב.
- חששות שהועלו במהלך היישום (לדוגמה: חוסר יכולת להשיג תאימות לאחור, חששות לגבי תחזוקה).
אם תהליך זה פועל היטב, RFCs צפויים להיכשל בשלבים המוקדמים, ולא המאוחרים. RFC מאושר אינו ערובה להתחייבות ליישום, וקבלה של יישום RFC מוצע עדיין כפופה לתהליך סקירת הקוד הרגיל.
אם יש לך שאלות כלשהן לגבי תהליך זה, אל תהסס לשאול ברשימת התפוצה של המפתחים או להגיש בעיה ב- tensorflow/קהילה .