first-contributions/docs/additional-material/translations/Tamil/Things a non Programmer can do.ta.md

புரோகிராமர் அல்லாதவர் செய்யக்கூடிய விஷயங்கள்

கேட்கத் தொடங்குங்கள்

திறந்த மூலத்தில் உள்ள அனைத்தும் மற்றவர்களை உள்ளடக்கியது. நீங்கள் ஒரு குழுவில் சேர விரும்புகிறீர்கள், அதாவது சமூகத்தையும் அது எவ்வாறு செயல்படுகிறது என்பதையும் புரிந்துகொள்வது. ஒரு ப்ராஜெக்ட்டில் நுழைந்து, "ஹாய், இதோ இந்த ப்ராஜெக்ட் செய்ய வேண்டும் என்று நான் நினைக்கிறேன்" என்று சொல்வது பொதுவாக நல்ல விஷயமாக எடுத்துக்கொள்ளப்படுவதில்லை. சில திட்டங்கள் அந்த வகையான அணுகுமுறையை வரவேற்கலாம், ஆனால் திட்டம் சிறிது நேரம் இயங்கிக்கொண்டிருந்தால், அந்த அணுகுமுறை ஏற்றுக்கொள்ளப்படுவதற்கான வாய்ப்புகள் சிறியவை. திட்டத்திற்கு என்ன தேவை என்பதை அறிய சிறந்த வழி கேட்பது.

1. அஞ்சல் பட்டியலில் சேரவும்: பல திட்டங்களுக்கு, திட்டத்தின் மேம்பாடு பற்றிய தகவல் பரிமாற்றத்தின் முக்கிய வழித்தடமாக அஞ்சல் பட்டியல் உள்ளது. பெரிய திட்டங்களில், தேர்வு செய்ய பல அஞ்சல் பட்டியல்கள் உள்ளன. எடுத்துக்காட்டாக, PostgreSQL திட்டமானது அதன் அஞ்சல் பட்டியல் பக்கத்தில் 12 பயனர் சார்ந்த பட்டியல்களையும் ஆறு டெவலப்பர் பட்டியல்களையும் கொண்டிருக்கவில்லை. முக்கிய பயனர் சார்ந்த பட்டியலையும், கேட்கத் தொடங்கும் முக்கிய டெவலப்பர் பட்டியலையும் நீங்கள் பின்பற்ற பரிந்துரைக்கிறேன்.

2. ஒரு வலைப்பதிவைப் பின்தொடரவும்: முக்கிய டெவலப்பர்களால் பராமரிக்கப்படும் வலைப்பதிவுகள் எதிர்கால வெளியீடுகளில் என்ன வரப்போகிறது என்பது பற்றிய தகவல்களை அடிக்கடி தருகிறது, மற்றும் அங்கு செல்ல என்ன எடுக்கப்பட்டது. திட்டத்துடன் தொடர்புடைய பல மூலங்களிலிருந்து செய்திகள் மற்றும் வலைப்பதிவு உள்ளீடுகளை ஒரு கிரக தளம் ஒருங்கிணைக்கிறது. planet.gnome.org அல்லது planet.mysql.com போன்ற கிரக தளம் இருந்தால், அங்கேயே தொடங்கவும். "planet " என்று கூகுளில் தேடினால் போதும்.

3. IRC சேனலில் சேரவும்: பல ஓப்பன் சோர்ஸ் திட்டங்களில் டெவலப்பர்கள் மற்றும் பயனர்கள் பிரச்சனைகள் மற்றும் மேம்பாடுகளைப் பற்றி விவாதிக்க பிரத்யேக இணைய ரிலே அரட்டை (IRC) சேனல்கள் உள்ளன. சேனல் என்ன அழைக்கப்படுகிறது மற்றும் எந்த IRC நெட்வொர்க்கில் உள்ளது என்ற விவரங்களுக்கு திட்டத்தின் இணையதளத்தைப் பார்க்கவும்.

