Information: कोड पीआर की समीक्षा अवधि

मेरी यह भी धारणा थी कि यह प्रक्रिया समुदाय-केंद्रित रेपो को ध्यान में रखकर लिखी गई थी, यानी संगठनात्मक परिवर्तनों के करीब पीआर।

सहमत, कोड को उन नियमों को लागू करने के रूप में देखा जा सकता है जो संगठन के काम करने के तरीके को बदलते हैं, लेकिन हम कैसे कोड पर कठोर प्रतिबंध लागू करने योग्य नहीं हैं। यह विकास को एक व्यावहारिक पड़ाव पर रोक देगा।

हो सकता है कि इस पर प्रक्रिया को और स्पष्ट करें, इसलिए इसे कोड पीआर पर लागू नहीं किया गया है?

जितनी जल्दी हो सके? तो आप आदर्श रूप से पुल अनुरोध या समस्या खोलने के तुरंत बाद विलय कर देंगे? क्या हमें संवाद के लिए एक खिड़की की जरूरत है?

मैं तुरंत तर्क दूंगा कि जो संभव है उससे परे है। :-) हमें समीक्षकों को एक सूचित समीक्षा करने की अनुमति देने की आवश्यकता है, लेकिन चूंकि उन्हें ऐसा करने के लिए पहले से ही समय चाहिए, और ऐसा करने से पहले कोई विलय नहीं होता है, "तुरंत" केवल काल्पनिक है।

इसलिए, मैं @megoth से पूरी तरह सहमत नहीं हूं, कि हम प्रक्रिया को कोड पर लागू नहीं कर सकते, क्योंकि कोड परिवर्तन हैं जो विवादास्पद हैं।

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

मुझे लगता है कि यहां लब्बोलुआब यह है कि विलय से पहले प्रत्येक पीआर (चाहे कोड के लिए या अन्यथा) को कितने समय तक आयोजित किया जाना चाहिए, इसके लिए वास्तव में एक कठिन और तेज़ नियम नहीं हो सकता है।

बहुत सारे कोड परिवर्तन, और बहुत सारे मानवीय-सामना करने वाले दस्तावेज़ परिवर्तन, गैर-विवादास्पद होंगे, और पीआर जमा करने और "फिक्स्ड टाइपो" जैसी किसी चीज़ पर विलय के बीच 14 दिन या 3 दिन या यहां तक ​​​​कि 3 घंटे की देरी के लिए बाध्य करने का कोई कारण नहीं है। , हाइपरलिंक से हाइपरलिंक"...

पीआर की समीक्षा आम तौर पर किसी ऐसे व्यक्ति द्वारा की जानी चाहिए जो चीजों को बदलने से परिचित हो - चाहे वह कोड हो या नहीं। ऐसा कुछ कहना उचित प्रतीत होता है जैसे "w OR ((x और/या y) और z) इस रेपो/फ़ाइल/जो कुछ भी के लिए सभी पीआर की समीक्षा करेंगे" - समीक्षकों के कार्यभार के साथ समीक्षा की समय सीमा अच्छी तरह से भिन्न हो सकती है पल के साथ-साथ पीआर लक्ष्य!

संभावित रूप से विवादास्पद परिवर्तन - किसी भी प्रकार का - उन समीक्षकों द्वारा देखा जाना चाहिए, जिन पर भरोसा किया जाना चाहिए, फिर व्यापक समीक्षा का अनुरोध किया जाना चाहिए, संभावित रूप से किसी भी प्रकार के "उच्च-अप" सहित।

मेरे द्वारा एक निश्चित अवधि का विकल्प चुनने का कारण यह है कि 1 के बारे में बातचीत हुई है) मुद्दों और पुल अनुरोधों को तेजी से पर्याप्त रूप से निपटाया नहीं जा रहा है 2) मुद्दों और पुल अनुरोधों को पर्याप्त रूप से प्रकाशित नहीं किया जा रहा है ताकि इनपुट और वैधता देने का मौका मिल सके। परिणामस्वरूप सुझावों पर सवाल उठाया जा रहा है। इसे स्पष्ट रूप से न लिखने का अर्थ है कि सॉलिड पर लंबे समय तक काम करने वाले लोगों को नए कामर्स पर एक फायदा होता है, जिन्हें समुदाय में शामिल होने के लिए एक खुले पारदर्शी वातावरण में शामिल होने के लिए सगाई के अनकहे नियमों का अनुमान लगाना पड़ता है।

