Slack संदेश को GitHub issue में बदलें, और फिक्स तक ले जाएँ
Slack में आम भाषा में बग बताइए। Zero GitHub issue लिखकर assign करता है, और जब कारण एक ही component में हो तो फिक्स और regression test वाला pull request भी खोल देता है, जिसकी समीक्षा आप करते हैं।
Zero क्या देता है: Slack संदेश से लेकर समीक्षा में पड़े फिक्स तक
vm0 टीम के #bug-report चैनल का असली थ्रेड, जैसा हुआ वैसा ही। एक साथी ने ग्राहक की शिकायत चिपकाई और फिक्स माँगा। चार मिनट बाद Zero ने निदान के साथ GitHub इश्यू बना दिया था। पहले मैसेज के चौदह मिनट बाद पुल रिक्वेस्ट खुल चुकी थी और प्रीव्यू लिंक थ्रेड में था। नीचे दोनों स्क्रीनशॉट हैं: वह थ्रेड जहाँ से शुरुआत हुई, और Zero की लिखी पुल रिक्वेस्ट। दोनों सार्वजनिक हैं, इसलिए इश्यू, diff और रिव्यू आप खुद पढ़ सकते हैं।
थ्रेड में क्या हुआ
एक साथी ने #bug-report में ग्राहक के बताए PWA लेआउट बग की जानकारी स्क्रीनशॉट के साथ दी। Zero ने थ्रेड पढ़ा, वजह iOS सेफ-एरिया इनसेट के बिना रेंडर हो रही ऊपरी बार में पहचानी, और लेबल तथा तर्क के साथ इश्यू #11708 बनाया। थ्रेड में फिक्स माँगे जाने पर Zero ने सिर्फ एक फाइल बदली (मोबाइल टॉप बार पर न्यूनतम ऊँचाई और सेफ-एरिया पैडिंग), प्रीव्यू लिंक के साथ पुल रिक्वेस्ट #11709 खोली, और वहीं रुक गया। रिव्यू और मर्ज एक इंसान ने किया।
- मैसेज से इश्यू तक
- 4 मिनटइश्यू #11708, लेबल bug और PWA
- मैसेज से पुल रिक्वेस्ट तक
- 14 मिनटPR #11709, प्रीव्यू लिंक के साथ
- फिक्स से बदली फाइलें
- 1मर्ज Zero ने नहीं, इंसान ने किया
Slack से GitHub issue बनाने का क्या मतलब है?
Slack से GitHub issue बनाने का मतलब है किसी बातचीत में बताए गए बग को, बिना थ्रेड छोड़े और दोबारा टाइप किए, आपकी repository में एक ठीक से संरचित issue में बदल देना। मुश्किल हिस्सा कभी API कॉल नहीं था: मुश्किल है साफ़ शीर्षक लिखना, reproduce करने के चरणों को अपेक्षित व्यवहार से अलग करना, labels चुनना, प्राथमिकता तय करना और सही व्यक्ति ढूँढना। यही काम Zero करता है। वह Slack संदेश और उसके आसपास के जवाब पढ़ता है, issue का मुख्य हिस्सा लिखता है, ऐसे labels और प्राथमिकता लगाता है जिनका कारण वह बता सके, Slack के display name को GitHub handle से मिलाकर assignee तय करता है, और उसी थ्रेड में issue का लिंक भेज देता है ताकि रिपोर्ट करने वाला एक नज़र में जाँच सके।
बग रिपोर्ट Slack थ्रेड में क्यों दब जाती हैं
डेमो के दौरान किसी को बग दिखता है, या शनिवार को कोई ग्राहक लिखता है। पुराना रास्ता लंबा है: GitHub खोलो, repo ढूँढो, ठीक से issue लिखो, किसी को assign करो, फिर इंतज़ार करो कि वह व्यक्ति इसे उठाए, कोड पढ़े और फिक्स लिखे। दस मिनट का बदलाव तीन लोगों के बीच कई दिन का चक्कर बन जाता है, और आधी रिपोर्ट तो थ्रेड से बाहर निकलती ही नहीं। इसके बजाय इसे Slack में बता दीजिए। Zero reproduce करने के चरणों, labels और मालिक के साथ issue बनाता है, और जहाँ कारण सीमित हो वहाँ आगे बढ़कर फिक्स और test वाला pull request भी खोल देता है। आप समीक्षा करके रिलीज़ करते हैं।
Zero Slack से GitHub issue कैसे बनाता है
चरण 1: अपने tools कनेक्ट करें
चरण 2: Zero से पूछें
चरण 3: इसे और आगे ले जाएँ
इस वर्कफ़्लो के पीछे Slack और GitHub इंटीग्रेशन
यह बीच में एक एजेंट के साथ Slack-GitHub इंटीग्रेशन है: Zero Slack में बातचीत पढ़ता है और GitHub में रिकॉर्ड लिखता है। हर connector अलग से दिया जाता है और वर्कफ़्लो जो वास्तव में इस्तेमाल करता है उसी तक सीमित रहता है, इसलिए कोई चैनल पढ़ने का मतलब कभी आपकी repositories में लिखने की अनुमति नहीं होता।
Slack इंटीग्रेशन: Zero जो बातचीत पढ़ता है
ज़रूरीZero उस संदेश को पढ़ता है जिस पर आप उसे लगाते हैं, और उसके आसपास के जवाब भी, इसलिए तीन संदेश बाद आया संदर्भ भी issue में पहुँच जाता है। वह संलग्न स्क्रीनशॉट साथ ले जाता है, रिपोर्ट करने वाले का display name पढ़कर assignee तय करता है, और संदेश का permalink रखता है ताकि हर issue वहीं वापस जोड़े जहाँ रिपोर्ट शुरू हुई थी। वह सिर्फ़ एक चीज़ लिखता है: उसी थ्रेड में issue नंबर और लिंक वाला जवाब। Zero दूसरे चैनलों में पोस्ट नहीं करता, DM नहीं भेजता, और किसी का संदेश संपादित नहीं करता।
GitHub इंटीग्रेशन: Zero जो issue बनाता है
ज़रूरीZero उसी repository में issue बनाता है जिसका नाम आप देते हैं, ऐसे शीर्षक के साथ जो कच्चे संदेश की नकल नहीं बल्कि रिपोर्ट से लिखा गया हो, साथ में विवरण, reproduce करने के चरण, अपेक्षित व्यवहार, और थ्रेड में बताया गया हो तो प्रभावित हिस्सा। वह आपके बताए labels लगाता है या शब्दों से अनुमान लगाता है, ऐसी प्राथमिकता तय करता है जिसे वह समझा सके, और मालिक assign करता है। बनाने से पहले वह उसी लक्षण वाले खुले issues खोजता है और मेल मिलने पर नया बनाने के बजाय मौजूदा issue पर टिप्पणी करता है। जब वह बग ठीक भी कर सकता है, तो एक branch push करता है और ऐसा pull request खोलता है जो उस issue को बंद करे और समीक्षा माँगे। लिखने की अनुमति सिर्फ़ उन्हीं repositories तक सीमित रहती है जो आप देते हैं, और दायरा बस इतना ही है: issues, टिप्पणियाँ, और समीक्षा के लिए खोले गए pull requests। Zero merge नहीं करता, force push नहीं करता, और repository सेटिंग्स को हाथ नहीं लगाता।
Zero बनाम Slack के लिए GitHub ऐप बनाम ऑटोमेशन बिल्डर
Slack संदेश से बग को GitHub तक पहुँचाने के तीन हिस्से हैं: रिपोर्ट पकड़ना, काम लायक issue लिखना, और उसे किसी मालिक तक पहुँचाना। मौजूदा विकल्प इनमें से एक-एक हल करते हैं।
Slack के लिए GitHub ऐप
/github टाइप करने पर एक डायलॉग खुलता है जिसमें शीर्षक, विवरण, labels और assignee आप खुद भरते हैं। ब्राउज़र तक जाने की मेहनत बचती है, पर issue अब भी आप ही लिखते हैं, और बातचीत के बीच में आया फ़ॉर्म ठीक वही रुकावट है जिसकी वजह से लोग कहते हैं “बाद में दर्ज कर दूँगा”।
ऑटोमेशन बिल्डर
कोई no-code टूल किसी trigger पर Slack संदेश को नए issue में कॉपी कर सकता है। वह कच्चा संदेश ही कॉपी करता है, तो issue में वही उतरता है जो रिपोर्ट करने वाले ने उस समय लिख दिया, और labels, प्राथमिकता, assignment और डुप्लिकेट के नियम आपको हर चैनल के लिए खुद तय और रखरखाव करने पड़ते हैं।
Zero का Slack से GitHub वर्कफ़्लो
Zero थ्रेड पढ़कर issue लिखता है: असली शीर्षक, अपेक्षित व्यवहार से अलग किए गए reproduce करने के चरण, ऐसे labels और प्राथमिकता जिनका कारण वह बता सके, और रिपोर्ट करने वाले के display name से मिलाया गया assignee। जब कारण एक ही component तक सीमित हो, तो वह आगे बढ़कर फिक्स और regression test वाला pull request खोलता है, उसे issue से जोड़ता है और आपकी समीक्षा का इंतज़ार करता है। वह पहले खुले issues जाँचता है और डुप्लिकेट बनाने के बजाय उस पर टिप्पणी करता है, और थ्रेड में लिंक के साथ जवाब देता है।
बेहतर परिणामों के लिए सुझाव
अक्सर पूछे जाने वाले सवाल
Slack संदेश से GitHub issue कैसे बनाएँ?
Slack और GitHub को Zero से जोड़ें, चैनल में बग बताएँ और Zero को mention करें। वह संदेश और आसपास के जवाब पढ़ता है, शीर्षक, reproduce करने के चरण, अपेक्षित व्यवहार, labels और प्राथमिकता के साथ issue लिखता है, आपकी बताई repository में बनाता है, assign करता है, और थ्रेड में issue नंबर व लिंक के साथ जवाब देता है। आपको कोई फ़ॉर्म नहीं भरना पड़ता।
यह Slack के लिए GitHub ऐप से कैसे अलग है?
GitHub ऐप आपको भरने के लिए डायलॉग देता है: शीर्षक, विवरण, labels और assignee आप लिखते हैं। Zero इन्हें बातचीत से लिखता है, बनाने से पहले उसी लक्षण वाला मौजूदा issue जाँचता है, और एक-एक संदेश के बजाय पूरे चैनल को निर्धारित समय पर संभाल सकता है।
क्या Zero सिर्फ़ issue बनाता है, या बग ठीक भी कर सकता है?
दोनों, और वह बताता है कि उसने क्या किया और क्यों। issue वह हमेशा बनाता है। जब थ्रेड या कोड किसी एक component की ओर इशारा करे, अपेक्षित व्यवहार स्पष्ट हो, और पहले एक फेल होने वाला test लिखा जा सके, तो वह फिक्स और उस test वाला pull request भी खोलता है, उसे issue से जोड़ता है और समीक्षा माँगता है। साझा utilities, design tokens, और जो कुछ भी प्रोडक्ट निर्णय माँगता है, उसे बदला नहीं जाता, सिर्फ़ दर्ज किया जाता है। Zero कभी merge नहीं करता; हर फिक्स एक pull request के रूप में आता है जिसकी समीक्षा आप करते हैं।
क्या Zero issue को अपने आप सही व्यक्ति को assign कर सकता है?
हाँ। Zero आपके बताए नाम, या रिपोर्ट करने वाले के Slack display name को repository के GitHub handles से मिलाकर issue assign करता है। संदेश में assignee का नाम लिखना सबसे भरोसेमंद तरीका है; जब कोई नाम न हो तो Zero उस हिस्से के मालिक पर लौटता है जिसकी ओर थ्रेड इशारा करता है, और issue में लिख देता है कि उसने कैसे तय किया।
Zero डुप्लिकेट GitHub issues से कैसे बचता है?
कुछ भी बनाने से पहले Zero उसी लक्षण, प्रभावित हिस्से और शब्दों वाले खुले issues खोजता है। मेल मिलने पर वह नए Slack थ्रेड को रिपोर्ट करने वाले और समय के साथ उसी issue पर टिप्पणी के रूप में जोड़ देता है, और दूसरा issue खोलने के बजाय Slack में मौजूदा issue का लिंक भेज देता है।
अगर बग रिपोर्ट में reproduce करने के चरण न हों तो?
Zero फिर भी issue बनाता है ताकि रिपोर्ट खो न जाए, उस पर reproduce करने के चरण चाहिए का label लगाता है, और Slack थ्रेड में रिपोर्ट करने वाले से वे चरण माँगता है। जवाब फिर उसी थ्रेड में आता है जो पहले से issue से जुड़ा है।
क्या Zero पूरे चैनल से निर्धारित समय पर बग दर्ज कर सकता है?
हाँ। Zero को एक या अधिक चैनल दें और एक शेड्यूल बताएँ, जैसे हर शुक्रवार शाम 4 बजे। वह उस सप्ताह के संदेश पढ़ता है, हर उस संदेश के लिए issue बनाता है जो किसी खामी का वर्णन करता है, डुप्लिकेट पर टिप्पणी करता है, फ़ीचर अनुरोध और सवाल छोड़ देता है, और बताता है कि उसने क्या किया।
क्या यह GitHub की जगह Linear या Jira के साथ काम करता है?
यही वर्कफ़्लो किसी भी ऐसे tracker पर लागू होता है जिससे Zero जुड़ा हो; यह पेज GitHub का रास्ता बताता है, जो GitHub connector इस्तेमाल करता है। Linear भी इसी तरह जोड़ा जाता है, और tracker का नाम आप निर्देश में देते हैं।
अगला बग Slack छोड़े बिना दर्ज करें
Slack और GitHub जोड़ें, बग को वैसे ही बताएँ जैसे किसी साथी को बताते, और Zero को issue लिखने और assign करने दें। जब कारण सीमित हो, तो pull request भी आपका इंतज़ार कर रहा होगा।