जैसा कि अनुरोध किया गया है, 2019 में जंग के विकास के लिए मेरे सुझाव यहां दिए गए हैं।

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

मुझे यह भी ध्यान देना चाहिए कि मैं आमतौर पर रस्ट के विकास से संतुष्ट हूं, और यह प्रस्ताव केवल कुछ समस्याओं से बचने के लिए है जो अब मैं बाहर से निरीक्षण करता हूं।

TL; DR: समस्या को स्वीकार करना और दो चीजों के विकास को सीमित करने के लिए स्पष्ट तंत्र की योजना बनाना महत्वपूर्ण है:

1. अनिवार्य सामान्य तकनीकी कलाकृतियों, विशेष रूप से एक भाषा की बहुत परिभाषा।
2. इन कलाकृतियों की चर्चा में शामिल लोगों पर बोझ।

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

कृपया ध्यान दें कि मैं कई अन्य क्षेत्रों की विकास सीमाओं के बारे में नहीं लिख रहा हूं। उदाहरण के लिए, एक पैकेज इंडेक्स, साइट का आकार, या यहां तक ​​कि एक उपयोगकर्ता समुदाय। यह स्पष्ट नहीं है कि यह किस प्रकार का खतरा है, यह रुस्त है, इसलिए हम केवल दो विशिष्ट मुद्दों के बारे में बात कर रहे हैं।

सीमित कारक और उड़ान

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



जब एक प्रणाली एक अनियंत्रित तरीके से या अचानक एक सीमा का सामना करती है, तो एक घटना हो सकती है जो लक्ष्य की उड़ान या यहां तक ​​कि वापसी की तरह दिखती है: सीमा अभी भी मौजूद है, लेकिन इसका प्रभाव पतन या संकट की तरह अधिक महसूस होता है। एस-वक्र एक शिखर तक बढ़ जाता है, इसके बाद पतन होता है। मैं इससे बचना चाहूंगा।

अच्छा नियंत्रण उदाहरण

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

• बोर्स कतार कार्यक्रम के लिए शुद्धता परिवर्तन को रोक देती है।
• गड्ढा छोड़ देता है पारिस्थितिकी तंत्र शुद्धता जारी करता है।
• नियोजित सुविधा तैयार नहीं है, भले ही नियोजित रिलीज़ समय पर जारी किए जाने के लिए पसंद की जाती हैं । निर्णय समय पर किया जाता है, और बिना तैयारी के सब कुछ कट जाता है।

इसके अलावा, परियोजना के प्रतिभागियों की संख्या को सीमित करने के लिए परियोजना के भीतर महत्वपूर्ण सामाजिक संरचनाएं बनाई गई हैं।

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

यह सब, संक्षेप में, मान्यता है कि नियंत्रण की अनुपस्थिति में परेशानी और संकट उत्पन्न हो सकते हैं: कम से कम अराजकता और कुछ हद तक रोग। यदि संभव हो, तो नियंत्रण स्वचालित और पूरी तरह से निष्पक्ष है (बीमार इच्छाशक्ति और व्यक्तिपरक मूल्यांकन को कम करने के लिए, कोनों को काटने का प्रलोभन), यदि व्यक्तिवाद से बचा नहीं जा सकता है, तो कम से कम नियमों और प्रक्रियाओं को स्पष्ट रूप से लिखित, अच्छी तरह से ज्ञात स्थानों में लिखित रूप में तैयार किया जाता है। ।

समस्या क्षेत्रों

आइए हम उन दो समस्या क्षेत्रों पर लौटते हैं, जहाँ परियोजना में वर्तमान में पर्याप्त तंत्र या नीतियां नहीं हैं, जिससे रुस्ट को नियंत्रित किया जा सके, जो संभावित शिथिलता या संकट का जोखिम वहन करती है। दोनों मामलों में, यह पूरी तरह से स्पष्ट नहीं है कि परियोजना अब इस तरह के संकट से कितनी दूर है। लेकिन किसी भी मामले में, देर से होने की तुलना में पहले से कार्य करना बेहतर होता है।

