प्रॉडक्ट की जानकारी लिखना

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की शिकायत करें सोर्स देखें रात · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

यह दस्तावेज़ बेज़ेल में योगदान देने वालों के लिए है.

Basel में कमिट के ब्यौरे में एक RELNOTES: टैग और एक रिलीज़ शामिल होती है नोट. इसका इस्तेमाल Basel की टीम, हर रिलीज़ में हुए बदलावों को ट्रैक करने और कॉन्टेंट लिखने के लिए करती है रिलीज़ की सूचना दें.

खास जानकारी

  • क्या आपने जो बदलाव किया है क्या उससे कोई गड़बड़ी हुई? ऐसे में, आपको रिलीज़ नोट की ज़रूरत नहीं पड़ती. प्लीज़ GitHub की समस्या के बारे में जानकारी दें.

  • अगर यह बदलाव बेज़ल को लोगों को दिखाई देने के हिसाब से जोड़ता / हटाता / बदलता है, तो इस्तेमाल करना फ़ायदेमंद हो सकता है.

अगर बदलाव अहम है, तो डिज़ाइन दस्तावेज़ देखें नीति को पहले लागू करें.

दिशा-निर्देश

रिलीज़ नोट हमारे उपयोगकर्ता पढ़ेंगे. इसलिए, यह छोटा होना चाहिए (बेहतर होगा वाक्य, कठिन शब्दों का इस्तेमाल करने से बचें, (बेज़ल-इंटरनल शब्दावली), इसलिए ज़रूरी है कि बदलाव शुरू होने वाला है.

  • सही दस्तावेज़ का लिंक शामिल करें. आम तौर पर, सभी रिलीज़ नोट में उस फ़ाइल में एक लिंक मौजूद हो. अगर जानकारी में किसी फ़्लैग, सुविधा, किसी कमांड के नाम के बारे में बताया गया है, उपयोगकर्ता इस बारे में ज़्यादा जानना चाहेंगे.

  • कोड, सिंबल, फ़्लैग या ऐसे किसी भी शब्द के चारों ओर बैककोट का इस्तेमाल करें जिसमें अंडरस्कोर देखें.

  • सिर्फ़ गड़बड़ी की जानकारी कॉपी और पेस्ट न करें. वे अक्सर छुपे होते हैं और केवल छुपे होते हैं उन्हें समझना पसंद है और उपयोगकर्ता को उनके सिर खुजाना छोड़ देना चाहिए. रिलीज़ नोट ये हैं का मतलब है कि क्या बदला है और क्यों किया गया है.

  • हमेशा वर्तमान काल और "Baज़ल अब Y का समर्थन करता है" फ़ॉर्मैट का इस्तेमाल करें या "X अब करता है ज़ेड॰" हम नहीं चाहते कि हमारे रिलीज़ नोट, गड़बड़ी की एंट्री की तरह दिखें. सभी रिलीज़ नोट में दी गई जानकारी जानकारी देने वाली होनी चाहिए. साथ ही, उसकी स्टाइल और भाषा एक जैसी होनी चाहिए.

  • अगर किसी चीज़ को बंद कर दिया गया है या हटा दिया गया है, तो "X को बंद कर दिया गया है" विकल्प का इस्तेमाल करें या "X को हटा दिया गया है." "हटाया गया" नहीं या "हटा दिया गया है."

  • अगर Baze अब कुछ अलग तरीके से काम करता है, तो इसके बजाय "X अब $newBehavior का इस्तेमाल करें $oldव्यवहार" वर्तमान काल में होता है. इससे उपयोगकर्ता को यह पता चलता है कि उसे कि वे नई रिलीज़ का इस्तेमाल कब करेंगे.

  • अगर Basel अब काम करता है या अब किसी सुविधा के साथ काम नहीं करता, तो "Bazu अब काम करता है" का इस्तेमाल करें / अब X के साथ काम नहीं करता".

  • इस बारे में जानकारी दें कि क्यों कुछ हटा दिया गया है / काम नहीं कर रहा है / उसमें बदलाव क्यों किया गया है. एक वाक्य है लेकिन हम चाहते हैं कि उपयोगकर्ता उनके निर्माण पर पड़ने वाले प्रभाव का मूल्यांकन कर सकें.

  • आने वाले समय में मिलने वाले फ़ंक्शन के बारे में कोई वादा न करें. "इस फ़्लैग का इस्तेमाल करके हटाया गया" या "इसे बदल दिया जाएगा." इसकी वजह से अनिश्चितता होती है. सबसे पहला काम उपयोगकर्ता को लगेगा कि "कब?" और हम नहीं चाहते कि वे इस बात की चिंता करना उनका मौजूदा बिल्ड अचानक टूट जाता है.

प्रोसेस

रिलीज़ के भाग के रूप में प्रोसेस, हम हर प्रतिबद्धता के लिए RELNOTES टैग इकट्ठा करते हैं. हम हर चीज़ को Google की दस्तावेज़ जहां हम नोट की समीक्षा करते हैं, उनमें बदलाव करते हैं, और उन्हें व्यवस्थित करते हैं.

रिलीज़ मैनेजर bazel-dev के ईमेल पतों की सूची. गेम में योगदान देने वाले लोगों को दस्तावेज़ में योगदान देने के लिए न्योता भेजा जाता है. साथ ही, यह पक्का किया जाता है कि उनके किए गए बदलाव, सूचना में सही तरीके से दिख रहे हों.

बाद में, सूचना को Baazल पर सबमिट कर दिया जाएगा ब्लॉग पेज पर, bazu-blog का इस्तेमाल करके डेटा स्टोर करने की जगह.