पुल के जूनियर्स को प्रशिक्षण के लिए जगह देने का अनुरोध कर रहे हैं


11

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

यहाँ विचार यह है कि एक बार जब आप PR बनाते हैं, तो आप कह रहे हैं कि आपने इसे मास्टर में रखा होगा, लेकिन कुछ समीक्षक चाहेंगे कि आपके साथ बस 'कॉनक्योर' करें और कुछ भी ऐसा करें जिसे आप मिस करें।

जैसा कि हम केवल मानव हैं, हम गलतियाँ करते हैं और आशा करते हैं कि अन्य समीक्षकों को वे आइटम मिल सकते हैं जो यूनिट परीक्षण नहीं पा सकते थे - वर्तनी की गलतियाँ, गलत जावास्क्रिप्ट आदि।

लेकिन, क्या वह जगह है जहां हम डेवलपर्स को कुछ स्तर पर सहायता / प्रशिक्षण प्रदान कर रहे हैं और यदि हां, तो किस स्तर पर अनुरोध करना चाहिए?

हर बार जब आप नए बदलावों को आगे बढ़ाते हैं, तो समीक्षकों को आपके परिवर्तनों की समीक्षा करनी होती है, जो उनके विकास के समय से होती है और परिवर्तनों की समीक्षा करने का कारण बनती है।

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

क्या कोई और "विकास के लिए तैयार होने के लिए मेरे अनुरोध को प्राप्त करने के लिए" प्राप्त करने की कोशिश कर रहा है?

जवाबों:


13

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

यहाँ एक चरम विचार है (दंडित इरादा)। जोड़ी कार्यक्रम के साथ प्रशिक्षु जो आपको नाराज़गी दे रहा है। एक अधिक वरिष्ठ टीम के सदस्य के रूप में, उन्हें उठाना और उन्हें उत्पादक तक पहुंचाना आपका काम है।


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

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

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

1
हम्म ... यह इतना आसान क्यों नहीं है? क्या ग्राहक को केवल कई आदमी घंटे नहीं मिलते हैं, और इससे भी महत्वपूर्ण बात यह है कि उनके डॉलर के लिए बेहतर मूल्य है? बेस्ट ऑफ लक मेट। बच्चे पर इसे आसानी से लें।
रबरडुक

3
यह एक आम गलत धारणा है @Andy। हालांकि यह सच नहीं है। हां, यह सहज है, मुझे पता है।
रबरडुक

9

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

लेकिन क्या यह सबसे अच्छी जगह है? यहाँ कुछ कारण है कि मैं क्यों नहीं कहूंगा:

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

जोड़ी प्रोग्रामिंग और डिजाइन समीक्षा बड़े पैमाने पर प्रतिक्रिया के लिए बेहतर स्थान हैं।

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

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


5

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

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

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


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

2

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

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

तो, इस सवाल के बारे में कि क्या पुल अनुरोध प्रशिक्षण जूनियर्स के लिए जगह हैं, मुझे यह कहना होगा कि इन के दौरान उठने योग्य क्षणों के लिए यह असामान्य नहीं है। अरे, आप अपने पहले मर्ज संघर्ष से निपटने जा रहे हैं, चलो समीक्षा के बाद उस पर जाएं। अरे देखो, आपने अपने DAO के लिए कोई इकाई परीक्षण शामिल नहीं किया, जब तक हम उन नए तरीकों को कवर करने का मौका नहीं लेते, हम आपकी समीक्षा को स्थगित कर देंगे। आपको क्यों लगा कि इस वित्तीय गणना में BigDecimals की तुलना में दोहरे प्राइमेटिव का उपयोग करना बेहतर होगा? हाँ, यह वास्तव में असामान्य नहीं है।

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

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

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

उस सब के बाद कोड बंद है। लेकिन तब हमने क्यूए को इसे यातना देने दिया।


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

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

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

2