एक समाधान के रूप में हम कहेंगे कि सभी पुल अनुरोधों और मुद्दों को प्रकाशित करने के बाद संभालने के लिए 3 दिन की अवधि है?

मुझे अभी भी इसके साथ "एक आकार सभी फिट बैठता है" समाधान के रूप में समस्या है। मुझे लगता है कि कोड गुणवत्ता और परियोजना की प्रगति के लिए इसके कई हानिकारक प्रभाव होंगे।

सबसे पहले, सगाई के ऐसे कोई अनकहे नियम नहीं हैं जो कम से कम पांच वर्षों से नहीं हैं, और यह हजारों और हजारों परियोजनाओं में बहुत ही मानक अभ्यास है। इसलिए, दी गई, यदि आप समग्र रूप से विकास के लिए पूरी तरह से नए हैं, तो आप नुकसान में होंगे, लेकिन यह सॉलिड के साथ किसी विशेष चीज के कारण नहीं है, प्रयास के एक नए क्षेत्र में प्रवेश करते समय हमेशा सीखने की अवस्था शामिल होती है। जैसा कि मैंने कहा है, मेरे लिए यह महत्वपूर्ण है कि सॉलिड में प्रवेश के लिए बहुत कम सीमा है, लेकिन मुझे यकीन नहीं है कि सर्वर विकास वह जगह है जहां लोगों को अपने कौशल, वातावरण को विकसित करना शुरू करना चाहिए जहां उन्हें अन्य के साथ मिलकर सहयोग करने की आवश्यकता नहीं होगी। समान कोड आधार पर डेवलपर्स शायद उनके लिए बेहतर अनुकूल हैं।

कई, यदि अधिकतर नहीं, तो पीआर में स्वाभाविक रूप से तीन दिनों से अधिक की समीक्षा अवधि होगी, जो समीक्षकों की उपलब्धता से सीमित होगी। हालांकि, हम अपेक्षाकृत छोटे पीआर के लिए भी स्वाभाविक रूप से प्रयास कर रहे हैं जिनकी समीक्षा करना आसान है। ऐसा करना एक अच्छा अभ्यास है, ताकि आपको जल्दी प्रतिक्रिया मिल सके और यह समीक्षकों के लिए बहुत कठिन न हो। हालांकि, अक्सर इसका मतलब है कि एक बड़े कार्य को हल करने में कई, वृद्धिशील पीआर शामिल होंगे। यदि प्रत्येक पीआर को तीन दिन की समीक्षा अवधि की आवश्यकता होती है, तो यह विकास को काफी धीमा कर देगा। यदि यह नीति है, तो मुझे संदेह है कि हम डेवलपर्स के रूप में छोटे पीआर नहीं लिखेंगे, बल्कि एक बड़ा पीआर करेंगे ताकि आपको प्रत्येक के लिए तीन-दिवसीय समीक्षा अवधि की प्रतीक्षा करने की आवश्यकता न हो।

इसके परिणामस्वरूप बड़े पीआर होंगे जिनकी समीक्षा करना कठिन होगा, चुस्त विकास से प्रस्थान, और अधिक जोखिम वाली गलतियाँ समीक्षा प्रक्रिया के माध्यम से छिप जाएंगी।

मुझे यह जानने में बहुत दिलचस्पी होगी कि इस संबंध में अन्य बड़ी परियोजनाएं क्या कर रही हैं, लेकिन मेरे लिए, एक आकार-फिट सभी दृष्टिकोण न तो वांछनीय है और न ही प्राप्त करने योग्य है।

मेरे लिए यह कहना मुश्किल है, क्योंकि मैं एक रिलीज मैनेजर हूं, लेकिन मुझे लगता है कि @TallTed इसका समर्थन करेगा, यह प्रक्रिया काफी हद तक रिलीज मैनेजर के विवेक पर होनी चाहिए। रिलीज मैनेजर को यह सुनिश्चित करना होगा कि सबसे उपयुक्त समीक्षकों से पूछा जाए, कि समस्या के आधार पर उपयुक्त संख्या में समीक्षकों से पूछा जाता है, और यह विलय नहीं होता है इससे पहले कि समीक्षकों की सही संख्या ने अनुमोदन के साथ प्रतिक्रिया दी है, जो विलय करता है ऐसा नहीं होगा यदि परिवर्तन का अनुरोध किया गया है, कि समीक्षा प्रक्रिया को लागू करने के लिए सही शाखाओं को बंद कर दिया गया है, संभावित रूप से विवादास्पद पीआर को अधिसूचना के कुछ माध्यमों के माध्यम से समुदाय के नेता का ध्यान लाया जाता है, और वास्तव में, अन्य समीक्षक निश्चित रूप से ऐसा करने के लिए स्वागत करते हैं भी।