டிக்கெட்டுகளுடன் வேலை செய்யுங்கள் எந்தவொரு திறந்த மூல திட்டத்திற்கும் குறியீடு தான் இதயம், ஆனால் குறியீட்டை எழுதுவது மட்டுமே பங்களிப்பதற்கான ஒரே வழி என்று நினைக்க வேண்டாம். புதிய அம்சங்களை உருவாக்குவதற்கும் பிழைகளை சரிசெய்வதற்குமான அவசரத்தில் குறியீட்டின் பராமரிப்பு மற்றும் குறியீட்டைச் சுற்றியுள்ள அமைப்புகள் பெரும்பாலும் புறக்கணிக்கப்படுகின்றன. ஒரு திட்டத்தில் உங்கள் பாதத்தைப் பெறுவதற்கான எளிதான வழியாக இந்தப் பகுதிகளைப் பாருங்கள். பெரும்பாலான ப்ராஜெக்ட்கள் பொதுவில் காணக்கூடிய பிரச்சனை டிக்கெட் அமைப்பைக் கொண்டுள்ளன, இது திட்டத்தின் இணையதளத்தின் முதல் பக்கத்திலிருந்து இணைக்கப்பட்டு ஆவணத்தில் சேர்க்கப்பட்டுள்ளது. இது பயனர்களுக்கும் டெவலப்பர்களுக்கும் இடையிலான தொடர்புக்கான முதன்மையான வழியாகும். அதை தற்போதைய நிலையில் வைத்திருப்பது திட்டத்திற்கு உதவ ஒரு சிறந்த வழியாகும். டிக்கெட் அமைப்பில் நீங்கள் சிறப்பு அனுமதிகளைப் பெற வேண்டியிருக்கலாம், பெரும்பாலான திட்டத் தலைவர்கள் டிக்கெட்டுகளை சுத்தம் செய்ய நீங்கள் உதவ விரும்புகிறீர்கள் என்று நீங்கள் கூறும்போது மகிழ்ச்சியுடன் வழங்குவார்கள்.

4. பிழையைக் கண்டறிதல்: பிழைகள் பெரும்பாலும் மோசமாகப் புகாரளிக்கப்படுகின்றன. பிழையைக் கண்டறிதல் மற்றும் சோதனை செய்வது, பிரச்சனையின் பிரத்தியேகங்களைக் கண்டறிவதன் மூலம் டெவலப்பர்களின் நேரத்தைச் சேமிக்க உதவும். ஒரு பயனர், "நான் X செய்யும் போது மென்பொருள் வேலை செய்யாது" எனப் புகாரளித்தால், அந்தச் சிக்கலில் என்ன நடக்கிறது என்பதைத் தெரிந்துகொள்ள சிறிது நேரம் செலவிடுங்கள். இது மீண்டும் மீண்டும் செய்யக்கூடியதா? மீண்டும் மீண்டும் சிக்கலை ஏற்படுத்துவதற்கான படிகளின் தொகுப்பை உருவாக்க முடியுமா? ஒரு உலாவியில் மட்டும் நடப்பது மற்றொன்று அல்ல, அல்லது ஒரு டிஸ்ட்ரோ ஆனால் மற்றொன்றில் நடக்காதது போன்ற சிக்கலைக் குறைக்க முடியுமா?

பிரச்சனைக்கு என்ன காரணம் என்று உங்களுக்குத் தெரியாவிட்டாலும், சூழ்நிலைகளைக் குறைப்பதில் நீங்கள் எடுக்கும் முயற்சி, அதைச் சரிசெய்வதை மற்றொருவருக்கு எளிதாக்குகிறது. நீங்கள் எதைக் கண்டறிந்தாலும், அதை அனைவரும் பார்க்க, பிழை அமைப்பில் உள்ள டிக்கெட்டில் சேர்க்கவும்.

5. நிலையான பிழைகளை மூடு: பெரும்பாலும் பிழைகள் கோட்பேஸில் சரி செய்யப்படும் ஆனால் அவற்றைப் பற்றி அறிவிக்கப்படும் டிக்கெட்டுகள் டிக்கெட் அமைப்பில் புதுப்பிக்கப்படுவதில்லை. இந்த க்ராஃப்ட்டை சுத்தம் செய்வது நேரத்தை எடுத்துக்கொள்ளும், ஆனால் இது முழு திட்டத்திற்கும் மதிப்புமிக்கது.

ஒரு வருடத்திற்கும் மேலான டிக்கெட்டுகளுக்கான டிக்கெட் முறையை வினவுவதன் மூலம் தொடங்கி, பிழை இன்னும் இருக்கிறதா என்று பார்க்கவும். பிழை சரி செய்யப்பட்டதா மற்றும் மூட முடியுமா என்பதைப் பார்க்க, திட்டத்தின் வெளியீட்டு மாற்றப் பதிவைச் சரிபார்க்கவும். அது சரி செய்யப்பட்டது எனத் தெரிந்தால், டிக்கெட்டில் உள்ள பதிப்பு எண்ணைக் குறிப்பிட்டு அதை மூடவும்.