मैं सभी को उनके योगदान के लिए धन्यवाद देना चाहता हूं और मुझे यह समझने में मदद करता हूं कि इस विषय पर लोगों का क्या कहना है।

यह मेरा जवाब दिया गया फीडबैक और अब प्राप्त उत्तरों और टिप्पणियों के आधार पर मेरी समझ है। सभी को धन्यवाद।

सारांश

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

1
अद्भुत सारांश और उत्तर। यदि आप खुद को चेक मार्क देते हैं तो मैं बिल्कुल भी नाराज नहीं होऊंगा।
रबरडक

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

0

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

यदि आपके पास एक जूनियर डेवलपर है, तो उनके पहले कुछ अनुरोधों में स्पष्ट रूप से समस्याएं होंगी। आखिरकार उन्हें इसके लिए फांसी मिलनी चाहिए। यदि आप पा रहे हैं कि उनके पास समस्याएँ हैं, तो आप उन्हें काम सौंप सकते हैं जो वे अभी तक तैयार नहीं हैं?

या हो सकता है कि आपको एक प्रतिस्थापन कनिष्ठ को नियुक्त करने की आवश्यकता है और उस एक को हटा दें जो कि यह पता लगाने में सक्षम नहीं है?

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

तो आपको खुद तय करना होगा: आपके जूनियर्स को कम्पीटीशन दिखाने के लिए कितने पुल रिक्वेस्ट लेने होंगे, और क्या आपमें हिम्मत है कि जो नहीं करते हैं उन्हें जाने दें?


@RibaldEddie का जवाब देने के लिए धन्यवाद, हम उम्मीद करते हैं कि डेवलपर्स ने यूनिट परीक्षण लिखा होगा, मैन्युअल रूप से परीक्षण किया है और इस बिंदु पर अपने स्वयं के काम की समीक्षा की है, जहां वे दावा करेंगे कि यह कोड महान है और क्या यह उनके लिए छोड़ दिया गया था जो वे इसे मास्टर में विलय कर देंगे, जवाब लेकिन इसकी समीक्षा करने के लिए 2 समीक्षक मिलेंगे और उम्मीद है कि इस कथन की पुष्टि करेंगे। हम किसी भी तकनीकी ऋण को स्वीकार नहीं करते हैं और समाधान के पक्ष में सुधार से पूरी तरह से दूर हो रहे हैं। तो उम्मीद यह है कि कोड उन आवश्यकताओं को पूरा करता है।
२१:३२ पर रयान स्कुट

@ रियान कौन समीक्षक हैं?
रिबॉल्डएड्डी

तकनीकी से कोई भी जूनियर की ओर जाता है। आम तौर पर यह एक वरिष्ठ / मध्यवर्ती समीक्षक के साथ-साथ एक जूनियर / मध्यवर्ती समीक्षक होता है। (2 समीक्षक)
रयान शुट्टे

@Riaan समय के साथ मैं टीम के जूनियर सदस्यों से खुद को अलग करने की उम्मीद करूंगा। आप बता पाएंगे कि कौन संजीदा है और कौन अभावग्रस्त है। मुझे लगता है कि सॉफ्टवेयर विकास अच्छी तरह से किया गया एक गतिविधि है जो एक विस्तार-उन्मुख मानसिकता के अनुकूल है। हो सकता है कि कुछ लोग इसे खींच न सकें। आपको यह तय करना होगा कि उनके साथ क्या करना है। लेकिन मूल रूप से आपको ऐसे डेवलपर्स से उम्मीद करनी चाहिए जो मर्ज किए जाने वाले कोड जमा करते हैं, उन्हें विश्वास है कि यह उद्देश्य के अनुसार काम करता है और उत्पादन के लिए तैयार है। यहां तक ​​कि अगर आपके पास एक बड़ी, परिष्कृत क्यूए टीम है, तो आपके देवताओं को अभी भी उत्पादन-तैयार कोड होना चाहिए।
रिबेल्डेदी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.