Thanks for tuning in to Google I/O. View all sessions on demandWatch on demand

תהליך ה- RFC של TensorFlow

כל תכונה חדשה של TensorFlow מתחילה את החיים כבקשת תגובה (RFC).

RFC הוא מסמך המתאר דרישה ואת השינויים המוצעים שיפתור אותה. באופן ספציפי, ה- RFC:

מטרת בקשת TensorFlow לתגובות (RFC) היא לערב את קהילת TensorFlow בפיתוח, על ידי קבלת משוב מבעלי העניין ומומחים ותקשורת שינויים עיצוביים באופן רחב.

כיצד להגיש RFC

  1. לפני הגשת RFC, שוחח על המטרות שלך עם תורמי הפרויקטים והתחזוקה וקבל משוב מוקדם. השתמש ברשימת התפוצה של המפתחים עבור הפרויקט הנוגע בדבר (developers@tensorflow.org, או ברשימה עבור ה- SIG הרלוונטי).

  2. טיוטה ל- RFC שלך.

    • קרא את הקריטריונים לבדיקת העיצוב
    • עקוב אחר תבנית ה- RFC .
    • תן שם לקובץ RFC שלך YYYYMMDD-descriptive-name.md , כאשר YYYYMMDD הוא תאריך ההגשה, ושם descriptive-name מתייחס לכותרת ה- RFC שלך. (לדוגמא, אם ה- RFC שלך נקרא API של יישומונים מקבילים , ייתכן שתשתמש בשם הקובץ 20180531-parallel-widgets.md .
    • אם יש לך תמונות או קבצי עזר אחרים, צור ספריה של הטופס YYYYMMDD-descriptive-name בה ניתן לאחסן קבצים אלה.

    לאחר כתיבת טיוטת ה- RFC, קבל משוב ממחזיקים ותורמים לפני הגשתה.

    כתיבת קוד יישום אינה דרישה, אך היא עשויה לעזור בדיונים בתכנון.

  3. לגייס ספונסר.

    • נותן חסות חייב להיות שומר הפרויקט.
    • זהה את נותן החסות ב- RFC לפני שתפרסם את יחסי הציבור.

    אתה רשאי לפרסם RFC ללא נותן חסות, אך אם תוך חודש מרגע פרסום יחסי הציבור אין עדיין נותן חסות, הוא ייסגר.

  4. הגש את ה- RFC שלך כבקשת משיכה ל- tensorflow / community / rfcs .

    כלול את טבלת הכותרת ואת התוכן של החלק ' מטרה ' בתגובה לבקשת המשיכה שלך באמצעות Markdown. לדוגמא, עיין בדוגמה זו RFC . כלול את ידיות ה- GitHub של מחברים משותפים, סוקרים וספונסרים.

    בחלק העליון של יחסי הציבור זהה כמה זמן תהיה תקופת ההערות. זה צריך להיות לפחות שבועיים מפרסום יחסי הציבור.

  5. שלח דוא"ל לרשימת התפוצה של המפתח עם תיאור קצר, קישור ליחסי ציבור ובקשה לבדיקה. עקוב אחר פורמט הדיוור הקודם, כפי שניתן לראות בדוגמה זו .

  6. נותן החסות יבקש ישיבת ועדת ביקורת, לא לפני שבועיים לאחר פרסום ה- RFC. אם הדיון ער, המתן עד שהוא הסתדר לפני שתעבור לביקורת. מטרת פגישת הביקורת היא לפתור בעיות קלות; יש להגיע מראש להסכמה בנושאים מרכזיים.

  7. הפגישה עשויה לאשר את ה- RFC, לדחותו או לדרוש שינויים לפני שניתן יהיה לשקול אותו שוב. RFCs מאושרים ימוזגו בקהילה / rfcs , ו- RFC דחויים יחסי הציבור שלהם יהיו סגורים.

משתתפי RFC

אנשים רבים מעורבים בתהליך ה- RFC:

  • מחבר RFC - אחד או יותר מחברי הקהילה שכותבים RFC ומחויבים לתמוך בו בתהליך

  • נותן חסות ל- RFC - מתחזק המממן את ה- RFC וירצה אותו באמצעות תהליך הבדיקה של ה- RFC

  • ועדת סקירה - קבוצת מתחזקים האחראית להמליץ ​​על אימוץ ה- RFC

  • כל חבר בקהילה עשוי לעזור על ידי מתן משוב האם ה- RFC יענה על צרכיו.

נותני חסות ל- RFC

נותן חסות הוא מנהל פרויקטים האחראי להבטחת התוצאה הטובה ביותר האפשרית של תהליך ה- RFC. זה כולל:

  • תומך בעיצוב המוצע.
  • הנחיית ה- RFC לדבוק במוסכמות העיצוב והסגנון הקיימות.
  • הדרכת ועדת הביקורת להגיע להסכמה יצרנית.
  • אם וועדת הביקורת מבקשת שינויים, וודאו שנעשו ובקשו לקבל אישור אחר כך מחברי הוועדה.
  • אם ה- RFC עובר ליישום:
    • הקפדה על יישום הצעה עומדת בתכנון.
    • תיאום עם גורמים מתאימים ליישום קרקעות בהצלחה.

ועדות סקירה של RFC

ועדת הביקורת מחליטה על בסיס קונצנזוס אם לאשר, לדחות או לבקש שינויים. הם אחראים ל:

  • הקפדה על פריטים מהותיים של משוב ציבורי.
  • הוספת הערות הפגישה שלהם כהערות ליחסי הציבור.
  • מתן סיבות להחלטותיהם.

החוקה של ועדת ביקורת עשויה להשתנות בהתאם לסגנון הממשל והמנהיגות המסוימים של כל פרויקט. לגבי הליבה של TensorFlow, הוועדה תורכב מתורמים לפרויקט TensorFlow שיש להם מומחיות בתחום התחום הנוגע בדבר.

חברי הקהילה ותהליך ה- RFC

מטרת ה- RFC היא להבטיח כי הקהילה מיוצגת היטב ומשרתת שינויים חדשים ב- TensorFlow. באחריותם של חברי הקהילה להשתתף בבדיקת ה- RFC בהם יש להם עניין בתוצאה.

חברי הקהילה המעוניינים ב- RFC צריכים:

  • ספק משוב בהקדם האפשרי כדי לאפשר זמן הולם לשיקול דעת.
  • קרא בעומק RFC לפני שתספק משוב.
  • היו אזרחיים ובונים .

יישום תכונות חדשות

לאחר אישור ה- RFC, היישום יכול להתחיל.

אם אתה עובד על קוד חדש ליישום RFC:

  • וודא שאתה מבין את התכונה ואת העיצוב שאושר ב- RFC. שאל שאלות ודן בגישה לפני תחילת העבודה.
  • על תכונות חדשות לכלול בדיקות יחידות חדשות המאמתות כי התכונה פועלת כצפוי. מומלץ לכתוב את המבחנים האלה לפני כתיבת הקוד.
  • עקוב אחר המדריך לסגנון קוד TensorFlow
  • הוסף או עדכן תיעוד API רלוונטי. התייחס ל- RFC בתיעוד החדש.
  • פעל לפי כל ההנחיות האחרות CONTRIBUTING.md בקובץ CONTRIBUTING.md ברשימת הפרויקטים שאתה תורם לה.
  • הפעל בדיקות יחידה לפני הגשת הקוד שלך.
  • עבוד עם נותן החסות של RFC כדי להנחיל את הקוד החדש בהצלחה.

שומרים על הבר גבוה

בעוד אנו מעודדים וחוגגים כל תורם, הרף לקבלת RFC נשמר גבוה בכוונה. תכונה חדשה עשויה להידחות או להזדקק לתיקון משמעותי בכל אחד מהשלבים הבאים:

  • שיחות עיצוב ראשוניות ברשימת התפוצה הרלוונטית.
  • אי גיוס ספונסר.
  • התנגדויות קריטיות בשלב המשוב.
  • כישלון בהסכמה במהלך סקירת העיצוב.
  • דאגות שהועלו במהלך היישום (לדוגמא: חוסר יכולת להשיג תאימות לאחור, חששות לגבי תחזוקה).

אם תהליך זה מתפקד היטב, צפויות RFCs להיכשל בשלבים המוקדמים ולא המאוחרים. RFC מאושר אינו מהווה ערובה להתחייבות ליישום, וקבלת יישום RFC המוצע עדיין כפופה לתהליך בדיקת הקוד הרגיל.

אם יש לך שאלות לגבי תהליך זה, אל תהסס לשאול ברשימת התפוצה של המפתחים או להגיש בעיה ב- tensorflow / community .