மென்பொருளின் சமீபத்திய பதிப்பைக் கொண்டு பிழையை மீண்டும் உருவாக்க முயற்சிக்கவும். சமீபத்திய பதிப்பில் அதை மீண்டும் உருவாக்க முடியாவிட்டால், டிக்கெட்டில் அதைக் கவனித்து அதை மூடவும். அது இன்னும் இருந்தால், டிக்கெட்டிலும் அதைக் கவனித்து அதைத் திறந்து விடுங்கள்.

குறியீட்டுடன் பணிபுரிதல் அனைத்து அனுபவ நிலைகளிலும் உள்ள புரோகிராமர்கள் திட்டத்தில் உள்ள குறியீட்டிற்கு உதவலாம். உங்களுக்குப் பிடித்த திட்டத்திற்கு உண்மையான பங்களிப்பைச் செய்ய நீங்கள் ஒரு குறியீட்டு மேதையாக இருக்க வேண்டும் என்று நினைக்க வேண்டாம்.

உங்கள் பணியானது குறியீட்டை மாற்றியமைப்பதை உள்ளடக்கியிருந்தால், பங்களிப்பாளர்களிடமிருந்து குறியீட்டைப் பெற திட்டம் பயன்படுத்தும் முறையை ஆராயுங்கள். ஒவ்வொரு திட்டத்திற்கும் அதன் சொந்த பணிப்பாய்வு உள்ளது, எனவே குறியீட்டை சமர்ப்பிக்கும் முன் அதை எப்படி செய்வது என்று கேளுங்கள்.

எடுத்துக்காட்டாக, PostgreSQL திட்டம் அதன் செயல்பாட்டில் மிகவும் கடுமையானது: குறியீடு மாற்றங்கள் இணைப்புப் பட்டியலில் அஞ்சல் பட்டியலில் அனுப்பப்படுகின்றன, அங்கு முக்கிய டெவலப்பர்கள் மாற்றத்தின் ஒவ்வொரு அம்சத்தையும் ஆய்வு செய்கிறார்கள். மறுமுனையில் கிளி போன்ற ஒரு திட்டம் உள்ளது, அங்கு கோட்பேஸுக்கு உறுதி சலுகைகளைப் பெறுவது எளிது. திட்டம் GitHub ஐப் பயன்படுத்தினால், GitHub இன் இழுக்கும் கோரிக்கை அம்சத்தைப் பயன்படுத்தும் பணிப்பாய்வு இருக்கலாம். இரண்டு திட்டங்களும் ஒரே மாதிரியானவை அல்ல.

நீங்கள் குறியீட்டை மாற்றும் போதெல்லாம், சமூகத்தின் பொறுப்பான உறுப்பினராகச் செயல்படுவதை உறுதிசெய்து, மீதமுள்ள குறியீட்டுத் தளத்துடன் பொருந்துமாறு உங்கள் குறியீட்டு பாணியை வைத்திருக்கவும். நீங்கள் சேர்க்கும் அல்லது மாற்றியமைக்கும் குறியீடு மற்றதைப் போலவே இருக்க வேண்டும். பிரேசிங் ஸ்டைல் ​​அல்லது உள்தள்ளலுக்கான இடைவெளிகளைக் கையாள்வது உங்களுக்குப் பிடிக்காமல் இருக்கலாம், ஆனால் தற்போதுள்ள தரநிலைகளுடன் பொருந்தாத குறியீட்டு மாற்றத்தைச் சமர்ப்பிப்பது முரட்டுத்தனமானது. "உங்கள் பாணி எனக்குப் பிடிக்கவில்லை, என்னுடையது சிறந்தது என்று நான் நினைக்கிறேன், எனவே நீங்கள் அதை என் வழியில் செய்ய வேண்டும்" என்று சொல்வதும் ஒன்றுதான்.

6. பீட்டாவைச் சோதிக்கவும் அல்லது வேட்பாளரை வெளியிடவும்: பல தளங்களில் இயங்கும் வகையில் வடிவமைக்கப்பட்ட எந்தத் திட்டமும் எல்லா வகையான பெயர்வுத்திறன் சிக்கல்களையும் கொண்டிருக்கலாம். ஒரு வெளியீடு நெருங்கி, பீட்டா அல்லது வெளியீட்டு வேட்பாளர் வெளியிடப்படும் போது, ​​அது பல்வேறு தளங்களில் பல்வேறு நபர்களால் சோதிக்கப்படும் என்று திட்டத் தலைவர் நம்புகிறார். நீங்கள் அந்த நபர்களில் ஒருவராக இருக்கலாம் மற்றும் உங்கள் பிளாட்ஃபார்மில் தொகுப்பு செயல்படுவதை உறுதிசெய்ய உதவலாம்.

