मैं एक ओपन सोर्स प्रोजेक्ट में शामिल होने वाले एक कठिन प्रोग्रामर से कैसे निपटता हूं?

Question

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

सबसे पहले, उसने हमारी संस्करण प्रणाली को हटा दिया (जैसे गिट नहीं, लेकिन उस तरह - हमने इसे संस्करण v4.1.16कहा) और कहा कि कोड को साइट पर धकेलने के लिए बेहतर होगा जब हमें लगता है कि यह तैयार है। अब कोई नोट जारी करने के लिए कोई केंद्रीकृत जगह नहीं है, जो कष्टप्रद हो गई है।

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

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

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

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

Comments

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

— हिरण हंटर

आप प्रश्न के बिंदु को याद कर रहे हैं। एक नवागंतुक कैसे आपकी परियोजना में शामिल हो गया और पूरी तरह से लग रहा है? यह खुला स्रोत हो सकता है, लेकिन यह निहित है कि एक नेता या नेताओं का एक समूह है, और संभवतः यह कि / वे नेता केवल वही होंगे जो इस तरह के महत्वपूर्ण हिस्से को बदलने की क्षमता रखते हैं कि परियोजना कैसे संचालित होती है।

— 28:13

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

— ग्रैंडमास्टरबी

आप क्या करते हैं? आप TheDailyWTF पर पोस्ट करते हैं और सभी के साथ लिंक साझा करते हैं। आप उसे प्रस्तुत करने में शर्म करेंगे।

— रथ

ईमानदारी से, और यहां दांव पर अन्य मुद्दों की परवाह किए बिना, एक वेबसाइट के लिए सॉफ्टवेयर को आगे बढ़ाने के लिए एक चित्रमय जावा कार्यक्रम के साथ पायथन स्क्रिप्ट की जगह मेरे लिए पागल अतिरेक की तरह लग रहा है।

— सम होसेवर

Answer 1

1. आप छोड़ सकते हैं। सबसे रचनात्मक काम करने के लिए नहीं, लेकिन कभी-कभी यह एकमात्र विकल्प होता है। यदि आप ऐसा करते हैं, तो आस-पास न बैठें और इस बारे में विलाप करें कि आपको इसे कैसे देना है, उस ऊर्जा को लें और इसे सीधे किसी और चीज़ में डालें - दूसरे शब्दों में 'आगे बढ़ें'।

2. आप इसे कांटा कर सकते हैं। कोई कारण नहीं है कि आपको किसी के साथ काम करना पड़े। कांटा, कोड में सुधार और दूसरों को अपने स्वयं के थोड़ा अहंकार-उत्सव जारी रखने दें। आपकी नई परियोजना बस पुराने और इसके साथ प्रतिस्पर्धा करेगी कि आप इसे सफल बनाते हैं, या पुराना आपको उपयोगकर्ताओं और सुविधाओं के मामले में हराता है।

3. आप अपनी चिंताओं को सुनाने के लिए परियोजना के बाकी विकास दल के साथ जुड़ सकते हैं । इसे व्यक्तिगत न करें, लेकिन यह सुनिश्चित करें कि आप कोड मंथन से नाखुश हैं, या स्थापित गुणवत्ता प्रक्रियाओं की कमी है, या इस बात से नाखुश हैं कि नए फैसले बस सभी से समझौते के बिना बाहर कर दिए जाते हैं। आपको या तो बताया जाएगा कि कुछ भी गलत नहीं है, या आप कुछ अन्य लोगों से सहमत होंगे जिनसे टीम को चीजों को ठीक करने की आवश्यकता है। यह विघटनकारी आदमी को अपनी प्रतिबद्ध पहुंच खोने के कारण खत्म हो सकता है। शायद आप सभी इस बात से सहमत होंगे कि कुछ बदलावों में सुधार नहीं हुआ है और परियोजना को वापस लाने की आवश्यकता है। (यह बाद वाला विकल्प सबसे संभावित परिणाम है, जब तक कि यह बड़े पैमाने पर उलझे हुए विचारों के तर्क में न बदल जाए।)

