Slack संदेश को GitHub issue में बदलें, और फिक्स तक ले जाएँ

Slack में आम भाषा में बग बताइए। Okou GitHub issue लिखकर assign करता है, और जब कारण एक ही component में हो तो फिक्स और regression test वाला pull request भी खोल देता है, जिसकी समीक्षा आप करते हैं।

Okou जुड़ता है:SlackGitHubLinear

Slack से GitHub issue बनाने का क्या मतलब है?

Slack से GitHub issue बनाने का मतलब है किसी बातचीत में बताए गए बग को, बिना थ्रेड छोड़े और दोबारा टाइप किए, आपकी repository में एक ठीक से संरचित issue में बदल देना। मुश्किल हिस्सा कभी API कॉल नहीं था: मुश्किल है साफ़ शीर्षक लिखना, reproduce करने के चरणों को अपेक्षित व्यवहार से अलग करना, labels चुनना, प्राथमिकता तय करना और सही व्यक्ति ढूँढना। यही काम Okou करता है। वह Slack संदेश और उसके आसपास के जवाब पढ़ता है, issue का मुख्य हिस्सा लिखता है, ऐसे labels और प्राथमिकता लगाता है जिनका कारण वह बता सके, Slack के display name को GitHub handle से मिलाकर assignee तय करता है, और उसी थ्रेड में issue का लिंक भेज देता है ताकि रिपोर्ट करने वाला एक नज़र में जाँच सके।

बग रिपोर्ट Slack थ्रेड में क्यों दब जाती हैं

डेमो के दौरान किसी को बग दिखता है, या शनिवार को कोई ग्राहक लिखता है। पुराना रास्ता लंबा है: GitHub खोलो, repo ढूँढो, ठीक से issue लिखो, किसी को assign करो, फिर इंतज़ार करो कि वह व्यक्ति इसे उठाए, कोड पढ़े और फिक्स लिखे। दस मिनट का बदलाव तीन लोगों के बीच कई दिन का चक्कर बन जाता है, और आधी रिपोर्ट तो थ्रेड से बाहर निकलती ही नहीं। इसके बजाय इसे Slack में बता दीजिए। Okou reproduce करने के चरणों, labels और मालिक के साथ issue बनाता है, और जहाँ कारण सीमित हो वहाँ आगे बढ़कर फिक्स और test वाला pull request भी खोल देता है। आप समीक्षा करके रिलीज़ करते हैं।

Okou Slack से GitHub issue कैसे बनाता है

चरण 1: अपने tools कनेक्ट करें

GitHub
GitHub
ज़रूरी
GitHub से OAuth कनेक्शन। issues बनाने के लिए, और जब फिक्स हो तो branch push करके pull request खोलने के लिए, Okou को read/write एक्सेस चाहिए।
जोड़ें
Slack
Slack
ज़रूरी
Okou आपका मैसेज पढ़ता है और उसी थ्रेड में जवाब देता है।
जोड़ें

चरण 2: Okou से पूछें

Okou थ्रेड पढ़ता है
Okou आपका संदेश और आसपास के जवाब पढ़ता है, इसलिए तीन संदेश बाद आया संदर्भ भी गिना जाता है। वह assignee पहचानता है और लोगों ने जो असल में कहा उससे labels और प्राथमिकता का अनुमान लगाता है।
GitHub पर issue बनता है
लिखा हुआ शीर्षक, विवरण, अपेक्षित व्यवहार से अलग किए गए reproduce करने के चरण, प्रभावित हिस्सा, labels, और Slack display name से मिलाया गया मालिक। Okou पहले खुले issues जाँचता है और दूसरा बनाने के बजाय डुप्लिकेट पर टिप्पणी करता है।
Okou कारण ढूँढकर pull request खोलता है
जब थ्रेड या कोड किसी एक component की ओर इशारा करे और पहले एक फेल होने वाला test लिखा जा सके, तो Okou फिक्स और वह test लिखता है, pull request को issue से जोड़ता है और CI चलने देता है। जब ऐसा न हो, वह issue पर रुक जाता है और थ्रेड में कारण बताता है।
आप समीक्षा करके रिलीज़ करते हैं
Okou उसी थ्रेड में issue, pull request और preview लिंक के साथ जवाब देता है, और मालिक से समीक्षा माँगता है। कुछ भी अपने आप merge नहीं होता; फिक्स आपका इंतज़ार करता है।

चरण 3: इसे और आगे ले जाएँ

फिक्स भी माँगें
टिकट से आगे, pull request तक
और विवरण जोड़ें
स्क्रीनशॉट या रिप्रोड्यूस करने के स्टेप्स अटैच करें
बैच में issues दर्ज करें
एक साथ कई issues बनाएं
ट्रायेज ऑटोमेट करें
एक चैनल से अपने आप issues बनाएं

इस वर्कफ़्लो के पीछे Slack और GitHub इंटीग्रेशन