1. भाषा ही है । इसकी परिभाषा है। यह (परियोजना के कई हिस्सों के विपरीत) एक अनिवार्य सामान्य तकनीकी विरूपण साक्ष्य है। हर कोई उसमें दिलचस्पी लेता है, और प्रत्येक परिवर्तन संभावित रूप से सभी को प्रभावित करता है। इसके अलावा, हर किसी को इसके आवश्यक हिस्से का अध्ययन और समझना चाहिए: निर्बाध भागों की उपेक्षा करना असंभव है। यहां तक ​​कि जिसे आप अनदेखा करना चाहते हैं वह एक सामान्य संदर्भ में मौजूद है: प्रलेखन और प्रशिक्षण सामग्री, परीक्षण उदाहरण और परीक्षण सामग्री, आंतरिक संकलक घटक, औपचारिक मॉडल, कोड आधार, सामान्य रखरखाव लोड, आदि।
   
   यहाँ एक कलाकृति के रूप में भाषा का विकास कम से कम निम्नलिखित कारकों द्वारा सीमित है:
   
   
   • एक शुरुआत के लिए एक भाषा सीखने का अवसर।
   • औसत उपयोगकर्ता की क्षमता आत्मविश्वास महसूस करने के लिए, अन्य लोगों के कोड आधारों के अनुकूल है।
   • एक विशेषज्ञ या अनुरक्षक की क्षमता सभी (या अधिकांश) को जानने के लिए बदलती है।
   • नए और चल रहे काम के संदर्भ में प्रत्येक नए परिवर्तन की लागत और लाभ का अनुपात। लोगों की संख्या या उन मामलों का उपयोग जो इससे लाभान्वित होते हैं। लागत डिजाइन और भाषा के आकार के कई आयामों में दहनशील हैं। वे लगभग हमेशा बढ़ जाते हैं।
   
   यदि आप इन सीमाओं का पालन नहीं करते हैं, तो आप बहुत गंभीर जोखिमों का सामना कर सकते हैं:
   
   
   • महत्वपूर्ण सुरक्षा गारंटी को बनाए रखने में असमर्थता के लिए अनुचित भाषा परिवर्तन।
   • अत्यधिक जटिलता की प्रतिष्ठा, उपयोगकर्ताओं की हानि। अगला C ++ या हास्केल बनने का जोखिम।
   • अधूरा परिभाषा, परीक्षण, प्रलेखन के साथ खराब गुणवत्ता वाले कार्य।
   • उन विशेषताओं को रेखांकित किया गया है जो अन्यत्र आवश्यक प्रयास करती हैं।
   • बोलियों में कुचल, पृथक कार्यक्रम, मूल्य में कमी।
2. भाषा पर काम कर रहे लोगों पर बोझ । परियोजना के कुछ हिस्सों को सभी उपलब्ध डेवलपर्स के बीच वितरित किया जा सकता है। ये आम तकनीकी कलाकृतियां नहीं हैं। कुछ हद तक, कई लोगों (और अधिक से अधिक) को लगभग सभी परिवर्तनों में भाग लेना पड़ता है । इसका मतलब है कि इस समूह में सभी पर बहुत अधिक दबाव है: उन्हें सभी चर्चाओं का पालन करना चाहिए, और परिवर्तनों की संख्या और चर्चाओं में भाग लेने वालों की संख्या बढ़ रही है।
   
   परियोजना के प्रतिभागियों के लिए इस भार की वृद्धि पर कुछ प्रतिबंध:
   
   
   • प्रति दिन घंटों की संख्या।
   • प्रति दिन भुगतान किए गए घंटों की संख्या।
   • परियोजना के बाहर की जिम्मेदारी और रुचियां।
   • जो हो रहा है उसे समझने के लिए मानसिक ऊर्जा का भंडार।
   • बातचीत में शामिल सभी की राय में विश्वास।
   • पढ़ने और चर्चा के लिए मनोवैज्ञानिक और भावनात्मक ऊर्जा का भंडार।
   • बातचीत में शामिल सभी के अच्छे विश्वास का अनुमान।
   
   इन सीमाओं को पार करने के जोखिम भी संभावित रूप से बहुत गंभीर हैं:
   
   
   • थकावट या जलन के कारण किए गए बुरे निर्णय।
   • बढ़ती असमानता: केवल सबसे विशेषाधिकार प्राप्त, सस्ती, ऊर्जावान, अच्छी तरह से भुगतान, या अन्यथा सुव्यवस्थित प्रतिभागी हर चीज का ट्रैक रख सकते हैं।
   • प्रवचन को संक्षिप्त करना: ध्यान से "विवाद जीतने" से।
   • चारों ओर मूर्ख लोग, बाहर जला, बुरा व्यवहार करते हैं, परियोजना छोड़ देते हैं।
   • निराशा, बेईमानी का आरोप, आक्रोश, षड्यंत्रकारी सोच, कांटे।
   
   मैं इस बात पर जोर देना चाहता हूं कि वर्णित सीमाएं और जोखिम विशिष्ट लोगों के लिए पूरी तरह से विशिष्ट नहीं हैं या यहां तक ​​कि समग्र रूप से जंग परियोजना भी नहीं है। एक अलग डिग्री के लिए, वे कहीं भी पाए जाते हैं। बस उन लोगों के साथ वर्तमान अनुरक्षकों (उदाहरण के लिए) को बदलना जो वास्तव में समस्या का समाधान नहीं करेंगे: प्रतिबंध रहेगा। एक सीमा के साथ टकराव में एकमात्र समाधान विचारशील प्रबंधन है। नियंत्रण रखना।

संभावित नियंत्रण विकल्प

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