बस समुदाय समर्थन मीटिंग वार्तालाप से नोट्स शामिल करना चाहता था। इन बिंदुओं को सॉलिड टीम के भीतर अलग-अलग लोगों द्वारा बनाया गया था:

• 3 दिनों की समीक्षा अवधि ठोस कार्य को धीमा कर सकती है।
• समयावधि का व्यावहारिक लाभ क्या है? व्यावहारिक लाभ पारदर्शी निर्णय लेने की प्रक्रिया के साथ एक अधिक खुला समावेशी वातावरण बनाना होगा जिसे समझा जा सकता है और वापस संदर्भित किया जा सकता है।
• हम किस समस्या को हल करने की कोशिश कर रहे हैं? क्या इसे हल करने के अन्य तरीके हैं? हम वास्तव में जो हल करने की कोशिश कर रहे हैं वह यह है कि जब परिवर्तन किए जाते हैं तो कुछ बाधाएं होती हैं और उनके पास अपना दृष्टिकोण प्रदान करने का अवसर नहीं होता है। समय सीमा अवसर देने का एक तरीका है। समावेशन को आमंत्रित करने का एक अन्य तरीका यह सुनिश्चित करना है कि सुझाव ऐसे वातावरण में पोस्ट किए गए हैं जिन्हें लोग जांच सकते हैं, उदाहरण के लिए, ठोस/सुझाव।
  - भेदभाव जड़ के बजाय एक साइड इफेक्ट है।
• समावेशिता और दक्षता के बीच की रेखा कहाँ है? डो-ओक्रेसी आपको उन लोगों को तय करने देना है जो सामान करते हैं। थोड़ी स्वायत्तता रखना एक और चरम है जिसकी ओर हमें नहीं जाना चाहिए। मेटिरोक्रेसी - do-ocracy। इन आदर्शों का कार्यान्वयन अल्पसंख्यकों के लिए विषाक्त हो सकता है।

• आइए सबसे आगे रहने की कोशिश करें। हम गलतियों से क्या सीख सकते हैं। आइए सब कुछ वैसा न करें जैसा पहले किया गया है, आइए इस पर चिंतन करें कि हम जो कर रहे हैं वह क्यों कर रहे हैं। विशिष्टताओं का प्राकृतिक भाषा में अनुवाद करने पर काम करें। विशेष रूप से जब विनिर्देश विकसित हो रहे हों, तो उन्हें अद्यतित रखना कठिन होता है। यह बहुत लंबा हो सकता है, और लोगों के लिए पढ़ने में आसान हो सकता है, चबाने के लिए बहुत अधिक हो सकता है। कल्पना के भीतर विषयों को खोजने का प्रयास करने का प्रस्ताव। कल्पना को देखने के तरीकों को वितरित करने के तरीके खोजें। विभिन्न समस्याओं को हल करने के लिए और अधिक ट्यूटोरियल लिखें। कल्पना के तत्वों की व्याख्या करने वाले ब्लॉग पोस्ट के लिए भी जगह है। इसे चबाने योग्य टिटबिट्स में बनाएं।

• हम कमिट को हटा सकते हैं, वे प्रतिवर्ती हैं, हालांकि, उलटा व्यावहारिक है? समुदाय को वापस लाना धीमा है, इसलिए इसे उलटने में और भी अधिक समय लगेगा। सर्वर में वापस करना कठिन है क्योंकि पिछले निर्णयों के शीर्ष पर निर्मित आइटम।

