புதிய சிக்கலைச் சமர்ப்பித்தல்

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

ஏற்கனவே உள்ள சிக்கல்களைத் தேடுக

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

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

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

ஒரு கலந்துரையாடலுடன் தொடங்குங்கள்

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

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

ஒரு நல்ல பிழை அறிக்கையை எழுதுதல்

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

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

உங்களால் முடிந்தவரை விரிவான விவரங்கள் எங்களுக்குத் தேவை. இதில் பின்வருவன அடங்கும், ஆனால் இவை மட்டுமே அல்ல:

• உங்கள் இயக்க முறைமைப் பதிப்பு - நுண் பதிப்பு வரை (உதாரணமாக, macOS 15.7.2).
• உங்கள் பைத்தான் பதிப்பு, நுண் பதிப்பு வரை (உதாரணமாக, 3.14.1).
• நீங்கள் பைத்தனை எப்படி நிறுவினார்? python.org-இலிருந்து பதிவிறக்கம் செய்தீர்களா? ஹோம்ப்ரூவைப் பயன்படுத்தினீர்களா? uv? pyenv? conda? வேறு ஏதேனும்?
• நீங்கள் பயன்படுத்தும் பீவேர் கருவிகளின் குறிப்பிட்ட பதிப்பு எது (உதாரணமாக, டோகா 0.5.3). நீங்கள் ஒரு மேம்பாட்டுப் பதிப்பைப் பயன்படுத்தினால், எந்த கிட் ஹாஷைப் பயன்படுத்துகிறீர்கள்? "தற்போதைய பிரதான கிளை" என்று சொல்வது மட்டும் போதுமானதல்ல, ஏனெனில் அது தினசரி மாறக்கூடும்.
• சிக்கலைத் தூண்டுவதற்கு நிறுவப்பட வேண்டிய மற்ற தொகுப்புகளின் குறிப்பிட்ட பதிப்புகள். இந்தத் தகவலை வழங்க, python -m pip freeze இயக்கியதன் முடிவுகளை நீங்கள் சேர்க்கலாம்.
• ஒரு பதிவு கோப்பு உருவாக்கப்பட்டிருந்தால், முழுமையான பதிவு கோப்பு.
• ஒரு ஸ்டேக் டிரேஸ் உருவாக்கப்பட்டிருந்தால், முழுமையான ஸ்டேக் டிரேஸை வழங்கவும். இறுதி பிழைச் செய்தியை மட்டும் வழங்க வேண்டாம் - ஸ்டேக் டிரேஸின் முழுமையான சூழல் முக்கியமானது. இதை ஒரு ஸ்கிரீன்ஷாட் ஆக அல்லாமல், எழுத்துப்பூர்வ வடிவத்தில் வழங்குவது சிறந்தது.
• இந்தச் சிக்கலில் தாக்கத்தை ஏற்படுத்தக்கூடிய உங்கள் கணினி அல்லது நெட்வொர்க் அமைப்பு பற்றி வேறு ஏதேனும் உள்ளதா? உங்கள் கணினி பழமையானதா அல்லது மெதுவானதா? அது ஒரு பணி கணினியா, அதில் ஃபயர்வால்ஸ், வைரஸ் சோதனையாளர்கள் அல்லது பிற கட்டுப்பாடுகள் இருக்கலாம்? உங்கள் நெட்வொர்க் குறிப்பாக மெதுவாக உள்ளதா? உங்கள் இயக்க முறைமையை வழக்கத்திற்கு மாறான அமைப்புகளுடன் (மிகப் பெரிய எழுத்துரு அல்லது வேறு ஏதேனும் உதவித் தொழில்நுட்பம் இயக்கப்பட்டது போன்றவை) இயக்குகிறீர்களா?

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

ஒரு குறைந்தபட்ச எடுத்துக்காட்டு

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

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

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

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

அறிக்கையைச் சமர்ப்பித்தல்

project issues list-க்குச் சென்று, "New issue" பொத்தானைக் கிளிக் செய்து, செயல்முறையைத் தொடங்க "Bug report"-ஐத் தேர்ந்தெடுக்கவும்.

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

கோடை சேர்க்கும்போது, BeeWare பயிற்சி போன்ற ஏற்கனவே உள்ள ஒரு உதாரணத்தில் உங்களால் அதை மீண்டும் உருவாக்க முடிந்தால், நீங்கள் ஒரு இணைப்பை வழங்கலாம். இல்லையெனில், அறிக்கையில் கோடை வழங்கவும். அது மார்க் டவுன் வடிவத்தில் இருக்க வேண்டும்; ஒரு கோட்பிளாக்கிற்கு (codeblock) அதன் முன் மற்றும் பின்னால் மூன்று பேக்டிக் குறியீடுகள் (```) தேவை.

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

<details>
<summary>சுருங்கிய உள்ளடக்கத்தின் தலைப்பு</summary>
நீண்ட உரைப் பகுதி.
</details>

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

ஒரு இசூவை உருவாக்க GitHub CLI-ஐப் பயன்படுத்துதல்

GitHub CLI-ஐ நேரடியாகப் பயன்படுத்துவது (gh) நாம் உருவாக்கிய டெம்ப்ளேட்களைத் தவிர்த்துவிடும். இந்த டெம்ப்ளேட்கள், இசூவில் நடவடிக்கை எடுப்பதற்குத் தேவையான தகவல்கள் நமக்குக் கிடைப்பதை உறுதி செய்வதற்காகவே உள்ளன.

புதிய சிக்கலை உருவாக்க நீங்கள் gh பயன்படுத்தப் போனால், பின்வருவனவற்றைப் பயன்படுத்தவும்:

ஜிஎச் இஷ்யூ கிரியேட் --வெப்

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