பொதுவாக நீங்கள் மென்பொருளைப் பதிவிறக்கம் செய்து, உருவாக்கி, சோதித்துப் பார்க்க வேண்டும், ஆனால் நீங்கள் அசாதாரணமான விநியோகம் அல்லது வன்பொருளில் இருந்தால் திட்டத்திற்கான மதிப்பு மிகப்பெரியதாக இருக்கும். உருவாக்கம் மற்றும் சோதனை வேலைகள் என்று அறிக்கையிடுவது, வரவிருக்கும் வெளியீடு உறுதியானது என்பதை திட்டத் தலைவர்கள் அறிய உதவுகிறது.

7. பிழையை சரிசெய்தல்: பொதுவாக, பங்களிப்பாளர்கள் குறியீட்டில் வேலை செய்ய விரும்பும் இடமாகும். இது எளிதானது: டிக்கெட் அமைப்பில் ஒரு சுவாரஸ்யமான-ஒலி பிழையைக் கண்டறிந்து குறியீட்டில் அதை சரிசெய்ய முயற்சிக்கவும். திருத்தம் பொருத்தமானதாக இருந்தால் குறியீட்டில் ஆவணப்படுத்தவும். நீங்கள் சரிசெய்த குறியீட்டின் இடத்தைச் சோதிக்க, சோதனைத் தொகுப்பில் ஒரு சோதனையைச் சேர்ப்பது நல்லது; சோதனைகளைச் சேர்க்க சில திட்டங்களுக்கு பிழை திருத்தங்கள் தேவை. இந்த அறிமுகமில்லாத கோட்பேஸை சுற்றிக் கொண்டே குறிப்புகளை வைத்துக் கொள்ளுங்கள். பிழையை உங்களால் சரிசெய்ய முடியாவிட்டாலும், திருத்த முயற்சியின் ஒரு பகுதியாக நீங்கள் கண்டறிந்ததை டிக்கெட்டில் பதிவு செய்யவும். நீங்கள் கண்டுபிடிப்பது உங்களுக்குப் பின் வருபவர்களுக்கு உதவும்.

8. சோதனை எழுது: பெரும்பாலான திட்டங்களில் குறியீட்டைச் சோதிக்கும் ஒரு சோதனைத் தொகுப்பு உள்ளது, ஆனால் கூடுதல் சோதனைகளைச் சேர்க்க முடியாத ஒரு சோதனைத் தொகுப்பைக் கற்பனை செய்வது கடினம். சோதனைத் தொகுப்பால் சோதிக்கப்படாத மூலக் குறியீட்டில் உள்ள பகுதிகளைக் கண்டறிய, Gcov for C அல்லது Devel::Cover for Perl போன்ற சோதனைக் கவரேஜ் கருவியைப் பயன்படுத்தவும். பின்னர், அதை மறைக்க ஒரு சோதனையை தொகுப்பில் சேர்க்கவும்.

9. ஒரு கம்பைலர் எச்சரிக்கையை அமைதிப்படுத்து: பல சி-அடிப்படையிலான திட்டங்களுக்கான உருவாக்க செயல்முறை பெரும்பாலும் ஒற்றைப்படை கம்பைலர் எச்சரிக்கைக் கொடியை திரையில் செலுத்துகிறது. இந்த எச்சரிக்கைகள் பொதுவாக ஒரு சிக்கலின் குறிகாட்டிகள் அல்ல, ஆனால் அவை அப்படியே இருக்கும். பல எச்சரிக்கைகள் இருப்பதால், கம்பைலர் ஓநாய் அழுவது போல் ஒலிக்கும். குறியீடு உண்மையில் பிழையை மறைக்கிறதா என்பதைப் பார்க்கவும். இல்லையெனில், மூலத்தை அமைதிக்கு மாற்றுவது இந்த தவறான நேர்மறைகளை மறைக்க உதவுகிறது.