यह बीच में एक एजेंट के साथ Slack-GitHub इंटीग्रेशन है: Okou Slack में बातचीत पढ़ता है और GitHub में रिकॉर्ड लिखता है। हर connector अलग से दिया जाता है और वर्कफ़्लो जो वास्तव में इस्तेमाल करता है उसी तक सीमित रहता है, इसलिए कोई चैनल पढ़ने का मतलब कभी आपकी repositories में लिखने की अनुमति नहीं होता।

Slack

Slack इंटीग्रेशन: Okou जो बातचीत पढ़ता है

ज़रूरी

Okou उस संदेश को पढ़ता है जिस पर आप उसे लगाते हैं, और उसके आसपास के जवाब भी, इसलिए तीन संदेश बाद आया संदर्भ भी issue में पहुँच जाता है। वह संलग्न स्क्रीनशॉट साथ ले जाता है, रिपोर्ट करने वाले का display name पढ़कर assignee तय करता है, और संदेश का permalink रखता है ताकि हर issue वहीं वापस जोड़े जहाँ रिपोर्ट शुरू हुई थी। वह सिर्फ़ एक चीज़ लिखता है: उसी थ्रेड में issue नंबर और लिंक वाला जवाब। Okou दूसरे चैनलों में पोस्ट नहीं करता, DM नहीं भेजता, और किसी का संदेश संपादित नहीं करता।

GitHub

GitHub इंटीग्रेशन: Okou जो issue बनाता है

ज़रूरी

Okou उसी repository में issue बनाता है जिसका नाम आप देते हैं, ऐसे शीर्षक के साथ जो कच्चे संदेश की नकल नहीं बल्कि रिपोर्ट से लिखा गया हो, साथ में विवरण, reproduce करने के चरण, अपेक्षित व्यवहार, और थ्रेड में बताया गया हो तो प्रभावित हिस्सा। वह आपके बताए labels लगाता है या शब्दों से अनुमान लगाता है, ऐसी प्राथमिकता तय करता है जिसे वह समझा सके, और मालिक assign करता है। बनाने से पहले वह उसी लक्षण वाले खुले issues खोजता है और मेल मिलने पर नया बनाने के बजाय मौजूदा issue पर टिप्पणी करता है। जब वह बग ठीक भी कर सकता है, तो एक branch push करता है और ऐसा pull request खोलता है जो उस issue को बंद करे और समीक्षा माँगे। लिखने की अनुमति सिर्फ़ उन्हीं repositories तक सीमित रहती है जो आप देते हैं, और दायरा बस इतना ही है: issues, टिप्पणियाँ, और समीक्षा के लिए खोले गए pull requests। Okou merge नहीं करता, force push नहीं करता, और repository सेटिंग्स को हाथ नहीं लगाता।

Okou बनाम Slack के लिए GitHub ऐप बनाम ऑटोमेशन बिल्डर

Slack संदेश से बग को GitHub तक पहुँचाने के तीन हिस्से हैं: रिपोर्ट पकड़ना, काम लायक issue लिखना, और उसे किसी मालिक तक पहुँचाना। मौजूदा विकल्प इनमें से एक-एक हल करते हैं।

Slack के लिए GitHub ऐप

/github टाइप करने पर एक डायलॉग खुलता है जिसमें शीर्षक, विवरण, labels और assignee आप खुद भरते हैं। ब्राउज़र तक जाने की मेहनत बचती है, पर issue अब भी आप ही लिखते हैं, और बातचीत के बीच में आया फ़ॉर्म ठीक वही रुकावट है जिसकी वजह से लोग कहते हैं “बाद में दर्ज कर दूँगा”।

ऑटोमेशन बिल्डर

कोई no-code टूल किसी trigger पर Slack संदेश को नए issue में कॉपी कर सकता है। वह कच्चा संदेश ही कॉपी करता है, तो issue में वही उतरता है जो रिपोर्ट करने वाले ने उस समय लिख दिया, और labels, प्राथमिकता, assignment और डुप्लिकेट के नियम आपको हर चैनल के लिए खुद तय और रखरखाव करने पड़ते हैं।

Okou का Slack से GitHub वर्कफ़्लो

Okou थ्रेड पढ़कर issue लिखता है: असली शीर्षक, अपेक्षित व्यवहार से अलग किए गए reproduce करने के चरण, ऐसे labels और प्राथमिकता जिनका कारण वह बता सके, और रिपोर्ट करने वाले के display name से मिलाया गया assignee। जब कारण एक ही component तक सीमित हो, तो वह आगे बढ़कर फिक्स और regression test वाला pull request खोलता है, उसे issue से जोड़ता है और आपकी समीक्षा का इंतज़ार करता है। वह पहले खुले issues जाँचता है और डुप्लिकेट बनाने के बजाय उस पर टिप्पणी करता है, और थ्रेड में लिंक के साथ जवाब देता है।

बेहतर परिणामों के लिए सुझाव

असाइनी का नाम शामिल करें। Okou Slack डिस्प्ले नामों को GitHub यूज़रनेम से मिलाता है।
अगर आप ख़ास लेबल चाहते हैं तो उनका साफ़ ज़िक्र करें, नहीं तो Okou संदर्भ से अनुमान लगाता है।
फ़ीचर अनुरोधों के लिए भी काम करता है, बस "bug" के बजाय "feature request" कहें।
जब आपको सिर्फ़ टिकट नहीं, फिक्स भी चाहिए तो कहिए "और एक PR भी खोलो"। अगर कारण इतना फैला हो कि सुरक्षित रूप से बदला न जा सके, तो Okou थ्रेड में बता देगा।

