Slack रिलीज़ अपडेट को ग्राहक-सामने वाले रिलीज़-नोट ड्राफ्ट में बदलें

अवलोकन

एक Computer स्वचालन हर घंटे Slack पर ग्राहकों के लिए पुष्टि किए गए रिलीज़ की जाँच करता है, लिंक किए गए GitHub परिवर्तनों, Linear समस्याओं और Notion में प्रोडक्ट प्रोजेक्ट की समीक्षा करता है, फिर डुप्लीकेट और स्वीकृत नामकरण के लिए पिछले रिलीज़ नोट्स की जाँच करता है। यह प्रकाशन या पोस्टिंग के बिना समीक्षा के लिए ग्राहकों के सामने आने वाले रिलीज़-नोट ड्राफ्ट और टीम सारांश तैयार करता है।

पहले परिणाम का समय: अगली प्रति घंटा जाँच को योग्य शिप संदेश मिलने के बाद; पहले उदाहरण के लिए तत्काल रन का अनुरोध करें।

कठिनाई: सेटअप की आवश्यकता है

आपको क्या चाहिए

• [release channel] तक पहुँच के साथ कनेक्ट किया गया Slack, ताकि ग्राहकों के सामने आने वाले पुष्टि किए गए रिलीज़ की पहचान की जा सके।
• लिंक किए गए pull request और समस्याओं तक पहुँच के साथ GitHub और Linear कनेक्ट किए गए हैं, ताकि ड्राफ्ट शिप किए गए दायरे को दर्शा सकें।
• [product Project] से जुड़ा Notion, ताकि स्वीकृत ग्राहक-सामने वाले नाम ड्राफ्ट का मार्गदर्शन करें।
• पिछले प्रविष्टियों और नामकरण नियमों के साथ एक रिलीज़ नोट्स लेजर, ताकि डुप्लीकेट और पुराने नामों की जाँच की जा सके।
• एक प्रति घंटा जाँच अनुसूची और एक समीक्षा स्वामी, ताकि योग्य अपडेट प्रकाशित नोटों के बजाय अनुमोदन के लिए ड्राफ्ट बन जाएं।

क्वेरी

आपको क्या वापस मिलता है

अनुसूचित रिपोर्ट डिलीवरी: समीक्षा के लिए ड्राफ्ट

काल्पनिक प्रोडक्ट विवरण और सचित्र स्रोत लिंक के साथ डेमो आउटपुट। पूर्ण किए गए ड्राफ्ट से अंश:

नामकरण जाँच:

“Product Project पुष्टि करता है कि "Scheduled Report Delivery" स्वीकृत नाम है। ड्राफ्ट इसका हूबहू उपयोग करता है। श्रेणी New है।”

डुप्लीकेट जाँच:

“LIN-4955, PR-3389, या "Scheduled Report Delivery" के लिए कोई पूर्व प्रविष्टि नहीं है।”

टीम सारांश:

“प्रस्तावित रिलीज़ टैग v2026.09.19-1।”

स्रोत कार्य में संपूर्ण डेमो ड्राफ्ट और लेज़र देखें।

• स्रोत समीक्षा: डेमो में एक GitHub pull request, एक Linear समस्या और मूल एपिक, और एक Notion प्रोडक्ट प्रोजेक्ट सूचीबद्ध है।
• नामकरण जाँच: “Scheduled Report Delivery” पुराने “Report Scheduler” लेबल की जगह लेता है।
• डुप्लीकेट जाँच: सुविधा नाम, समस्या ID, और pull request की तुलना पिछले रिलीज़ नोट्स से की जाती है।
• रिलीज़-नोट ड्राफ्ट: समीक्षा के लिए एक प्रस्तावित शीर्षक, श्रेणी, रिलीज़ टैग, लाभ विवरण, और सुविधा बुलेट।
• टीम सारांश: परिवर्तन, नामकरण निर्णय और डुप्लीकेट जाँच की व्याख्या करने वाला एक ड्राफ्ट Slack thread उत्तर।
• रिलीज़ नोट्स लेज़र: बाद की समीक्षाओं के लिए तीन सचित्र पूर्व प्रविष्टियाँ और नामकरण सम्मेलन।