यह मुश्किल हो सकता है जब कोई व्यक्ति साथ आता है और आपके द्वारा उपयोग की जाने वाली सुरक्षित और आरामदायक दिनचर्या को बदल देता है, लेकिन यह कहा जा सकता है कि किसी के साथ आने और पुरानी, ​​आरामदायक प्रथाओं को हिला देना अपने आप में अच्छी चीजें हैं।

Comments

मैं एक कांटा () प्रस्तावित करता हूँ;

— ott--

क्यों समाधान # 1 के रूप में कहा जा रहा है? यदि परियोजना वास्तव में रोमांचक है, तो क्या यह अंतिम विकल्प नहीं होना चाहिए?

— हिरण शिकारी

@DeerHunter: मैंने वरीयता क्रम के अनुसार संभावनाओं के क्रम को नहीं पढ़ा है, लेकिन पहले 1,2 सूचीबद्ध होना उपयोगी है क्योंकि ये संभावनाएँ 3. की ​​चर्चा को सूचित कर सकती हैं

— हार्डमैथ

विकल्प टाइप करने के लिए सबसे आसान के क्रम में सूचीबद्ध हैं।

— gbjbaanb

# 1 के साथ # 3 स्वैप करें, आपको पीछे धकेलना होगा क्योंकि एक अकेला-भेड़िया किसी भी चीज के लिए बिना किसी अच्छे प्रोजेक्ट को नष्ट कर सकता है।

— जोनाथन नेफेल्ड

Answer 2

आपने इसे थोड़ा स्पष्ट कर दिया है कि आपकी भूमिका क्या है। जवाब इस बात पर निर्भर करता है कि आप किस तरह से फिट होते हैं।

यदि आप परियोजना का नेतृत्व कर रहे हैं और गिट रिपॉजिटरी को नियंत्रित करते हैं

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

अगर रेपो को कोई और नियंत्रित करता है

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

Answer 3

कृपया मेरी कुंदता को क्षमा करें, लेकिन आपकी पोस्ट एक शेख़ी की तरह पढ़ती है।

आप कहते हैं कि यह दूसरा आदमी है जो नासमझ बदलाव चाहता है, लेकिन तब आप खुद को इस नए चमकदार जावा कार्यक्रम के बारे में बात करते हुए विरोधाभास करते हैं।

एक ब्रेक ले लो; यह एक-तरफ़ा सड़क नहीं है, कृपया समझौता खोजने की कोशिश करें (यदि आप परियोजना पर काम जारी रखना चाहते हैं - फोर्किंग सबसे आसान निर्णय है, लेकिन यह आपको कहीं भी उपयोगी नहीं बनाएगा, हालांकि यह आपके अहंकार को आघात कर सकता है)।

कृपया परियोजना में श्रम के विभाजन के बारे में अच्छी तरह से सोचें - यदि आपके पास कौन क्या है, यह बताने में स्वच्छ सीमाएं अपरिहार्य नहीं हैं । हां, आपको कभी-कभी दूसरे लोगों के फैसले पर भरोसा करना होगा।

Comments

@ नथान 2055 - सरल और काम करना बेहतर है, मेरी पुस्तक में (शायद यह सिर्फ मेरे लिए है)। वैसे भी, ऐसा लगता है कि परियोजना बहुत अधिक मार्गदर्शन के बिना उत्थान है।

— हिरण हंटर

मैं एड्रिफ्ट पार्ट से सहमत हूं। जिन चीजों का मैं उल्लेख करना भूल गया, उनमें से एक यह है कि एक ही डेवलपर ने बिना किसी को बताए परियोजना को बेतरतीब ढंग से लागू कर दिया।

— नाथन 2055