10. ஒரு கருத்தைச் சேர்: நீங்கள் குறியீட்டைத் தோண்டி எடுக்கும்போது, ​​குழப்பமான சில இடங்களைக் காணலாம். நீங்கள் குழப்பமடைந்திருந்தால், மற்றவர்களும் அவ்வாறு இருப்பதற்கான வாய்ப்புகள் உள்ளன. குறியீட்டில் அவற்றை ஆவணப்படுத்தி ஒரு பேட்சைச் சமர்ப்பிக்கவும். ஆவணங்களுடன் வேலை செய்யுங்கள் ஆவணப்படுத்தல் என்பது ஒரு திட்டத்தின் ஒரு பகுதியாகும், இது குறுகிய மாற்றத்தைப் பெறுகிறது. யாரோ ஒருவரின் பார்வையில் நுழைவதை விட, திட்டத்துடன் நன்கு தெரிந்தவர்களின் பார்வையில் எழுதப்பட்டதால் இது பாதிக்கப்படலாம். நீங்கள் எப்போதாவது ஒரு ப்ராஜெக்ட்டுக்கான டாக்ஸைப் படித்திருந்தால், "இந்த கையேடு எனக்கு ஏற்கனவே பேக்கேஜை எப்படி பயன்படுத்துவது என்று தெரியும் என்று எதிர்பார்க்கிறது போல் இருக்கிறது", நான் எதைப் பற்றி பேசுகிறேன் என்று உங்களுக்குத் தெரியும். பெரும்பாலும் புதிய கண்களின் தொகுப்பு, திட்டத்திற்கு நெருக்கமானவர்கள் கவனிக்காத ஆவணங்களில் உள்ள குறைபாடுகளை சுட்டிக்காட்டலாம்.

11. உதாரணத்தை உருவாக்கவும்: பல எப்படி-எப்படி-எடுத்துக்கொள்ளும் உதாரணங்களைக் கொண்ட எந்த திட்டமும் இல்லை. இது ஒரு வலை API ஆக இருந்தாலும், நடைமுறைகளின் நூலகமாக இருந்தாலும், Gimp அல்லது கமன் போன்ற GUI ஆப்ஸாக இருந்தாலும் சரி, ஆனால் தற்போதுள்ள தரநிலைகளுடன் பொருந்தாத குறியீட்டு மாற்றத்தைச் சமர்ப்பிப்பது முரட்டுத்தனமானது. "உங்கள் பாணி எனக்குப் பிடிக்கவில்லை, என்னுடையது சிறந்தது என்று நான் நினைக்கிறேன், எனவே நீங்கள் அதை என் வழியில் செய்ய வேண்டும்" என்று சொல்வதும் ஒன்றுதான்.

12. பீட்டாவைச் சோதிக்கவும் அல்லது வேட்பாளரை வெளியிடவும்: பல தளங்களில் இயங்கும் வகையில் வடிவமைக்கப்பட்ட எந்தத் திட்டமும் எல்லா வகையான பெயர்வுத்திறன் சிக்கல்களையும் கொண்டிருக்கலாம். ஒரு வெளியீடு நெருங்கி, பீட்டா அல்லது வெளியீட்டு வேட்பாளர் வெளியிடப்படும் போது, ​​அது பல்வேறு தளங்களில் பல்வேறு நபர்களால் சோதிக்கப்படும் என்று திட்டத் தலைவர் நம்புகிறார். நீங்கள் அந்த நபர்களில் ஒருவராக இருக்கலாம் மற்றும் உங்கள் பிளாட்ஃபார்மில் தொகுப்பு செயல்படுவதை உறுதிசெய்ய உதவலாம்.

பொதுவாக நீங்கள் மென்பொருளைப் பதிவிறக்கம் செய்து, உருவாக்கி, சோதித்துப் பார்க்க வேண்டும், ஆனால் நீங்கள் அசாதாரணமான விநியோகம் அல்லது வன்பொருளில் இருந்தால் திட்டத்திற்கான மதிப்பு மிகப்பெரியதாக இருக்கும். உருவாக்கம் மற்றும் சோதனை வேலைகள் என்று அறிக்கையிடுவது, வரவிருக்கும் வெளியீடு உறுதியானது என்பதை திட்டத் தலைவர்கள் அறிய உதவுகிறது.

7. பிழையை சரிசெய்தல்: பொதுவாக, பங்களிப்பாளர்கள் குறியீட்டில் வேலை செய்ய விரும்பும் இடமாகும். இது எளிதானது: டிக்கெட் அமைப்பில் ஒரு சுவாரஸ்யமான-ஒலி பிழையைக் கண்டறிந்து குறியீட்டில் அதை சரிசெய்ய முயற்சிக்கவும். திருத்தம் பொருத்தமானதாக இருந்தால் குறியீட்டில் ஆவணப்படுத்தவும். நீங்கள் சரிசெய்த குறியீட்டின் இடத்தைச் சோதிக்க, சோதனைத் தொகுப்பில் ஒரு சோதனையைச் சேர்ப்பது நல்லது; சோதனைகளைச் சேர்க்க சில திட்டங்களுக்கு பிழை திருத்தங்கள் தேவை. இந்த அறிமுகமில்லாத கோட்பேஸை சுற்றிக் கொண்டே குறிப்புகளை வைத்துக் கொள்ளுங்கள். பிழையை உங்களால் சரிசெய்ய முடியாவிட்டாலும், திருத்த முயற்சியின் ஒரு பகுதியாக நீங்கள் கண்டறிந்ததை டிக்கெட்டில் பதிவு செய்யவும். நீங்கள் கண்டுபிடிப்பது உங்களுக்குப் பின் வருபவர்களுக்கு உதவும்.