एक Markdown ड्राफ्ट और एक अलग Markdown लेज़र के रूप में वितरित, समीक्षा और संशोधन के लिए तैयार; डेमो प्रकाशित रिलीज़ नोट या पोस्ट किया गया Slack उत्तर नहीं दिखाता है।

इसे बेहतर बनाएं

• संदर्भ जोड़ें: शब्दों और पात्रता दावों का मार्गदर्शन करने के लिए स्वीकृत रिलीज़ नोट्स और पुष्टि की गई योजना उपलब्धता शामिल करें।
• विशिष्टताओं पर इंगित करें: Slack चैनल, GitHub रिपॉजिटरी, Linear टीम और Notion प्रोजेक्ट का नाम बताएं जो रिलीज़ को परिभाषित करते हैं।
• प्रारूप के लिए पूछें: प्रत्येक ड्राफ्ट में ग्राहक लाभ, उपलब्धता विवरण, सुविधा बुलेट और स्रोत संदर्भों का अनुरोध करें।
• एक कौशल का उपयोग करें: स्वीकृत रिलीज़-नोट संरचना और नामकरण नियमों को एक पुन: प्रयोज्य कौशल के रूप में सहेजें।
• इसे आवर्ती बनाएं: जाँच के घंटे और समय क्षेत्र निर्दिष्ट करें, और जब कोई योग्य परिवर्तन दिखाई न दे तो मौन रहने के लिए कहें।

एक भिन्नता आज़माएं

[Slack ship-message link], इसके लिंक किए गए GitHub परिवर्तन, संबंधित Linear समस्याएँ, और [product Project in Notion] की समीक्षा करें। डुप्लीकेट और स्वीकृत नामकरण के लिए [release notes ledger] की जाँच करें। समीक्षा के लिए एक Markdown रिलीज़-नोट प्रविष्टि और टीम सारांश का ड्राफ्ट तैयार करें। कुछ भी शेड्यूल, प्रकाशित या पोस्ट न करें।

हर घंटे, [GitHub repository] में ग्राहक-सामने आने वाले शिप किए गए बग फिक्स के लिए [Slack channel] की जाँच करें। संबंधित Linear समस्याओं, [product Project in Notion], और [release notes ledger] की समीक्षा करें। समीक्षा के लिए टीम सारांश के साथ Fixed श्रेणी में Markdown प्रविष्टियों का ड्राफ्ट तैयार करें। कुछ भी प्रकाशित या पोस्ट न करें।

हर [Friday at time and time zone] पर, लिंक किए गए GitHub परिवर्तनों, Linear समस्याओं, [product Project in Notion], और [release notes ledger] के विरुद्ध [Slack channel] में पुष्टि किए गए रिलीज़ की समीक्षा करें। ग्राहक लाभ, स्वीकृत नाम और डुप्लीकेट-जाँच परिणामों के साथ एक एक-पेज का Markdown रिलीज़ डाइजेस्ट बनाएं। इसे समीक्षा के लिए रखें।

संबंधित उपयोग के मामले

• Computer Slack में दैनिक प्रोडक्ट विकास डाइजेस्ट भेजता है: रिलीज़ घोषणाएं बनने से पहले प्रोडक्ट टीम को निर्णयों और कार्यान्वयन परिवर्तनों पर संरेखित रखें।
• सहायता केंद्र लेखों को स्वचालित करें: प्रोडक्ट दस्तावेज़ीकरण को सहायता लेखों में बदलें जो बताते हैं कि नई रिलीज़ की गई सुविधाओं का उपयोग कैसे करें।
• अपनी कंपनी के लिए पुराने लैंडिंग पृष्ठों का पता लगाएं: लॉन्च के बाद पुराने दावों को फ्लैग करने के लिए नवीनतम रिलीज़ नोट्स के साथ सार्वजनिक पृष्ठों की तुलना करें।