1. नकारात्मक रूप से परिभाषित स्थान । भाषा के भविष्य के विकास के लिए योजनाओं से कार्यों और अवधारणाओं पर चर्चा करने की प्रक्रिया को लें। RFC को अनुमति दें (या प्रोत्साहित करें) जो कहते हैं कि "Rust में X कभी नहीं होगा" X के कुछ मान के लिए। इसलिए हमें निष्पक्ष चर्चा और लंबी अवधि के परिवर्तन पर आपत्तियों पर विचार करने के लिए एक बार का दौर मिलता है ("कभी नहीं" काफी लंबा समय है!)। फिर यह चर्चा हमेशा के लिए खत्म हो जाएगी। यह विमुख संघर्ष का शाश्वत स्रोत नहीं बनेगा। कुछ उदाहरण जहां नकारात्मक स्थान परिभाषित किए गए हैं:
   
   
   • स्थायी रूप से टाइप सिस्टम से निश्चितता की कुछ श्रेणियों को हटा दें (उदाहरण के लिए, निर्भर प्रकार, एचकेटी, आदि);
   • सिंटैक्स से (जैसे पैरामीटर कुंजी, स्थिति या नामित तर्क);
   • तत्व विचारों के एक सेट से (उदाहरण के लिए, अनाम पोस्ट प्रकार);
   • मध्य-अंत (उदाहरण के लिए, स्थिरांक के संश्लेषण, निहित तर्क) के उत्पादन के लिए दायित्वों के एक सेट से।
   
   कुछ सख्त प्रतिबंध निर्धारित करें: इन वस्तुओं से बचने के लिए, साथ ही साथ वे लोग जो "सब कुछ सही करने" का लक्ष्य निर्धारित करते हैं।
2. विकास लागतों को स्पष्ट रूप से कहा जाना चाहिए। WebAssembly के परिवर्तनों की सूची से एक पृष्ठ लेते हुए, यह स्पष्ट करें कि प्रारंभिक चरण में, इस तरह के RFC को कार्यान्वयन, औपचारिकता, प्रलेखन में संशोधन, प्रशिक्षण सामग्री का पुनरीक्षण, लेखन परीक्षण, रखरखाव, आदि में उचित निवेश की आवश्यकता होगी, अगर इस स्तर पर कवर नहीं किया जा सकता है। पोस्टपोन बदल जाता है "जब तक एक प्रायोजक नहीं मिलता है।"
3. सीखने की गति और सामग्री की मात्रा के लिए लक्ष्य निर्धारित करें। विपरीत दिशा में काम करने की कोशिश करें: समय की मात्रा और भाषा सीखने या उसमें एक विशेषज्ञ बनने के लिए आवश्यक पृष्ठों की संख्या से आगे बढ़ें - और फिर इस ढांचे से परे जाने वाली सभी चीज़ों को हटा दें। यदि "21 दिनों में जंग सीखना" काम नहीं करता है, तो सही अंतराल ढूंढें। तीन महीने? छह? वर्ष? उन भाषाओं के बारे में सोचें जिनके सीखने में "निश्चित रूप से बहुत अधिक समय लगता है" और कम संख्या चुनें। क्या 1000 पेज का मैनुअल ठीक है? 500? 300?
4. अन्य स्वचालित सीमाएं निर्धारित करें : कंपाइलर में कोड की पंक्तियों की संख्या, कुल डाउनलोड समय, AWS उदाहरणों के लिए प्रति दिन डॉलर, व्याकरण में नियमों की संख्या, प्रकार प्रणाली में, परीक्षण कवरेज का प्रतिशत, दस्तावेजों का प्रतिशत जिन्हें "अपूर्ण" के रूप में चिह्नित किया जा सकता है। रचनात्मक बनें, उन प्रासंगिक चीजों का पता लगाएं जो मापने योग्य हैं, और फिर उन्हें सीमित करने के लिए तंत्र को लागू करें।
5. व्यक्तिगत समय सीमा : कितने घंटे (या भुगतान किए गए समय) एक व्यक्ति वास्तव में थकावट या बर्नआउट के बिना एक परियोजना के लिए समर्पित कर सकता है, जिसमें न्यूनतम अधिकार वाले प्रतिभागी शामिल हैं। समूहों, व्यक्तिगत रिलीज़ और संबंधित कार्य योजनाओं पर समान प्रतिबंध सेट करें। फिर निकालें या स्थगित करें जो सब कुछ सीमा में फिट नहीं होता है।
6. मध्यस्थों को पदों की आवृत्ति पर सीमा निर्धारित करने या विशिष्ट चर्चाओं में मौन की अवधि निर्धारित करने की अनुमति दें। कभी-कभी बाहर से ऐसा लगता है कि चर्चा बहुत गर्म है। संघर्ष के डी-एस्केलेशन के लिए, व्यक्तिगत प्रतिभागियों को प्रतिबंध लागू करने की तुलना में एक सामान्य सीमा स्थापित करना आसान है।
7. मॉडरेटर्स के साथ: एक अतिरिक्त क्रॉस-प्रोजेक्ट टीम बनाएं जो अन्य टीमों में लोड स्तरों को बजट और ऑडिट करने में शामिल है। यह प्रभावी हो सकता है: ऑडिट टीम लोगों को आवश्यक होने पर ना कहने में मदद करेगी, और सहन नहीं करेगी, जैसा कि अधिकांश टीम के सदस्य करते हैं, बहुत अधिक सहमत हैं।

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

नया साल मुबारक हो और शुभकामनाएँ!