8. சோதனை எழுது: பெரும்பாலான திட்டங்களில் குறியீட்டைச் சோதிக்கும் ஒரு சோதனைத் தொகுப்பு உள்ளது, ஆனால் கூடுதல் சோதனைகளைச் சேர்க்க முடியாத ஒரு சோதனைத் தொகுப்பைக் கற்பனை செய்வது கடினம். சோதனைத் தொகுப்பால் சோதிக்கப்படாத மூலக் குறியீட்டில் உள்ள பகுதிகளைக் கண்டறிய, Gcov for C அல்லது Devel::Cover for Perl போன்ற சோதனைக் கவரேஜ் கருவியைப் பயன்படுத்தவும். பின்னர், அதை மறைக்க ஒரு சோதனையை தொகுப்பில் சேர்க்கவும்.

9. ஒரு கம்பைலர் எச்சரிக்கையை அமைதிப்படுத்து: பல சி-அடிப்படையிலான திட்டங்களுக்கான உருவாக்க செயல்முறை பெரும்பாலும் ஒற்றைப்படை கம்பைலர் எச்சரிக்கைக் கொடியை திரையில் செலுத்துகிறது. இந்த எச்சரிக்கைகள் பொதுவாக ஒரு சிக்கலின் குறிகாட்டிகள் அல்ல, ஆனால் அவை அப்படியே இருக்கும். பல எச்சரிக்கைகள் இருப்பதால், கம்பைலர் ஓநாய் அழுவது போல் ஒலிக்கும். குறியீடு உண்மையில் பிழையை மறைக்கிறதா என்பதைப் பார்க்கவும். இல்லையெனில், மூலத்தை அமைதிக்கு மாற்றுவது இந்த தவறான நேர்மறைகளை மறைக்க உதவுகிறது.

10. ஒரு கருத்தைச் சேர்: நீங்கள் குறியீட்டைத் தோண்டி எடுக்கும்போது, ​​குழப்பமான சில இடங்களைக் காணலாம். நீங்கள் குழப்பமடைந்திருந்தால், மற்றவர்களும் அவ்வாறு இருப்பதற்கான வாய்ப்புகள் உள்ளன. குறியீட்டில் அவற்றை ஆவணப்படுத்தி ஒரு பேட்சைச் சமர்ப்பிக்கவும். ஆவணங்களுடன் வேலை செய்யுங்கள் ஆவணப்படுத்தல் என்பது ஒரு திட்டத்தின் ஒரு பகுதியாகும், இது குறுகிய மாற்றத்தைப் பெறுகிறது. யாரோ ஒருவரின் பார்வையில் நுழைவதை விட, திட்டத்துடன் நன்கு தெரிந்தவர்களின் பார்வையில் எழுதப்பட்டதால் இது பாதிக்கப்படலாம். நீங்கள் எப்போதாவது ஒரு ப்ராஜெக்ட்டுக்கான டாக்ஸைப் படித்திருந்தால், "இந்த கையேடு எனக்கு ஏற்கனவே பேக்கேஜை எப்படி பயன்படுத்துவது என்று தெரியும் என்று எதிர்பார்க்கிறது போல் இருக்கிறது", நான் எதைப் பற்றி பேசுகிறேன் என்று உங்களுக்குத் தெரியும். பெரும்பாலும் புதிய கண்களின் தொகுப்பு, திட்டத்திற்கு நெருக்கமானவர்கள் கவனிக்காத ஆவணங்களில் உள்ள குறைபாடுகளை சுட்டிக்காட்டலாம்.