कैसे, वास्तव में, एक नए डेवलपर ने एकतरफा रूप से कोड के मौजूदा निकाय पर लाइसेंस को बदल दिया, जिसके पास एकमात्र कॉपीराइट नियंत्रण नहीं है? उसे ऐसी पहुँच / अधिकार कैसे प्राप्त हुआ और इसे क्यों नहीं हटाया गया?

— कुटुलुमाइक

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

— नोरक्रॉस

@ Nathan2055 प्राधिकरण के बिना किसी परियोजना के लाइसेंस को बदलना शायद तत्काल खारिज करने के लिए आधार है, यहां तक ​​कि खुले स्रोत परियोजनाओं में भी। सिर्फ इसलिए कि यह खुला स्रोत है इसका मतलब यह नहीं है कि कुछ यादृच्छिक दोस्त बस में चल सकते हैं और नियंत्रण मान सकते हैं। कोई फर्क नहीं पड़ता कि उनके प्रोग्रामिंग कौशल कितने महाकाव्य हैं, अगर वह ऐसी टीम में काम नहीं कर सकता है जिसे आप उसे नहीं चाहते हैं और आपको उसके साथ बात करने और / या उसे बाहर निकालने की आवश्यकता है। जब तक आप हमें सब कुछ नहीं बता रहे हैं ..

— थॉमस

Answer 4

यह पहले से ही कई जवाबों में वर्णित है कि श्रम का विभाजन संघर्ष को कम करने का एक तरीका है। यहाँ कुछ ठोस उदाहरण दिए गए हैं:

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

---

संघर्ष-परिहार पहलू के अलावा, यह स्पष्ट है कि परियोजना में अपर्याप्त शासन हो सकता है ।

शासन महत्वपूर्ण क्यों है? एक दिन कल्पना कीजिए कि एक पूर्व टीममेट ने सॉफ्टवेयर का एक टुकड़ा लिया, और उल्लंघन के लिए टीम पर मुकदमा दायर किया। या टीम ने पेटेंट ट्रोल द्वारा मुकदमा दायर किया। या कोई नहीं जानता है, जिसने प्रोजेक्ट होस्टिंग साइट पर DMCA नोटिस भेजने का फैसला किया है और परियोजना के स्रोत कोड को मिटाने की मांग की है।

न्यूनतम पर:

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

अधिकांश ओपन-सोर्स प्रोजेक्ट साइटें तैयार-किए गए प्रोजेक्ट गवर्नेंस चार्टर्स प्रदान कर सकती हैं।

Comments

शासन के लिए +1। जितनी जल्दी या बाद में सभी ओपन सोर्स प्रोजेक्ट्स को कुछ लिखित नियमों के साथ-साथ कुछ कोड की आवश्यकता होती है, चाहे वह बड़ी परियोजनाओं के लिए पूर्ण-विकसित शासन हो, या जो भी फ़ोरम, मेलिंग सूचियों के लिए एक साधारण कोड ऑफ़ कंडक्ट (जैसे wiki.gnome.org/CodeOfConduct ) हो। , बग डेटाबेस या SCCS आप सभी साझा करें।

— calum_b

Answer 5

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

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

सामान्य लक्ष्य आपके प्रयासों को महत्वपूर्ण सामान पर केंद्रित करेगा। एक ही दिशा में काम करने वाले सभी को प्राप्त करना मुश्किल है, और संघर्ष वैसे भी होगा। सामान्य लक्ष्य तय करने के लिए यह जानना आवश्यक है कि परियोजना की वर्तमान स्थिति क्या है, और फिर यह तय करना कि उसे कुछ समय बाद कहाँ होना है।

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

Comments

श्रम विभाजन पर एक अच्छा बिंदु।

— हिरण हंटर

कभी नहीं देखें कि अन्य प्रोग्रामरों ने क्या फैसला किया, बस उन पर भरोसा करें? मेरे लिए खतरनाक लगता है। गुणवत्ता नियंत्रण के बारे में क्या?

— Stephan

