כולם יכולים לתרום תוכן ב-OpenXLA, ואנחנו מעריכים את התרומות של כולם. יש כמה דרכים להוסיף תוכן, כולל:
מענה על שאלות בפורומים של הדיונים של OpenXLA (דיון פתוח)
שיפור או הרחבה של מסמכי OpenXLA
תרומה לבסיס הקוד של OpenXLA
תרומה בכל אחת מהדרכים שלמעלה לסביבה הרחבה של הספריות שנבנו ב-OpenXLA
פרויקט OpenXLA פועל בהתאם להנחיות הקהילה של Google בנושא קוד פתוח.
לפני שמתחילים
חתימה על הסכם הרישיון לתורמים
התרומות לפרויקט הזה חייבות להיות מלוות בהסכם רישיון לתורמים (CLA). אתם (או המעסיק שלכם) מחזיקים בזכויות היוצרים על התרומה. זה רק נותן לנו הרשאה להשתמש בתרומות שלכם ולהפיץ אותן מחדש כחלק מהפרויקט.
אם אתם או המעסיק הנוכחי שלכם כבר חתמתם על הסכם רישיון תוכן (CLA) של Google (גם אם מדובר בפרויקט אחר), סביר להניח שלא תצטרכו לעשות זאת שוב.
כדי לראות את ההסכמים הנוכחיים או לחתום על הסכם חדש, אפשר לעבור לכתובת <https://cla.developers.google.com/>.
עיון בקוד ההתנהגות
הפרויקט פועל בהתאם לקוד ההתנהגות של Tensorflow.
תהליך התרומה
מדריך למפתחים
במדריך למפתחים מוסבר איך מגדירים סביבת פיתוח ל-OpenXLA, כולל קבלת קוד, בנייתו, הפעלת בדיקות ושליחת שינויים.
תקני קוד
סגנון תכנות: אנחנו פועלים לפי מדריך הסגנון של Google לקודים. ניתן לעיין במדריכים של C/C++ ו-Python. כל הקוד ששולחים צריך להתאים אך ורק למדריכי הסגנון האלה.
שינויים קומפקטיים: אנחנו פועלים בהתאם לשיטות העבודה של Google בנושא הנדסה. במיוחד, כדאי לעיין במדריך לכתיבת שינויים קומפקטיים. אם תעשו זאת, תשפרו מאוד את המהירות שבה תוכלו למזג את הקוד כי הוא יכול לשפר את יכולת הבדיקה, ולהפחית את הסיכוי שתופעות לא רצויות של שינוי. גם אם יש שינוי גדול, יש אסטרטגיות רבות לפיצולו לשינויים נוספים.
כיסוי בדיקה: כל השינויים צריכים לכלול בדיקות יחידה מתאימות. בדיקות היחידות לא צריכות להיות תלויות בתזמונים ספציפיים של חומרה (מעבד גרפי, GPU וכו'), וצריך לעשות שימוש חופשי בהדמיות וזיופים כדי לבצע בדיקות חד-משמעיות וממוקדות. אם רוצים להרחיב קוד קיים שקשה לבדוק כרגע, כדאי לשפר את יכולת הבדיקה.
כל השינויים צריכים לכלול תוצאות מתאימות של נקודת השוואה גם בשם השינוי, כדי להבטיח שהיתרונות מובנים לכם באופן ברור.
כשיש ספק לגבי המוסכמות בקוד, תמיד כדאי לבדוק את הקוד הקיים ולנסות לפעול בהתאם לדפוסים שכבר קיימים ב-OpenXLA.
בדיקת התהליך
כל ההגשות, כולל הגשות של חברים בפרויקט, מחייבות בדיקה. לשם כך, אנחנו משתמשים בבקשות משיכה ב-GitHub. תוכלו להיעזר במרכז העזרה של GitHub כדי לקבל מידע נוסף על השימוש בבקשות משיכה.
לפני הבדיקה, הקוד חייב לעמוד בכל הסטנדרטים שמפורטים למעלה. לא חובה לעשות זאת, וחשוב מאוד שהמגיש יוודא שהקוד שלו עומד בדרישות לפני בקשת בדיקה כדי לוודא שהשינויים יאושרו בזמן.
כל הבדיקות חייבות לעבור. אם גיליתם שהבדיקה לא תקינה והבעיה לא קשורה לסביבת ה-build שלכם או לשינויים אחרים, פנו למנהלים.
כדאי להימנע מרגיעה בהיקף במהלך הבדיקה. זו האחריות של מגיש התלונה ושל הבודק. אם שינוי מתחיל להיות גדול מדי, כדאי לפצל אותו למספר שינויים.
לפני מיזוג השינוי, הוא יעבור בדיקה פנימית שמתבססת על קוד פנימי של Google ושל ספקי חומרה אחרים. הדבר עשוי להוסיף עוד שלבים לתהליך הבדיקה אם אירעו כשלים בבדיקות פנימיות שצוות ה-CI הציבורי שלנו לא מצליח לזהות. הגוגלר שבודק את השינוי ימסור פרטים על כשלים בבדיקה הפנימית ויתאר מה צריך לתקן.
שאלות נפוצות
"השינוי הזה בתשתית לא קשור ליחסי הציבור שלי. מדוע כדאי לי לעשות זאת?"
לצוות XLA אין צוות תשתיות ייעודי, כך שכולנו צריכים ליצור ספריות מסייעות ולהימנע מחובות טכניים. מבחינתנו זה חלק קבוע מעריכת שינויים בפורמט XLA, וכולם נדרשים להשתתף. בדרך כלל אנחנו בונים תשתית לפי הצורך כשכותבים קוד.
יכול להיות שבודקי XLA יבקשו מכם לבנות תשתית (או לבצע שינוי גדול ב-PR) ביחד עם יחסי ציבור שכתבתם. יכול להיות שהבקשה הזו נראית לא נחוצה או תואמת לזו שאתם מנסים לבצע. סביר להניח שהסיבה לכך היא חוסר התאמה בין הציפיות שלכם לגבי כמות התפרה שצריך לבנות לבין הציפיות של הבודקים.
אי-התאמה בציפיות זה בסדר! זה ככה זה כשמתחילים פרויקט חדש (ולפעמים זה גם קורה גם לנו עם כובעים ישנים). סביר להניח שלפרויקטים שעבדתם עליהם בעבר יש ציפיות שונות. זה גם בסדר וצפוי! זה לא אומר שלאחד מהפרויקטים האלה יש גישה שגויה, הם פשוט שונים. אנחנו מזמינים אתכם להתייחס לבקשות הפרטיות לצד כל שאר התגובות הביקורות כהזדמנות ללמוד מה אנחנו מצפים במסגרת הפרויקט הזה.
"האם אוכל לטפל בתגובה שלך בפרסום ציבורי עתידי?"
פעמים רבות, ביחס לבקשות לתשתית (או לבקשות גדולות אחרות) ב-PR, יש לציין אם צריך לבצע את השינוי ב-PR המקורי או לא, או אם אפשר לעשות אותו כהמשך המשך ביחסי ציבור עתידיים.
באופן כללי, XLA לא מאפשר לכותבי יחסי ציבור להתייחס לתגובות לביקורות באמצעות יחסי ציבור. כאשר בודק מחליט שיש צורך להתייחס לנושא מסוים ביחסי ציבור, אנחנו בדרך כלל מצפים שהמחברים יתייחסו לכך באותו יחסי ציבור, גם אם מדובר בשינוי גדול. הסטנדרט הזה חל באופן חיצוני וגם באופן פנימי בתוך Google.
יש כמה סיבות לכך שחברת XLA נוקטת בגישה הזו.
אמון: השגת האמון של הבודק היא רכיב מרכזי. בפרויקט קוד פתוח, השותפים יכולים להופיע או להיעלם כרצונכם. אחרי שאנחנו מאשרים יחסי ציבור, לבודקים אין דרך לוודא שהבדיקות שהובטחו אכן התבצעו.
השפעה על מפתחים אחרים: אם שלחתם יחסי ציבור שנוגעים לחלק מסוים של XLA, יש סיכוי טוב שאנשים אחרים בוחנים את אותו החלק. אם נקבל חוב טכני בקובץ ה-PR שלכם, כל מי שצופה בקובץ הזה יושפע מהחוב הזה עד להגשת הבקשה למעקב.
רוחב הפס של הבודקים: דחיית שינוי להמשך טיפול גורמת לכם לעלויות מרובות על הבודקים שכבר עמוסים שלנו. סביר להניח שהבודקים ישכחו מה היה נושא יחסי הציבור הראשונה בזמן ההמתנה להמשך הבדיקה, דבר שיקשה על הבדיקה הבאה. בנוסף, הבודקים יצטרכו לעקוב אחרי המעקבים הצפויים ולוודא שאכן הם מתרחשים. אם ניתן לבצע את השינוי כך שהוא יהיה אורתוגונלי באמת ליחסי ציבור אחרים כדי שבודק אחר יוכל לבדוק אותו, רוחב הפס יהיה פחות בעייתי. מניסיוננו, זה מקרה נדיר.