11. உதாரணத்தை உருவாக்கவும்: பல எப்படி-எப்படி-எடுத்துக்கொள்ளும் உதாரணங்களைக் கொண்ட எந்த திட்டமும் இல்லை. அது ஒரு வலை API, நடைமுறைகளின் நூலகம், Gimp போன்ற GUI ஆப்ஸ் அல்லது கட்டளை வரி கருவியாக இருந்தாலும் சரி, முறையான பயன்பாட்டிற்கான ஒரு சிறந்த எடுத்துக்காட்டு, ஆவணங்களின் பக்கங்களை விட மென்பொருளின் சரியான பயன்பாட்டை மிகவும் தெளிவாகவும் விரைவாகவும் விளக்க முடியும். API அல்லது நூலகத்திற்கு, கருவியைப் பயன்படுத்தும் ஒரு எடுத்துக்காட்டு நிரலை உருவாக்கவும். இது நீங்கள் எழுதிய குறியீட்டிலிருந்து பிரித்தெடுக்கப்படலாம், தேவைக்கேற்ப குறைக்கலாம். ஒரு கருவிக்கு, உங்கள் அன்றாட வாழ்க்கையில் அதை எப்படிப் பயன்படுத்துகிறீர்கள் என்பதற்கான நிஜ உலக உதாரணங்களைக் காட்டுங்கள். நீங்கள் பார்வை சார்ந்தவராக இருந்தால், பயன்பாட்டை எவ்வாறு நிறுவுவது போன்ற முக்கியமான செயல்முறையின் திரை-பிடிப்பை உருவாக்குவதைக் கருத்தில் கொள்ளுங்கள்.

சமூகத்துடன் வேலை செய்யுங்கள் ஓப்பன் சோர்ஸ் என்பது ஓரளவுக்கு மட்டுமே குறியீடு பற்றியது. சமூகம் திறந்த மூல வேலை செய்கிறது. நீங்கள் அதை உருவாக்க உதவும் வழிகள் இங்கே உள்ளன.

12. கேள்விக்கு பதிலளிக்கவும்: சமூகத்தை கட்டியெழுப்ப சிறந்த வழி மற்றவர்களுக்கு உதவுவதே. ஒரு கேள்விக்கு பதிலளிப்பது, குறிப்பாக கால்களை நனைக்கும் ஒருவரிடமிருந்து, திட்டம் வளரவும் செழிக்கவும் உதவும். ஒரு தொடக்கநிலையாளருக்கு உதவ நீங்கள் எடுக்கும் நேரம், நீங்கள் விரைவாக "RTFM" ஐ எங்கே எளிதாகத் திரும்பப் பெறலாம் என்று ஒரு கேள்வியைக் கேட்டாலும், சமூகத்தின் மற்றொரு செயலில் உள்ள உறுப்பினரைப் பெறுவதற்கான பாதையைக் குறைக்கிறது. ஒவ்வொருவரும் எங்காவது தொடங்குகிறார்கள், மேலும் அவர்கள் முக்கியமாக இருக்க வேண்டுமென்றால் திட்டங்களுக்கு மக்கள் தொடர்ந்து வர வேண்டும்.

13. ஒரு வலைப்பதிவு இடுகையை எழுதுங்கள்: உங்களிடம் வலைப்பதிவு இருந்தால், நீங்கள் பயன்படுத்தும் திட்டத்தில் உங்கள் அனுபவங்களைப் பற்றி எழுதுங்கள். மென்பொருளைப் பயன்படுத்தி நீங்கள் எதிர்கொண்ட பிரச்சனை மற்றும் அதைத் தீர்க்க நீங்கள் என்ன செய்தீர்கள் என்று சொல்லுங்கள். உங்களைச் சுற்றியுள்ள மற்றவர்களின் மனதில் திட்டத்தை வைத்திருக்க உதவுவதன் மூலம், நீங்கள் இரண்டு வழிகளில் உதவுவீர்கள். எதிர்காலத்தில் உங்கள் பிரச்சனையை எதிர்கொண்டு அதற்கான பதிலை இணையத்தில் தேடும் எவருக்கும் ஒரு பதிவை உருவாக்குவதன் மூலம். (உங்கள் தொழில்நுட்ப சாகசங்களின் வலைப்பதிவு, கேள்விக்குரிய மென்பொருளின் நிஜ-உலக அனுபவத்தைக் காட்ட, அடுத்த முறை நீங்கள் வேலைக்காக வேட்டையாடச் செல்லும் ஒரு சிறந்த வழியாகும்.)

