דוח באג Slack לתיקון GitHub
תאר באג בשפה פשוטה ב-Slack. Okou כותב את בעיית GitHub ומקצה אותה, וכאשר הגורם נמצא ברכיב אחד הוא פותח בקשת משיכה עם התיקון ובדיקת רגרסיה לבדיקתך.
מה Okou מספק: מהודעת Slack לתיקון בבדיקה
שרשור אמיתי מערוץ #bug-report של צוות Okou, שתועד כפי שקרה. חבר צוות הדביק דיווח של לקוח וביקש תיקון. ארבע דקות לאחר מכן, Okou הגיש את בעיית GitHub עם אבחון. ארבע עשרה דקות לאחר ההודעה הראשונה, הוא פתח את בקשת המשיכה ופרסם את קישור התצוגה המקדימה. להלן שתי התפיסות: השרשור שבו הוא התחיל, ובקשת המשיכה ש-Okou כתב. הם ציבוריים, כך שתוכלו לקרוא את הבעיה, את ההבדל ואת הביקורת בעצמכם.
מה קרה בשיחה
חבר צוות דיווח על באג בפריסת PWA של לקוח ב-#bug-report וצירף את צילומי המסך. Okou קרא את השרשור, איתר אותו לסרגל עליון שמוצג ללא מרווח בטוח של iOS, ופתח את בעיה #11708 עם תוויות וההיגיון שלה. כאשר השרשור ביקש את התיקון, Okou שינה קובץ אחד (גובה מינימלי וריפוד אזור בטוח בסרגל העליון של הנייד), פתח בקשת משיכה #11709 עם קישור לתצוגה מקדימה, ועצר שם. אדם בדק ומיזג אותו.
- הודעה לנושא מתועד
- 4 דקותבעיה #11708, מסומנת כבאג ו-PWA
- הודעה לבקשת משיכה
- 14 דקותPR #11709 עם קישור לתצוגה מקדימה
- קבצים ששונו על ידי התיקון
- 1מוזג על ידי אדם, לא על ידי Okou
מה זה אומר ליצור בעיית GitHub מ-Slack?
יצירת בעיית GitHub מ-Slack פירושה הפיכת באג שמישהו תיאר בשיחה לבעיה מובנית כהלכה במאגר שלכם, מבלי שאף אחד יעזוב את השרשור כדי להקליד אותה מחדש. החלק הקשה מעולם לא היה שיחת API; זה כתיבת כותרת ברורה, הפרדת שלבי שחזור מהתנהגות צפויה, בחירת תוויות, קביעת עדיפות, ומציאת הבעלים הנכון. Okou עושה את העבודה הזו. הוא קורא את הודעת Slack ואת התשובות סביבה, כותב את גוף הבעיה, מיישם תוויות ועדיפות שהוא יכול להצדיק, פותר את המוטל על ידי התאמת שם התצוגה של Slack לכינוי GitHub, ומפרסם את קישור הבעיה בחזרה באותו שרשור כדי שהמדווח יוכל לבדוק אותו במבט אחד.
למה דוחות באגים מתים בשרשורי Slack
מישהו מזהה באג במהלך הדגמה, או שלקוח כותב בשבת. הדרך הישנה ארוכה: פתחו את GitHub, מצאו את הריפו, כתבו בעיה מפורמטת, הקצו מישהו, ואז המתינו שאותו אדם יטפל בה, יקרא את הקוד ויכתוב את התיקון. שינוי של עשר דקות הופך לנסיעה הלוך ושוב של מספר ימים בין שלושה אנשים, וחצי מהדיווחים לעולם לא יוצאים מהשרשור. במקום זאת, אתם מתארים זאת ב-Slack. Okou מגיש את הבעיה עם שלבים לשחזור, תוויות ובעלים, ובמקום שבו הגורם מוכל, הוא ממשיך ופותח בקשת משיכה עם התיקון ובדיקה. אתם בודקים ושולחים.
כיצד Okou יוצר בעיית GitHub מ-Slack
שלב 1: חבר את הכלים שלך
שלב 2: שאל את Okou
שלב 3: קח את זה רחוק יותר
שילובי Slack ו-GitHub שמאחורי זרימת העבודה
זוהי אינטגרציה של Slack GitHub עם סוכן באמצע: Okou קורא את השיחה ב-Slack וכותב את הרשומה ב-GitHub. כל מחבר מוענק בנפרד ומותאם למה שתהליך העבודה באמת משתמש בו, כך שקריאת ערוץ לעולם אינה מרמזת על גישת כתיבה למאגרים שלך.
שילוב Slack: השיחה ש-Okou קורא
נדרשOkou קורא את ההודעה שאתה מצביע עליה ואת התשובות סביבה, כך שגם הקשר שהגיע שלוש הודעות מאוחר יותר עדיין נכנס לבעיה. הוא קולט צילומי מסך מצורפים ומעביר אותם, קורא את שם התצוגה של המדווח כדי לפתור מקבל משימה, ושומר את הקישור הקבוע להודעה כך שכל בעיה מקשרת חזרה למקום שבו החל הדיווח. הכתיבה היא דבר אחד בלבד: תשובה באותו שרשור עם מספר הבעיה והקישור. Okou אינו מפרסם לערוצים אחרים, שולח הודעות פרטיות, או עורך הודעות של אף אחד.
שילוב GitHub: הבעיה ש-Okou מגיש
נדרשOkou יוצר את הבעיה במאגר שאתה מציין, עם כותרת שנכתבה מהדוח ולא עותק של ההודעה הגולמית, תיאור, שלבים לשחזור, התנהגות צפויה, והאזור המושפע כאשר השרשור מציין אחד. הוא מיישם את התוויות שאתה מציין או מסיק אותן מהניסוח, קובע עדיפות שהוא מסביר, ומקצה את הבעלים. לפני הגשת הבעיה הוא מחפש בעיות פתוחות עם אותו סימפטום ומגיב על הבעיה הקיימת במקום זאת כאשר הוא מוצא התאמה. כאשר הוא יכול גם לתקן את הבאג, הוא דוחף ענף ופותח בקשת משיכה שסוגרת את הבעיה ומבקשת סקירה. גישת כתיבה מוגבלת למאגרים שאתה מעניק, וזה כל המשטח: בעיות, תגובות ובקשות משיכה שנפתחו לסקירה. Okou אינו מאחד, אינו דוחף בכוח, ואינו נוגע בהגדרות המאגר.
Okou לעומת אפליקציית GitHub עבור Slack לעומת בונה אוטומציה
העברת באג מהודעת Slack ל-GitHub מורכבת משלושה חלקים: לכידת הדיווח, כתיבת בעיה שמישה, וניתובה לבעלים. האפשרויות הקיימות פותרות כל אחת מהן.
אפליקציית GitHub עבור Slack
הקלדת /github פותחת תיבת דו-שיח שבה אתה ממלא בעצמך את הכותרת, הגוף, התוויות והמטפל. זה חוסך את הדרך לדפדפן, אבל אתה עדיין זה שכותב את הבעיה, וטופס באמצע שיחה הוא בדיוק החיכוך שגורם לאנשים לומר "אני אגיש את זה מאוחר יותר."
בונה אוטומציה
בונה ללא קוד יכול להעתיק הודעת Slack לבעיה חדשה בטריגר. מה שהוא מעתיק הוא ההודעה הגולמית, כך שהבעיה יורשת את מה שהכתב הקליד במקרה, והכללים לתוויות, עדיפות, הקצאה וכפילויות הם כאלה שאתה צריך להגדיר ולתחזק לכל ערוץ.
זרימת העבודה של Okou מ-Slack ל-GitHub
Okou קורא את השרשור וכותב את הבעיה: כותרת אמיתית, שלבי שחזור מופרדים מהתנהגות צפויה, תוויות ועדיפות שהוא יכול להצדיק, ומקבל משימה שתואם לשם התצוגה של המדווח. כאשר הגורם מוגבל לרכיב אחד, הוא ממשיך ופותח בקשת משיכה עם התיקון ובדיקת רגרסיה, מקושרת לבעיה וממתינה לסקירה שלך. הוא בודק תחילה בעיות פתוחות ומגיב על כפילות במקום להגיש אחת, והוא משיב בשרשור עם הקישור.
טיפים לתוצאות טובות יותר
שאלות נפוצות
כיצד אתה יוצר בעיית GitHub מהודעת Slack?
חברו את Slack ו-GitHub ל-Okou, ואז תארו את הבאג בערוץ וציינו את Okou. הוא קורא את ההודעה ואת התגובות הסובבות אותה, כותב בעיה עם כותרת, שלבים לשחזור, התנהגות צפויה, תוויות ועדיפות, יוצר אותה במאגר שציינתם, מקצה בעלים, ומשיב בשרשור עם מספר הבעיה והקישור. אינכם ממלאים טופס.
במה זה שונה מאפליקציית GitHub עבור Slack?
אפליקציית GitHub נותנת לך תיבת דו-שיח למילוי: אתה עדיין כותב את הכותרת, הגוף, התוויות והמטפל. Okou כותב אותם מהשיחה, בודק אם קיימת בעיה עם אותו סימפטום לפני הגשה, ויכול לרוץ על פני ערוץ שלם בלוח זמנים במקום הודעה אחת בכל פעם.
האם Okou רק רושם את הבעיה, או שהוא יכול לתקן את הבאג?
גם וגם, והוא אומר לך מה הוא עשה ולמה. Okou תמיד מגיש את הבעיה. כאשר השרשור או הקוד מצביעים על רכיב יחיד, ההתנהגות הצפויה אינה חד-משמעית, וניתן לכתוב בדיקה כושלת תחילה, הוא גם פותח בקשת משיכה עם התיקון והבדיקה הזו, מקשר אותה לבעיה, ומבקש סקירה. כלי עזר משותפים, אסימוני עיצוב, וכל דבר הדורש החלטת מוצר מוגשים במקום לשנותם. Okou לעולם לא ממזג; כל תיקון מגיע כבקשת משיכה שאתה סוקר.
האם Okou יכול להקצות את הבעיה לאדם הנכון באופן אוטומטי?
כן. Okou מתאים את השם שאתה מזכיר, או את שם התצוגה של Slack של הכתב, מול ידיות GitHub במאגר ומקצה את הבעיה. ציון המקצה בהודעה שלך הוא הדרך האמינה ביותר; כאשר אף אחד לא מצוין, Okou חוזר לבעל האזור שהשרשור מצביע עליו ואומר בבעיה כיצד החליט.
כיצד Okou מונע רישום בעיות GitHub כפולות?
לפני יצירת משהו, Okou מחפש בעיות פתוחות אחר אותם סימפטומים, אזור מושפע וניסוח. כאשר הוא מוצא התאמה, הוא מוסיף את שרשור Slack החדש כהערה על אותה בעיה, עם המדווח וחותמת הזמן, ומשיב ב-Slack עם קישור הבעיה הקיימת במקום לפתוח אחת שנייה.
מה קורה כאשר לדוח באג אין שלבים לשחזור?
Okou עדיין מגיש את הבעיה כדי שהדיווח לא יאבד, מתייג אותה כדורשת שלבי שחזור, ומשיב בשרשור Slack בבקשה מהמדווח לספק אותם. התשובה נוחתת אז בשרשור שכבר מקושר מהבעיה.
האם Okou יכול לרשום באגים מערוץ שלם בלוח זמנים?
כן. כוון את Okou לערוץ אחד או יותר ותן לו לוח זמנים, לדוגמה כל יום שישי בשעה 16:00. הוא קורא את הודעות השבוע, פותח בעיה עבור כל אחת שמתארת פגם, מגיב על כפילויות, מדלג על בקשות תכונה ושאלות, ומדווח על מה שעשה.
האם זה עובד עם Linear או Jira במקום GitHub?
אותה צורת זרימת עבודה חלה על כל גשש ש-Okou מחובר אליו; עמוד זה מכסה את נתיב GitHub, המשתמש במחבר GitHub. Linear מחובר באותה צורה, ואתה נותן שם לגשש בהוראה.
הגש את הבאג הבא שלך מבלי לעזוב את Slack
חבר את Slack ו-GitHub, תאר את הבאג כפי שהיית מתאר לחבר צוות, ותן ל-Okou לכתוב את הבעיה ולהקצות אותה. כאשר הגורם מוגבל, בקשת המשיכה ממתינה גם לך.