Answer 6

चार विकल्प, मुझे लगता है।

1. धक्के मार कर बाहर निकालें। आप (कथित तौर पर) अभी भी इस परियोजना पर मुख्य दोस्त हैं; अपने पुश विशेषाधिकारों को रद्द करें और इसे एक दिन कहें। सबसे संभावित परिणाम उसके प्रोजेक्ट को कांटा लगाने, उसके समुदाय को विभाजित करने, और फिर एक युद्ध ढीला हो जाता है, और जब धूल बैठ जाती है, तो कांटा में से एक लोकप्रिय होगा।
2. इसे कांटा और कहीं और जारी रखें। 1. से कम आक्रामक, लेकिन परिणाम अन्यथा समान हैं। आपको समुदाय में सक्रिय रहना होगा, हालांकि लोगों को अपनी ओर खींचने के लिए।
3. इसे छोड़ दो: बस उसे वही करने दो जो वह कर रहा है, शांत हो जाओ, और सर्वश्रेष्ठ की आशा करो।
4. समुदाय के साथ चर्चा करें, आवश्यकतानुसार समझौता करें और स्थिति को हल करें।

व्यक्तिगत रूप से, मैं विकल्प 4 पसंद करूंगा।

Answer 7

Google ने कुछ साल पहले इस बारे में कुछ तकनीकी बातचीत की थी। उन्हे देखे:1 ,२ । संक्षेप में:

1. समझ : अपने समुदाय की प्रेरणा समझे अपनी परियोजना बनाम अन्य सभी अवसर लागत पर काम करने के लिए, और उन कारणों की रक्षा।
2. किलेबंदी : राजनीति, सम्मान, विश्वास और विनम्रता के सामाजिक मानदंडों के साथ एक स्वस्थ समुदाय का निर्माण।
3. पहचानें : जहरीले लोगों के संकेत-कहानी के संकेतों को देखें (सूची में बहुत सारे, लेकिन यदि आप यह सवाल पूछ रहे हैं तो आप शायद उनमें से कई को पहले से ही जानते हैं)।
4. निस्संकोच : शांत रहें और अपनी जमीन पर खड़े रहें, अपमान, शूरवीर, चुनौती, अनादर, आदि के प्रति अप्रसिद्ध रहें और अपने सामुदायिक मानदंडों को सुदृढ़ करने में निरंतर रहें।

यदि आप घड़ी के बजाय पढ़ना पसंद करते हैं तो एक व्यापक लिखित रूपरेखा भी उपलब्ध है।

Comments

क्या आप इस बात पर थोड़ा विस्तार करेंगे कि इनमें से प्रत्येक संसाधन में क्या है और आप पूछे गए प्रश्न का उत्तर देने के लिए इनकी सिफारिश क्यों करते हैं? स्टैक एक्सचेंज में "लिंक-ओनली जवाब" का बहुत स्वागत नहीं है

— gnat

जोड़ा गया सारांश, कैसा है?

— कुर्टोसिस

Answer 8

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

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

फिर से, यह ईमेल भेजना कठिन है लेकिन यह अपने आप में एक शानदार अनुभव है जो आपके लिए बहुत उपयोगी हो सकता है। महान सबक सीखने के लिए।

पुनश्च: मैं बहुत पैतृक ध्वनि का मतलब नहीं था। हालाँकि यह वास्तव में कुछ है जो मैं अपने बच्चों सहित किसी से भी कहूंगा।

Comments

"आप बस नहीं छोड़ सकते" ... हाँ आप कर सकते हैं । यह हल्के ढंग से बनाने का विकल्प नहीं है क्योंकि इसका मतलब है कि यदि आप करते हैं तो आप टीम पर हर किसी के साथ हर पुल को जला देंगे, लेकिन अगर स्थिति काफी खराब है (भावनात्मक संकट पैदा करने की बात), तो हमेशा दूर चलना एक विकल्प है ।

— शादुर