14. ஒரு இணையதளத்தை மேம்படுத்தவும்: நீங்கள் வலை வடிவமைப்பில் திறமை பெற்றிருந்தால் மற்றும் வலைகளை மேம்படுத்த உதவலாம்இது, மற்றும் திட்டத்தின் பொது முகம் படம், அந்த நேரம் நன்றாக செலவிடப்பட்டது. திட்டமானது ஒரு கிராஃபிக் மாற்றத்தை அல்லது திட்டத்தை அடையாளம் காண ஒரு லோகோவைப் பயன்படுத்தலாம். இவை சமூகத்தில் இல்லாத திறன்களாக இருக்கலாம். எனது திட்டப்பணிகளின் இணையதளங்களில் ஏதேனும் கிராஃபிக் டிசைன் உதவி கிடைத்தால் நான் அதை விரும்புவேன் என்று எனக்குத் தெரியும்.

15. தொழில்நுட்ப ஆவணங்களை எழுதவும் ஒரு பயன்பாடு அல்லது மென்பொருள் எவ்வாறு செயல்படுகிறது என்பதைப் பற்றி நீங்கள் எழுத முடிந்தால், அதைப் பற்றிய தொழில்நுட்ப ஆவணங்களை நீங்கள் எழுதலாம். குறிப்பாக ஓப்பன் சோர்ஸ் திட்டங்கள், பொது மக்கள் படிக்கும் வகையில் தொழில்நுட்ப ஆவணங்களை புதுப்பிக்க, புதுப்பிக்க, விரிவாக்க அல்லது உருவாக்க வேண்டும். நீங்கள் சாதாரண ஆங்கிலத்தில் எவ்வளவு அதிகமாக எழுதுகிறீர்களோ, அவ்வளவு சிறந்தது. சிறந்த பகுதி, தொழில்நுட்ப ஆவணங்களை எழுத நீங்கள் ஒரு புரோகிராமராக இருக்க வேண்டியதில்லை.

எல்லாவற்றிற்கும் மேலாக, உங்களைச் சுற்றியுள்ளவர்கள் என்ன பேசுகிறார்கள் என்பதைக் கேளுங்கள். ஒரு அழுத்தமான தேவையை உங்களால் அடையாளம் காண முடியுமா என்று பாருங்கள். உதாரணமாக, சமீபத்தில் கிளி டெவலப்பர்களின் அஞ்சல் பட்டியலில், அவர்கள் வைத்திருந்த பழைய ட்ராக் நிறுவலைக் கைவிட்டு, சிக்கல் டிக்கெட் அமைப்பாக GitHub ஐப் பயன்படுத்த முடிவு செய்யப்பட்டது. டிக்கெட்டுகளை கிட்ஹப் அமைப்பிற்கு மாற்ற வழி இல்லாததால் சிலர் இந்த நடவடிக்கைக்கு எதிராக இருந்தனர். ஒரு நாள் முன்னும் பின்னுமாக வாக்குவாதத்திற்குப் பிறகு, "நான் மாற்றி எழுதினால் எப்படி?" இந்த யோசனையில் மக்கள் மகிழ்ச்சியடைந்தனர். 450+ டிக்கெட்டுகளுக்கு மாற்றும் திட்டத்தை எழுத நான் நேரத்தை செலவிட்டேன், அதனால் எங்களின் டிக்கெட் வரலாறு எதையும் இழக்கவில்லை. இது பெரும் வெற்றி பெற்றது. நான் களமிறங்கினேன், முக்கிய டெவலப்பர்கள் கிளி வேலை செய்யும் வணிகத்தில் கவனம் செலுத்தினர்.

16. மற்றவர்களுக்குக் கற்றுக் கொடுங்கள்: ஒரு தலைப்பைப் பற்றி மேலும் அறிய சிறந்த வழி அதைக் கற்பிக்க முயற்சிப்பதாகும். சிக்கலான விஷயங்களை எளிய உதாரணங்களுடன் விளக்கக்கூடியவர் சிறந்த ஆசிரியர். எனவே நீங்கள் சிறந்த கற்பவராகவும் உங்கள் நிரலாக்க உலகில் சிறந்தவராகவும் இருக்க சிறந்த ஆசிரியராக இருக்க முயற்சிக்க வேண்டும். மற்றவர்களுக்குக் கற்பிப்பது உங்களைப் பற்றி நன்றாக உணரவைக்கும், மேலும் உங்கள் தொழிலில் சிறந்த திறன்களையும் அறிவையும் பெற உதவும். நீங்கள் ஒருவரிடமிருந்து உதவியைப் பெற்றால், அதை நீங்களே வைத்துக் கொள்ளாதீர்கள், மற்றவர்களுடன் பகிர்ந்து கொள்ளுங்கள். உலகத்தை வாழ சிறந்த இடமாக மாற்றவும்.