अक्सर पूछे जाने वाले सवाल

Slack संदेश से GitHub issue कैसे बनाएँ?

Slack और GitHub को Okou से जोड़ें, चैनल में बग बताएँ और Okou को mention करें। वह संदेश और आसपास के जवाब पढ़ता है, शीर्षक, reproduce करने के चरण, अपेक्षित व्यवहार, labels और प्राथमिकता के साथ issue लिखता है, आपकी बताई repository में बनाता है, assign करता है, और थ्रेड में issue नंबर व लिंक के साथ जवाब देता है। आपको कोई फ़ॉर्म नहीं भरना पड़ता।

यह Slack के लिए GitHub ऐप से कैसे अलग है?

GitHub ऐप आपको भरने के लिए डायलॉग देता है: शीर्षक, विवरण, labels और assignee आप लिखते हैं। Okou इन्हें बातचीत से लिखता है, बनाने से पहले उसी लक्षण वाला मौजूदा issue जाँचता है, और एक-एक संदेश के बजाय पूरे चैनल को निर्धारित समय पर संभाल सकता है।

क्या Okou सिर्फ़ issue बनाता है, या बग ठीक भी कर सकता है?

दोनों, और वह बताता है कि उसने क्या किया और क्यों। issue वह हमेशा बनाता है। जब थ्रेड या कोड किसी एक component की ओर इशारा करे, अपेक्षित व्यवहार स्पष्ट हो, और पहले एक फेल होने वाला test लिखा जा सके, तो वह फिक्स और उस test वाला pull request भी खोलता है, उसे issue से जोड़ता है और समीक्षा माँगता है। साझा utilities, design tokens, और जो कुछ भी प्रोडक्ट निर्णय माँगता है, उसे बदला नहीं जाता, सिर्फ़ दर्ज किया जाता है। Okou कभी merge नहीं करता; हर फिक्स एक pull request के रूप में आता है जिसकी समीक्षा आप करते हैं।

क्या Okou issue को अपने आप सही व्यक्ति को assign कर सकता है?

हाँ। Okou आपके बताए नाम, या रिपोर्ट करने वाले के Slack display name को repository के GitHub handles से मिलाकर issue assign करता है। संदेश में assignee का नाम लिखना सबसे भरोसेमंद तरीका है; जब कोई नाम न हो तो Okou उस हिस्से के मालिक पर लौटता है जिसकी ओर थ्रेड इशारा करता है, और issue में लिख देता है कि उसने कैसे तय किया।

Okou डुप्लिकेट GitHub issues से कैसे बचता है?

कुछ भी बनाने से पहले Okou उसी लक्षण, प्रभावित हिस्से और शब्दों वाले खुले issues खोजता है। मेल मिलने पर वह नए Slack थ्रेड को रिपोर्ट करने वाले और समय के साथ उसी issue पर टिप्पणी के रूप में जोड़ देता है, और दूसरा issue खोलने के बजाय Slack में मौजूदा issue का लिंक भेज देता है।

अगर बग रिपोर्ट में reproduce करने के चरण न हों तो?

Okou फिर भी issue बनाता है ताकि रिपोर्ट खो न जाए, उस पर reproduce करने के चरण चाहिए का label लगाता है, और Slack थ्रेड में रिपोर्ट करने वाले से वे चरण माँगता है। जवाब फिर उसी थ्रेड में आता है जो पहले से issue से जुड़ा है।

क्या Okou पूरे चैनल से निर्धारित समय पर बग दर्ज कर सकता है?

हाँ। Okou को एक या अधिक चैनल दें और एक शेड्यूल बताएँ, जैसे हर शुक्रवार शाम 4 बजे। वह उस सप्ताह के संदेश पढ़ता है, हर उस संदेश के लिए issue बनाता है जो किसी खामी का वर्णन करता है, डुप्लिकेट पर टिप्पणी करता है, फ़ीचर अनुरोध और सवाल छोड़ देता है, और बताता है कि उसने क्या किया।

क्या यह GitHub की जगह Linear या Jira के साथ काम करता है?

यही वर्कफ़्लो किसी भी ऐसे tracker पर लागू होता है जिससे Okou जुड़ा हो; यह पेज GitHub का रास्ता बताता है, जो GitHub connector इस्तेमाल करता है। Linear भी इसी तरह जोड़ा जाता है, और tracker का नाम आप निर्देश में देते हैं।

अगला बग Slack छोड़े बिना दर्ज करें

Slack और GitHub जोड़ें, बग को वैसे ही बताएँ जैसे किसी साथी को बताते, और Okou को issue लिखने और assign करने दें। जब कारण सीमित हो, तो pull request भी आपका इंतज़ार कर रहा होगा।

Help me with: Slack संदेश को GitHub issue में बदलें, और फिक्स तक ले जाएँ