• हम किसी अन्य प्रोजेक्ट से अलग कुछ नहीं कर रहे हैं। हालांकि एक समय अवधि निर्धारित करना पिछली प्रथाओं से अलग है, हम जो करने की कोशिश कर रहे हैं वह एक अलग मॉडल का निर्माण करना है, और पिछले मॉडल पर एक समरूप समूह का प्रभुत्व रहा है, इसलिए क्या हम पिछली प्रथाओं का उपयोग करना चाहते हैं या किनारे पर रहने का प्रयास करना चाहते हैं। सोचा था की? क्या हम पिछले उदाहरणों से सीख सकते हैं कि कैसे एक ही नुकसान में न पड़ें और विश्लेषण करें कि क्या काम किया? हम अलग होने का वादा कर रहे हैं - जो पहले काम करता था वह काम नहीं करता था।

• क्या हम रेपो के बीच अंतर कर सकते हैं? यदि हां, तो कैसे?

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

• नोड-सॉलिड-सर्वर के लिए एक हाइब्रिड नियम सेट किया जा सकता है, जिसमें कहा गया है कि यदि परिवर्तन कल्पना से विचलित होता है, तो इसे एक लंबी समीक्षा समय की आवश्यकता होती है। जिन मामलों में हम विशिष्टताओं से विचलित कोड में विनिर्देशों को लागू करते हैं, उनके लिए एक प्रक्रिया होना भी महत्वपूर्ण है।

• कार्यप्रवाह और चरणों का दस्तावेजीकरण नहीं किया गया है।

• गैर-इंजीनियरों की तुलना में इंजीनियर पाइपलाइन पर अधिक भरोसा करते हैं। शायद हम इस पर भरोसा कर रहे हैं। शायद कोई बात हो। डेवलपर संस्कृति की जनसांख्यिकी, शायद ऐसा इसलिए है क्योंकि हमें लगता है कि यह वैसा ही होना चाहिए जैसा होना चाहिए।
• मुख्य निर्णय तकनीकी के रूप में प्रच्छन्न होते हैं जब वास्तव में उनके तकनीकी से परे बड़े पैमाने पर निहितार्थ होते हैं।
• प्रभाव को समझने और लोगों को इसमें शामिल होने की अनुमति देने के लिए कोड का समाज पर जबरदस्त प्रभाव हो सकता है।
• प्राकृतिक भाषा - चश्मा किसी भी मामले में कुछ ताज़ा कर सकता है। ऐसा करने में बात समझाने का एक बेहतर तरीका है। तकनीकी तत्वों को गैर-तकनीकी के रूप में दोबारा लिखने तक नहीं जाएंगे। यह सुनिश्चित करने के लिए कि यह सही है, कल्पना की पठनीयता में सुधार करने का अवसर है। काफी धक्का-मुक्की करते हुए कह देंगे कि टेक्निकल निकाल लिया जाएगा।
  
  
  
  • हमें उन चीजों का निर्माण करने की आवश्यकता है जो स्वीकार की जाती हैं और इसलिए सभी को समझने योग्य होना चाहिए।
  
  

@TallTed क्या आपके पास पिछली टिप्पणी में मीटिंग मिनट्स पर कोई विचार है?

आगे बढ़ने के लिए मैं निम्नलिखित का प्रस्ताव करता हूं:

पुल अनुरोध और निम्नलिखित रेपो से जुड़े मुद्दों को कम से कम तीन दिनों तक खुला रहने की आवश्यकता है:
https://github.com/सॉलिड/सॉलिड-स्पेक
https://github.com/solid/web-access-control-spec
https://github.com/solid/webid-oidc-spec
https://github.com/solid/community

पुल अनुरोध और अन्य सभी रेपो से जुड़े मुद्दों को तुरंत बंद किया जा सकता है और उनके पास न्यूनतम समय नहीं होता है जब तक कि वे उस विनिर्देश से विचलित न हों जिस स्थिति में उन्हें कम से कम तीन दिनों के लिए खुला रहने की आवश्यकता होती है।

कोई एतराज?

मेरे लिये कार्य करता है। यह रिलीज मैनेजर के भूमिका विवरण में टेक्स्ट जोड़ने की भी संभावना है, यह वर्णन करते हुए कि उन्हें शेष रेपो के साथ क्या करना चाहिए।

मुझे यह समाधान भी अच्छा लगता है :smile_cat: आइए कहीं तर्क भी लिख लें, ताकि लोग इसके पीछे हमारी सोच को समझ सकें।

@kjetilk हां, मैं https://github.com/solid/community/pull/44 पर एक नोट जोड़ूंगा

@megoth OK समुदाय रेपो रीडमी में एक संक्षिप्त विवरण शामिल करेगा

https://github.com/solid/community/blob/master/README.md