mirror of
https://github.com/LucasVbr/first-contributions.git
synced 2026-05-14 01:31:50 +00:00
Merge branch 'main' into main
This commit is contained in:
Roshan Jossy
@@ -0,0 +1,84 @@
|
||||
# গিট কনফিগারেশন
|
||||
|
||||
প্রথমবারের মতো যখন আপনি `commit` করার চেষ্টা করবেন, তখন এই ধরনের বার্তা দেখতে পাবেন:
|
||||
|
||||
```bash
|
||||
$ git commit
|
||||
*** Please tell me who you are.
|
||||
|
||||
Run
|
||||
|
||||
git config --global user.email "you@example.com"
|
||||
git config --global user.name "Your Name"
|
||||
|
||||
to set your account's default identity.
|
||||
Omit --global to set the identity only in this repository.
|
||||
```
|
||||
|
||||
একটি `commit` তৈরি করতে গিটকে জানতে হবে যে এর লেখক কে। সহযোগী কাজের ক্ষেত্রে, প্রকল্পের বিভিন্ন অংশের পরিবর্তন করেছেন কে এবং কবে, তা জানা খুবই গুরুত্বপূর্ণ। তাই গিটে প্রতিটি `commit`-এর সাথে ব্যবহারকারীর নাম এবং ইমেল ঠিকানা সংযুক্ত করা হয়।
|
||||
|
||||
এখানে কিছু উপায় আছে যার মাধ্যমে আপনি আপনার ইমেল এবং নাম `git commit` কমান্ডের সাথে যুক্ত করতে পারেন।
|
||||
|
||||
### গ্লোবাল কনফিগারেশন
|
||||
|
||||
গ্লোবাল কনফিগারেশনে সংরক্ষিত তথ্য সমস্ত গিট রিপোজিটরিতে প্রযোজ্য। এটি হল সবচেয়ে ব্যবহৃত পদ্ধতি।
|
||||
|
||||
গ্লোবাল কনফিগারেশনে কিছু সেট করতে, আপনি `config` কমান্ডটি এভাবে ব্যবহার করতে পারেন:
|
||||
|
||||
```bash
|
||||
$ git config --global <variable name> <value>
|
||||
```
|
||||
|
||||
ব্যবহারকারীর তথ্য সেট করার জন্য, এটি এভাবে হবে:
|
||||
|
||||
```bash
|
||||
$ git config --global user.email "you@example.com"
|
||||
$ git config --global user.name "Your Name"
|
||||
```
|
||||
|
||||
### রিপোজিটরি স্তরের কনফিগারেশন
|
||||
|
||||
এই ধরনের কনফিগারেশন শুধুমাত্র আপনার বর্তমান রিপোজিটরিতে প্রযোজ্য। যদি আপনি কোনও নির্দিষ্ট রিপোজিটরিতে কাজ করতে চান (উদাহরণস্বরূপ, কোম্পানির প্রকল্পে), তবে এই পদ্ধতি ব্যবহার করতে পারেন।
|
||||
|
||||
রিপোজিটরি স্তরের কনফিগারেশন সেট করতে, `--global` বাদ দিয়ে `config` কমান্ডটি ব্যবহার করুন:
|
||||
|
||||
```bash
|
||||
$ git config <variable name> <value>
|
||||
```
|
||||
|
||||
ব্যবহারকারীর তথ্য সেট করার জন্য, এটি এভাবে হবে:
|
||||
|
||||
```bash
|
||||
$ git config user.email "you@alternate.com"
|
||||
$ git config user.name "Your Name"
|
||||
```
|
||||
|
||||
### কমান্ড লাইনে কনফিগারেশন
|
||||
|
||||
এই ধরনের কনফিগারেশন শুধুমাত্র একটি নির্দিষ্ট কমান্ডের জন্য প্রযোজ্য। সব গিট কমান্ডে `-c` ব্যবহার করে আপনি কনফিগারেশন পরামিতি সেট করতে পারেন।
|
||||
|
||||
একটি কমান্ডের জন্য কনফিগারেশন পরিবর্তন করতে, গিট কমান্ডটি এভাবে ব্যবহার করুন:
|
||||
|
||||
```bash
|
||||
$ git -c <variable-1>=<value> -c <variable-2>=<value> <command>
|
||||
```
|
||||
|
||||
আমাদের ক্ষেত্রে, `commit` কমান্ডটি এভাবে হবে:
|
||||
|
||||
```bash
|
||||
git -c user.name='Your Name' -c user.email='you@example.com' commit -m "Your commit message"
|
||||
```
|
||||
|
||||
### অগ্রাধিকারের ক্রম
|
||||
|
||||
এই তিনটি কনফিগারেশন পদ্ধতির মধ্যে অগ্রাধিকারের ক্রম হল: `কমান্ড লাইন > রিপোজিটরি > গ্লোবাল`। এর মানে হল যদি কোনও পরিবর্তনশীল গ্লোবাল এবং কমান্ড লাইনে উভয় ক্ষেত্রেই সেট করা থাকে, তবে কমান্ড লাইনের মান ব্যবহার করা হবে।
|
||||
|
||||
## শুধু ব্যবহারকারীর তথ্য নয়
|
||||
|
||||
এখন পর্যন্ত আমরা গিট কনফিগারেশন নিয়ে আলোচনা করেছি শুধু ব্যবহারকারীর তথ্যের ক্ষেত্রে। কিন্তু গিট আরও অনেক পরামিতি কনফিগার করতে দেয়। এখানে কিছু উল্লেখযোগ্য উদাহরণ:
|
||||
|
||||
1. `core.editor` - কমিট মেসেজ এডিট করার জন্য ব্যবহৃত টেক্সট এডিটর,
|
||||
2. `commit.template` - কমিটের জন্য প্রাথমিক টেমপ্লেট ফাইল,
|
||||
3. `color.ui` - টার্মিনালে গিট মেসেজে রঙিন ফন্ট ব্যবহার করা যাবে কিনা তা নির্ধারণ করে।
|
||||
|
||||
আরও বিস্তারিত জানতে [git-scm.com](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration) দেখুন।
|
||||
@@ -0,0 +1,58 @@
|
||||
# ওপেন সোর্স অবদানের জন্য Git অনুমতি ত্রুটি সমাধান
|
||||
|
||||
## সমস্যা
|
||||
|
||||
আমি "first-contributions" রিপোজিটরিতে অবদান রাখার চেষ্টা করার সময় একটি অনুমতি ত্রুটি পেয়েছিলাম। আমি নতুন ব্রাঞ্চ তৈরি করে এবং পরিবর্তনগুলি পুশ করার চেষ্টা করার পর:
|
||||
|
||||
```bash
|
||||
$ git checkout -b fahimar_oss_YYYY
|
||||
Switched to a new branch 'fahimar_oss_YYYY'
|
||||
|
||||
$ git push origin fahimar_oss_YYYY
|
||||
remote: Permission to firstcontributions/first-contributions.git denied to fahimar.
|
||||
fatal: unable to access 'https://github.com/firstcontributions/first-contributions.git/': The requested URL returned error: 403
|
||||
```
|
||||
|
||||
সমস্যাটি ছিল যে, আমি মূল রিপোজিটরিটি সরাসরি ক্লোন করেছিলাম এবং সেখানে পুশ করার চেষ্টা করেছিলাম। একজন বাইরের অবদানকারী হিসেবে, আমার মূল রিপোজিটরিতে লেখার অনুমতি নেই।
|
||||
|
||||
## সমাধান
|
||||
|
||||
আমি নিম্নলিখিত উপায়ে এই সমস্যাটি সমাধান করেছি:
|
||||
|
||||
1. আমার রিমোট URL পরিবর্তন করে এটিকে আমার ব্যক্তিগত ফর্কে পয়েন্ট করানো:
|
||||
|
||||
```bash
|
||||
$ git remote set-url origin https://github.com/yourname/first-contributions.git
|
||||
```
|
||||
|
||||
2. রিমোট ঠিকভাবে আপডেট হয়েছে কিনা তা যাচাই করা:
|
||||
|
||||
```bash
|
||||
$ git remote -v
|
||||
origin https://github.com/yourname/first-contributions.git (fetch)
|
||||
origin https://github.com/yourname/first-contributions.git (push)
|
||||
```
|
||||
|
||||
3. সফলভাবে আমার ফর্কে পুশ করা:
|
||||
|
||||
```bash
|
||||
$ git push origin fahimar_oss_YYYY
|
||||
```
|
||||
|
||||
4. GitHub আমাকে একটি লিঙ্ক দিয়েছিল যাতে আমি আমার ব্রাঞ্চ থেকে পুল রিকোয়েস্ট তৈরি করতে পারি:
|
||||
```
|
||||
remote: Create a pull request for 'fahimar_oss_YYYY' on GitHub by visiting:
|
||||
remote: https://github.com/fahimar/first-contributions/pull/new/fahimar_oss_YYYY
|
||||
```
|
||||
|
||||
## প্রধান শিক্ষা
|
||||
|
||||
ওপেন সোর্স অবদানের জন্য সঠিক কাজের ধারাবাহিকতা হল:
|
||||
|
||||
1. মূল রিপোজিটরিটি আপনার GitHub অ্যাকাউন্টে ফর্ক করুন
|
||||
2. আপনার ফর্কটি স্থানীয়ভাবে ক্লোন করুন
|
||||
3. একটি নতুন ব্রাঞ্চে পরিবর্তন করুন
|
||||
4. আপনার ফর্কে পুশ করুন
|
||||
5. আপনার ফর্ক থেকে মূল রিপোজিটরিতে পুল রিকোয়েস্ট তৈরি করুন
|
||||
|
||||
যদি আপনি আগে মূল রিপোজিটরি ক্লোন করে থাকেন এবং আপনার ফর্ক না করে থাকেন, তবে উপরে দেখানো মতো রিমোট URL আপডেট করে এটি ঠিক করতে পারেন।
|
||||
@@ -0,0 +1,164 @@
|
||||
# حاجات ممكن اللي مش مبرمج يعملها
|
||||
## اسمع الأول
|
||||
|
||||
كل حاجة في الـ Open Source بتعتمد على الناس اللي شغالة فيها.
|
||||
إنت عايز تنضم لفريق، وده معناه إنك تفهم المجتمع شغال إزاي.
|
||||
لو دخلت على مشروع وقلت "هاي، أنا شايف إن المشروع المفروض يعمل كذا" غالبًا ده مش هيكون مقبول.
|
||||
ممكن مشاريع معينة تكون بتحب الأسلوب ده، لكن لو المشروع ليه فترة شغال، نسبة إن الناس تتقبل الكلام ده قليلة.
|
||||
**أحسن حاجة تعملها في الأول إنك تسمع وتشوف الناس شغالة إزاي.**
|
||||
|
||||
1. **اشترك في Mailing List**: في مشاريع كتير، الـ mailing list هي وسيلة التواصل الرئيسية بين الناس اللي بتطور المشروع.
|
||||
في المشاريع الكبيرة، هتلاقي كذا mailing list.
|
||||
مثلاً، مشروع PostgreSQL عنده أكتر من 12 mailing list للمستخدمين و6 للمطورين.
|
||||
ابدأ بمتابعة الـ list الأساسية للمستخدمين وواحدة من بتوع المطورين علشان تفهم اللي بيحصل.
|
||||
|
||||
2. **تابع Blog**: المطورين الكبار غالبًا بيكتبوا تدوينات بيشرحوا فيها اللي هيحصل في النسخ الجاية،
|
||||
وبيتكلموا عن اللي اتعمل علشان نوصل للمرحلة دي.
|
||||
في مواقع اسمها Planet بتجمع التدوينات والأخبار من كذا مصدر عن المشروع.
|
||||
لو فيه planet زي planet.gnome.org أو planet.mysql.com، يبقى ده مكان كويس تبدأ منه.
|
||||
اكتب في جوجل "planet <اسم المشروع>".
|
||||
|
||||
3. **ادخل على قناة IRC**: معظم مشاريع الـ Open Source عندها قنوات IRC الناس بتدخل تتكلم فيها عن المشاكل والتطوير.
|
||||
ادخل على موقع المشروع وشوف اسم القناة على أي شبكة IRC.
|
||||
|
||||
**اشتغل على التذاكر**
|
||||
الكود هو الأساس في أي مشروع مفتوح المصدر، بس ده مش معناه إن الكود هو الطريقة الوحيدة اللي ممكن تساهم بيها.
|
||||
فيه حاجات تانية كتير الناس بتكسل تعملها، زي صيانة النظام أو متابعة المشاكل.
|
||||
ابدأ من هنا وهتلاقي نفسك بقيت جزء من الفريق.
|
||||
|
||||
معظم المشاريع عندها نظام تذاكر على الموقع الرسمي.
|
||||
ده بيكون وسيلة تواصل بين الناس اللي بتستخدم البرنامج والمطورين.
|
||||
تنضيف التذاكر دي وتحديثها بيساعد الفريق جدًا.
|
||||
|
||||
ممكن تحتاج صلاحيات علشان تعدل على التذاكر، بس صدقني، أول ما تقول إنك عايز تساعد، هيدوك الصلاحيات دي على طول.
|
||||
|
||||
4. **حلل مشكلة (Bug)**: ساعات الناس بتبلّغ عن مشاكل بشكل مش واضح.
|
||||
لو حد قال "البرنامج بيهنّج لما بعمل كذا"، خد وقتك وحاول تعرف المشكلة دي بتحصل إزاي.
|
||||
هل بتتكرر؟ تقدر تكتب خطوات تثبت بيها إنها بتحصل؟ بتحصل على متصفح معين؟ ولا في نظام تشغيل معين؟
|
||||
|
||||
حتى لو معرفتش تحلها، إنك توضّح المشكلة أكتر بيسهّل على حد تاني ييجي يحلها.
|
||||
وكل اللي تكتشفه، اكتبه في التذكرة علشان غيرك يستفيد.
|
||||
|
||||
5. **اقفل التذاكر القديمة**: كتير من المشاكل بتكون اتحلت، بس التذاكر لسه مفتوحة.
|
||||
البحث في التذاكر القديمة وتنضيفها حاجة مهمة جدًا.
|
||||
|
||||
ابدأ بدور على تذاكر بقالها أكتر من سنة وشوف هل المشكلة لسه موجودة ولا اتصلحت.
|
||||
راجع سجل التغييرات في الإصدارات وشوف لو فيه ذكر للمشكلة.
|
||||
لو اتحلت، اكتب رقم النسخة في التذكرة واقفلها.
|
||||
|
||||
جرّب تعيد المشكلة في آخر نسخة من البرنامج.
|
||||
لو مشتغلتش، اكتب ده في التذكرة واقفلها.
|
||||
لو لسه موجودة، اكتبه برضو وسيب التذكرة مفتوحة.
|
||||
|
||||
## الشغل على الكود
|
||||
الناس اللي عندها خبرة مختلفة في البرمجة تقدر تساعد في الكود.
|
||||
مش لازم تكون مبرمج جامد علشان تساهم.
|
||||
|
||||
لو ناوي تعدل على الكود، اعرف الأول المشروع بيشتغل إزاي في موضوع استلام التعديلات.
|
||||
كل مشروع ليه طريقة معينة، فاسأل الأول.
|
||||
|
||||
مثلاً، PostgreSQL بيستقبل التعديلات على شكل Patch في mailing list، والمطورين بيراجعوها كويس جدًا.
|
||||
لكن في مشروع زي Parrot، ممكن تاخد صلاحيات التعديل بسهولة.
|
||||
لو المشروع على GitHub، غالبًا بيستخدموا Pull Requests.
|
||||
كل مشروع وليه طريقته.
|
||||
|
||||
لما تعدل حاجة، خليك محترم مع باقي الفريق وحافظ على تنسيق الكود زي ما هو.
|
||||
ما تحاولش تفرض أسلوبك.
|
||||
الكود اللي بتكتبه لازم يشبه اللي موجود، حتى لو مش عاجبك.
|
||||
|
||||
6. **اختبر نسخة Beta أو Release Candidate**:
|
||||
المشاريع اللي بتشتغل على كذا نظام تشغيل ساعات بيكون فيها مشاكل توافق.
|
||||
قبل الإصدارات، المطورين بينزلوا نسخ تجريبية علشان الناس تجربها.
|
||||
لو شغّلت البرنامج على نظام تشغيل مختلف واشتغل، ده بيساعدهم يعرفوا إن النسخة كويسة.
|
||||
|
||||
مش لازم تعمل حاجة غير إنك تبني البرنامج وتفتحه وتجربه.
|
||||
لو شغال، بلغهم.
|
||||
ده بيفرق كتير جدًا مع المطورين.
|
||||
|
||||
7. **صلّح Bug**: ده غالبًا أول حاجة الناس بتعملها لما تبدأ تشتغل في الكود.
|
||||
دور على Bug شكله بسيط، وجرب تصلحه.
|
||||
اكتب ملاحظاتك جوه الكود، ولو في Test يوضح إن المشكلة اتحلت، ضيفه.
|
||||
لو معرفتش تصلحها، اكتب اللي وصلتله في التذكرة.
|
||||
|
||||
8. **اكتب Test**:
|
||||
معظم المشاريع عندها Tests، بس دايمًا فيه مكان لإضافة تانية.
|
||||
استخدم أدوات بتقيس مدى التغطية، زي `gcov` أو `Devel::Cover`.
|
||||
وشوف أجزاء الكود اللي مش متغطية، وضيف لها Test.
|
||||
|
||||
9. **اسكت تحذير من الكومبايلر**:
|
||||
لما تبني برامج C، ممكن يطلعلك تحذيرات.
|
||||
مش دايمًا معناها إن فيه مشكلة، بس بتشوّش.
|
||||
لو شفت تحذير، شوف هل فعلاً فيه مشكلة؟
|
||||
لو لأ، عدل الكود علشان تسكت التحذير.
|
||||
|
||||
10. **ضيف تعليق**:
|
||||
لو لقيت جزء في الكود مش مفهوم، اكتبه تعليق.
|
||||
أكيد في ناس غيرك هتتلخبط برضو.
|
||||
ابعت تعديل فيه التعليقات دي.
|
||||
|
||||
## الشغل على التوثيق
|
||||
المستندات دايمًا بتتاخد بشكل بسيط.
|
||||
وساعات بتكون مكتوبة كأن اللي بيقراها أصلاً فاهم المشروع.
|
||||
لو حسيت إن التوثيق مش واضح، قول.
|
||||
اللي عنيهم جديدة بيشوفوا حاجات الناس اللي شغالة عليها مش شايفاها.
|
||||
|
||||
11. **اعمل مثال**:
|
||||
مفيش مشروع عنده أمثلة كتير كفاية.
|
||||
لو فيه API، أو مكتبة، أو برنامج GUI زي Gimp، أو حتى أداة سطر أوامر – اعمل مثال عملي بيشرح ازاي تستخدمه.
|
||||
|
||||
ممكن المثال يكون حاجة بسيطة من كود انت كتبته، أو حتى فيديو Screen Recording وانت بتستخدمه.
|
||||
الناس بتحب تشوف التطبيق العملي أكتر من الكلام.
|
||||
|
||||
## اشتغل مع المجتمع
|
||||
الـ Open Source مش بس كود. المجتمع هو اللي بيخلي المشاريع دي تعيش وتكبر.
|
||||
فيه طرق كتير تقدر تساعد بيها في تقوية المجتمع حوالي المشروع.
|
||||
|
||||
12. **جاوب على سؤال**:
|
||||
أحسن طريقة تساعد بيها المشروع والمجتمع هي إنك تساعد غيرك.
|
||||
لما حد جديد يسأل سؤال، وحضرتك تجاوبه بدل ما تقول له "روح اقرأ الـ Manual"، كده إنت مش بس ساعدته،
|
||||
إنت كمان شجّعته يكمل، ويمكن كمان يبقى عضو نشيط في المشروع بعد كده.
|
||||
|
||||
كلنا بدأنا من الصفر، والمشاريع محتاجة دايمًا ناس جديدة تدخل علشان تفضل عايشة.
|
||||
|
||||
13. **اكتب تدوينة (Blog Post)**:
|
||||
لو عندك مدونة، احكي فيها عن تجربتك مع المشروع اللي بتستخدمه.
|
||||
قول واجهت إيه مشاكل، وازاي حليتها.
|
||||
كده بتساعد المشروع بطريقتين:
|
||||
- إنك بتخلي الناس تفكر في المشروع وتسمع عنه.
|
||||
- وإنك بتسيب أثر للي بعدك لو حد واجه نفس المشكلة وعمل بحث على جوجل.
|
||||
|
||||
(والتدوينة دي كمان ممكن تبقى وسيلة كويسة توري بيها خبرتك الحقيقة في الشغل لما تيجي تدور على شغل.)
|
||||
|
||||
14. **طوّر موقع المشروع**:
|
||||
لو عندك خبرة في تصميم المواقع، وساعدت في تحسين الموقع أو شكله العام، ده وقتك مش بيضيع.
|
||||
يمكن المشروع محتاج لوجو، أو ستايل أحسن، أو تنظيم أحسن للمحتوى.
|
||||
الحاجات دي ساعات بتكون ناقصة عند المبرمجين، وساعتها أي حد عنده ذوق أو خبرة في التصميم بيفرق جامد.
|
||||
أنا عن نفسي بتمنى ألاقي حد يساعدني في التصميم في مشاريعي!
|
||||
|
||||
15. **اكتب توثيق تقني (Documentation)**:
|
||||
لو تقدر تشرح ازاي برنامج أو أداة شغالة، يبقى تقدر تكتب توثيق تقني عنها.
|
||||
مشاريع Open Source كتير بتبقى محتاجة توثيق جديد، أو تطوير اللي موجود، أو تبسيطه للناس.
|
||||
|
||||
كل ما كانت كتابتك أبسط وأوضح، كل ما كانت أحسن.
|
||||
وأجمل حاجة؟ مش لازم تكون مبرمج علشان تكتب Documentation.
|
||||
|
||||
والأهم من كل ده، اسمع الناس بتتكلم عن إيه.
|
||||
حاول تلاحظ المشاكل اللي محتاجة حل.
|
||||
مثلاً، في مرة على Mailing List لمشروع Parrot، قرروا ينقلوا من Trac لـ GitHub في نظام التذاكر.
|
||||
ناس كتير كانوا ضد القرار علشان مفيش طريقة ينقلوا التذاكر القديمة.
|
||||
دخلت وقلت "طب ما أكتب أنا برنامج يحوّل التذاكر؟" والناس فرحت جدًا.
|
||||
فعلاً كتبت برنامج نقل أكتر من 450 تذكرة، واحتفظنا بتاريخهم.
|
||||
نجاح جميل، وساعدت الفريق، والمطورين ركزوا في شغلهم بدل وجع الدماغ.
|
||||
|
||||
16. **علّم وساعد غيرك**:
|
||||
أحسن طريقة تتعلم بيها أكتر، إنك تشرح اللي فهمته لحد تاني.
|
||||
المدرّس الشاطر هو اللي يقدر يشرح حاجة معقدة بطريقة بسيطة.
|
||||
|
||||
لو علمت حد، أو ساعدته، مش بس هتحس إنك عملت حاجة كويسة،
|
||||
ده كمان هيثبت المعلومة في دماغك، ويقوّي مهاراتك.
|
||||
ولما حد يساعدك، ما تحتفظش بالمعلومة لنفسك.
|
||||
شارك اللي عرفته، وخلّي الدنيا مكان أحسن.
|
||||
|
||||
والسلام عليكم ورحمة الله وبركاته.
|
||||
|
||||
|
||||
@@ -0,0 +1,52 @@
|
||||
# Ce qu'un non programmeur peut faire
|
||||
|
||||
## Être attentive
|
||||
|
||||
Dans le domaine de l'open source, toute démarche, qu'il s'agisse de programmation ou d'autres aspects, requiert la contribution et l'implication d'autres personnes.
|
||||
|
||||
Rejoindre une équipe open source, implique de comprendre la dynamique de la communauté et son mode de fonctionnement. Plutôt que d'arriver sur un projet en affirmant immédiatement, "Voici ce que je pense que ce projet devrait faire", il est généralement plus bénéfique d'adopter une approche plus attentive.
|
||||
|
||||
Certains projets peuvent accueillir favorablement ce type d'approche, mais si le projet existe depuis un certain temps, les chances que cette attitude soit adoptée sont faibles. L'écoute est le meilleur moyen de savoir ce dont le projet a besoin.
|
||||
|
||||
1. **S'abonner à une liste de diffusion** : Pour de nombreux projets, la liste de diffusion est le principal moyen de communication sur le développement du projet. Dans les grands projets, il existe de nombreuses listes de diffusion. Par exemple, le projet PostgreSQL a pas moins de 12 listes orientées utilisateurs et six listes de développeurs sur sa page de listes de diffusion. Je vous suggère de suivre la liste principale orientée utilisateurs et la liste principale de développeurs pour commencer à écouter.
|
||||
2. **Suivre un blog** : Les blogs tenus par les développeurs principaux donnent souvent des informations sur les prochaines versions et sur les étapes nécessaires pour y parvenir. Un site planet regroupe des nouvelles et des articles de blog provenant de nombreuses sources liées au projet. S'il existe un site planet, comme planet.gnome.org ou planet.mysql.com, commencez par là. Il suffit de chercher "planet" dans Google.
|
||||
3. **Rejoindre un canal IRC** : De nombreux projets open source disposent de canaux IRC (Internet relay chat) dédiés où les développeurs et les utilisateurs se retrouvent pour discuter des problèmes et du développement. Consultez le site web du projet pour connaître le nom du canal et le réseau IRC sur lequel il se trouve.
|
||||
4. **Travailler avec des tickets**: Le code est au cœur de tout projet open source, mais il ne faut pas croire que l'écriture de code est la seule façon de contribuer. La maintenance du code et des systèmes qui l'entourent est souvent négligée dans la course à la création de nouvelles fonctionnalités et à la correction des bogues. Ces domaines sont un moyen facile de mettre un pied dans un projet. La plupart des projets disposent d'un système de tickets de dépannage visible par tous, lié à la page d'accueil du site web du projet et inclus dans la documentation. Il s'agit du principal canal de communication entre les utilisateurs et les développeurs. Le maintenir à jour est un excellent moyen d'aider le projet. Il se peut que vous deviez obtenir des autorisations spéciales dans le système de tickets, que la plupart des chefs de projet seront heureux de vous accorder lorsque vous direz que vous voulez aider à nettoyer les tickets.
|
||||
5. **Diagnostiquer un bogue** : Les bogues sont souvent mal signalés. Le diagnostic et le triage d'un bogue peuvent aider les développeurs à gagner du temps en leur permettant de comprendre les spécificités du problème. Si un utilisateur signale que "le logiciel ne fonctionne pas lorsque je fais X", prenez le temps d'analyser les détails de ce problème. Est-il reproductible ? Pouvez-vous créer une série d'étapes pour provoquer le problème de manière répétée ? Pouvez-vous circonscrire le problème, par exemple s'il ne se produit que sur un navigateur et pas sur un autre, ou sur une distribution et pas sur une autre ?
|
||||
|
||||
Même si vous ne savez pas ce qui cause le problème, l'effort que vous faites pour réduire les circonstances permet à quelqu'un d'autre de le résoudre plus facilement. Quoi que vous découvriez, ajoutez-le au ticket dans le système de gestion des bogues pour que tout le monde puisse le voir.
|
||||
|
||||
6. **Fermer les bogues corrigés** : Il arrive souvent que des bogues soient corrigés dans la base de code, mais que les tickets signalés à leur sujet ne soient pas mis à jour dans le système de gestion des tickets. Le nettoyage de ces bogues peut prendre du temps, mais il est précieux pour l'ensemble du projet.
|
||||
Commencez par interroger le système de tickets pour les tickets datant de plus d'un an et voyez si le bogue existe toujours. Consultez le journal des modifications de la version du projet pour voir si le bogue a été corrigé et s'il peut être fermé. Si l'on sait qu'il a été corrigé, notez le numéro de version dans le ticket et fermez-le.
|
||||
|
||||
Essayez de recréer le bogue avec la dernière version du logiciel. S'il ne peut pas être recréé avec la dernière version, notez-le dans le ticket et fermez-le. S'il existe toujours, notez-le également dans le ticket et laissez-le ouvert.
|
||||
|
||||
Travailler avec du code Des programmeurs de tous les niveaux d'expérience peuvent aider à développer le code du projet. Ne pensez pas que vous devez être un génie du codage pour apporter une réelle contribution à votre projet favori.
|
||||
|
||||
Si votre travail consiste à modifier le code, renseignez-vous sur la méthode utilisée par le projet pour obtenir le code des contributeurs. Chaque projet a son propre flux de travail, alors renseignez-vous sur la façon de procéder avant de commencer à soumettre du code.
|
||||
|
||||
Par exemple, le projet PostgreSQL est très rigoureux dans son processus : Les modifications de code sont envoyées sous forme de correctifs à une liste de diffusion où les développeurs principaux examinent minutieusement chaque aspect du changement. À l'autre extrémité, on trouve un projet comme Parrot, où il est facile d'obtenir des privilèges de validation pour la base de code. Si le projet utilise GitHub, il peut y avoir un flux de travail qui utilise la fonction de demande d'extraction de GitHub. Il n'y a pas deux projets identiques.
|
||||
|
||||
Chaque fois que vous modifiez du code, veillez à agir en tant que membre responsable de la communauté et à conserver un style de code qui corresponde au reste de la base de code. Le code que vous ajoutez ou modifiez doit ressembler au reste. Vous pouvez ne pas aimer le style des accolades ou la gestion des espaces pour l'indentation, mais il est impoli de soumettre une modification de code qui ne correspond pas aux normes existantes. Cela revient à dire : "Je n'aime pas votre style, et je pense que le mien est meilleur, alors vous devriez le faire à ma façon".
|
||||
|
||||
7. **Tester une version bêta ou une "release candidate"** : Tout projet conçu pour fonctionner sur plusieurs plateformes peut rencontrer toutes sortes de problèmes de portabilité. Lorsqu'une version approche et qu'une version bêta ou candidate est publiée, le chef de projet espère qu'elle sera testée par de nombreuses personnes différentes sur de nombreuses plateformes différentes. Vous pouvez être l'une de ces personnes et contribuer à faire en sorte que le paquetage fonctionne sur votre plateforme.
|
||||
|
||||
En général, il suffit de télécharger, de compiler et de tester le logiciel, mais la valeur pour le projet peut être énorme si vous utilisez une distribution ou un matériel peu courant. Le simple fait de signaler que la compilation et le test fonctionnent permet aux chefs de projet de savoir que la version imminente est solide.
|
||||
|
||||
8. **Corriger un bogue** : C'est généralement par là que commencent les contributeurs désireux de travailler sur le code. C'est simple : Trouvez un bogue intéressant dans le système de tickets et essayez de le corriger dans le code. Documentez la correction dans le code si cela est approprié. C'est une bonne idée d'ajouter un test à la suite de tests pour tester la partie du code que vous avez corrigée ; certains projets exigent que les corrections de bogues incluent des tests. Prenez des notes pendant que vous fouillez dans cette base de code inconnue. Même si vous ne parvenez pas à corriger le bogue, documentez dans le ticket ce que vous avez découvert dans le cadre de la tentative de correction. Ce que vous trouvez aide ceux qui viennent après vous.
|
||||
9. **Écrire un test**: La plupart des projets ont une suite de tests qui teste le code, mais il est difficile d'imaginer une suite de tests qui ne pourrait pas être complétée par d'autres tests. Utilisez un outil de couverture des tests comme gcov pour le C, ou Devel::Cover pour Perl pour identifier les zones du code source qui ne sont pas testées par la suite de tests. Ensuite, ajoutez un test à la suite pour couvrir ces zones.
|
||||
10. **Faire taire un avertissement du compilateur** : Le processus de compilation de nombreux projets basés sur le langage C fait souvent apparaître à l'écran un avertissement du compilateur. Ces avertissements ne sont généralement pas des indicateurs d'un problème, mais ils peuvent y ressembler. Un trop grand nombre d'avertissements peut donner l'impression que le compilateur crie au loup. Vérifiez si le code ne cache pas un bogue. Si ce n'est pas le cas, la modification du code source pour le rendre silencieux permet de dissimuler ces faux positifs.
|
||||
11. **Ajouter un commentaire** : Lorsque vous fouillez dans le code, il se peut que vous trouviez des points qui prêtent à confusion. Il y a de fortes chances que si vous avez été dérouté, d'autres le seront aussi. Documentez-les dans le code et soumettez un correctif. Travailler avec la documentation La documentation est généralement la partie d'un projet qui est la plus négligée. Elle peut aussi souffrir d'avoir été écrite du point de vue de ceux qui connaissent bien le projet, plutôt qu'à travers les yeux de quelqu'un qui vient de s'y lancer. Si vous avez déjà lu la documentation d'un projet et que vous vous êtes dit : "C'est comme si ce manuel s'attendait à ce que je sache déjà comment utiliser ce paquet", vous savez de quoi je parle. Souvent, un regard neuf peut mettre en évidence des lacunes dans la documentation que les personnes proches du projet ne remarquent pas.
|
||||
12. **Create an example** : There is no project that has too many how-to examples. Whether it's a web API, a library of routines, a GUI app like Gimp or a command line tool, a good example of proper usage can more clearly and quickly explain proper usage of software than pages of documentation. For an API or library, create an example program that uses the tool. This could even be extracted from code you've written, trimmed down to the bare necessities. For a tool, show real-world examples of how you've used it in your daily life. If you’re visually oriented, consider creating a screen-capture of an important process, such as how to install the application.
|
||||
|
||||
Travailler avec la communauté L'open source n'est qu'une partie du code. C'est la communauté qui fait fonctionner l'open source. Voici comment vous pouvez contribuer à son développement
|
||||
|
||||
13. **Répondre à une question** : La meilleure façon de contribuer à la construction de la communauté est d'aider les autres. Répondre à une question, en particulier à celle d'un débutant, est essentiel pour aider le projet à se développer et à prospérer. Le temps que vous prenez pour aider un débutant, même s'il pose une question à laquelle vous pourriez facilement répondre par un rapide "RTFM", vous permet de devenir un membre actif de la communauté. Tout le monde commence quelque part, et les projets ont besoin d'un afflux constant de personnes pour rester dynamiques.
|
||||
|
||||
14. **Rédigez un article de blog** : Si vous avez un blog, écrivez sur vos expériences avec le projet que vous utilisez. Racontez un problème que vous avez rencontré en utilisant le logiciel et ce que vous avez fait pour le résoudre. Vous apporterez une double aide, en contribuant à maintenir le projet dans l'esprit des personnes qui vous entourent et en créant une trace pour toute personne qui, à l'avenir, sera confrontée à votre problème et cherchera la réponse sur le web. (Un blog relatant vos aventures techniques est également un excellent moyen de montrer votre expérience concrète du logiciel en question la prochaine fois que vous chercherez un emploi dans ce domaine).
|
||||
15. **Améliorer un site web** : Si vous avez des compétences en conception de sites web et que vous pouvez aider à améliorer le site web, et donc l'image du projet auprès du public, c'est du temps bien utilisé. Le projet pourrait peut-être bénéficier d'une refonte graphique ou d'un logo pour l'identifier. Il s'agit peut-être de compétences qui font défaut à la communauté. Je sais que j'aimerais beaucoup avoir de l'aide en matière de conception graphique pour les sites web de mes projets.
|
||||
16. **Rédiger de la documentation technique** : Si vous pouvez écrire sur le fonctionnement d'une application ou d'un logiciel, vous pouvez rédiger de la documentation technique à son sujet. En particulier pour les projets open source qui cherchent à mettre à jour, réorganiser, développer ou créer des documents techniques destinés au grand public. Plus vous écrivez en anglais simple, mieux c'est. Le plus intéressant, c'est qu'il n'est pas nécessaire d'être programmeur pour rédiger des documents techniques.
|
||||
|
||||
Surtout, écoutez ce que disent les gens autour de vous. Voyez si vous pouvez reconnaître un besoin pressant. Par exemple, récemment, sur la liste de diffusion des développeurs de Parrot, il a été décidé d'utiliser GitHub comme système de tickets d'incident, abandonnant l'ancienne installation de Trac qu'ils avaient. Certaines personnes se sont opposées à cette décision car il n'y avait aucun moyen de convertir les tickets au système de GitHub. Après une journée de discussions, j'ai pris la parole et j'ai dit : "Et si j'écrivais un convertisseur ?". Les gens étaient ravis de l'idée. J'ai pris le temps d'écrire un programme de conversion pour les plus de 450 tickets, de sorte que nous n'avons rien perdu de l'historique de nos tickets. Ce fut un grand succès. J'ai pu apporter ma contribution, et les développeurs principaux sont restés concentrés sur leur travail sur Parrot.
|
||||
|
||||
17. **Enseigner et aider les autres** : La meilleure façon d'en savoir plus sur un sujet est d'essayer de l'enseigner. Le meilleur professeur est celui qui peut expliquer des choses complexes avec des exemples simples. Vous devez donc essayer d'être le meilleur professeur pour être le meilleur apprenant et le meilleur dans votre monde de programmation. Enseigner aux autres vous permettra de vous sentir mieux dans votre peau et vous aidera à acquérir de meilleures compétences et connaissances dans votre profession. Lorsque vous recevez de l'aide de quelqu'un, ne la gardez pas pour vous, partagez-la avec les autres. Faites du monde un endroit où il fait bon vivre.
|
||||
+123
@@ -0,0 +1,123 @@
|
||||
# Hal-hal yang dapat dilakukan oleh non Programmer
|
||||
## Mulai mendengarkan
|
||||
|
||||
Semua yang ada di open source melibatkan orang lain.
|
||||
Anda ingin bergabung dengan sebuah tim, dan itu berarti memahami komunitas dan cara kerjanya.
|
||||
Datang ke sebuah proyek dan berkata “Hai, inilah yang saya pikir harus dilakukan oleh proyek ini” biasanya tidak dianggap sebagai hal yang baik.
|
||||
Beberapa proyek mungkin akan menerima pendekatan semacam itu, tetapi jika proyek tersebut sudah berjalan cukup lama, kemungkinan sikap tersebut akan kecil.
|
||||
**Mendengarkan adalah cara terbaik untuk mengetahui apa yang dibutuhkan oleh proyek.**.
|
||||
|
||||
1. **Bergabunglah dengan milis**: Untuk banyak proyek, milis adalah saluran utama komunikasi tentang perkembangan proyek.
|
||||
Pada proyek-proyek besar, ada banyak milis yang dapat dipilih.
|
||||
Sebagai contoh, proyek PostgreSQL memiliki tidak kurang dari 12 milis berorientasi pengguna dan enam milis pengembang pada halaman milisnya.
|
||||
Saya sarankan Anda mengikuti milis berorientasi pengguna utama dan milis pengembang inti untuk mulai menyimak.
|
||||
|
||||
2. **Mengikuti sebuah blog: Blog yang dikelola oleh pengembang inti sering kali memberikan informasi tentang apa yang akan hadir di rilis mendatang,
|
||||
dan apa yang diperlukan untuk mencapainya. Situs planet mengumpulkan berita dan entri blog dari banyak sumber yang terkait dengan proyek.
|
||||
Jika ada situs planet, seperti planet.gnome.org atau planet.mysql.com, mulailah dari sana. Cari saja di Google dengan kata kunci “planet <nama proyek>.”
|
||||
|
||||
3. **Bergabunglah dengan saluran IRC**: Banyak proyek open source memiliki saluran khusus Internet relay chat (IRC) di mana para pengembang dan pengguna berkumpul untuk mendiskusikan
|
||||
|
||||
**Bekerja dengan Tiket**
|
||||
Kode adalah jantung dari setiap proyek open source, tetapi jangan berpikir bahwa menulis kode adalah satu-satunya cara untuk berkontribusi.
|
||||
Pemeliharaan kode dan sistem yang mengelilingi kode sering kali terabaikan karena terburu-buru untuk membuat fitur baru dan memperbaiki bug.
|
||||
Lihatlah area-area ini sebagai cara mudah untuk masuk ke dalam sebuah proyek.
|
||||
Sebagian besar proyek memiliki sistem tiket masalah yang dapat dilihat oleh publik, ditautkan dari halaman depan situs web proyek dan disertakan dalam dokumentasi.
|
||||
Ini adalah saluran utama komunikasi antara pengguna dan pengembang. Menjaga agar tetap mutakhir adalah cara yang bagus untuk membantu proyek.
|
||||
Anda mungkin perlu mendapatkan izin khusus dalam sistem tiket, yang sebagian besar pemimpin proyek akan dengan senang hati memberikannya kepada Anda ketika Anda mengatakan ingin membantu membersihkan tiket.
|
||||
|
||||
4. **Mendiagnosis bug**: Bug sering kali tidak dilaporkan dengan baik.
|
||||
Mendiagnosis dan melakukan triase terhadap bug dapat membantu menghemat waktu pengembang untuk mencari tahu secara spesifik masalahnya.
|
||||
Jika pengguna melaporkan, “Perangkat lunak tidak berfungsi ketika saya melakukan X,” luangkan waktu untuk mencari tahu secara spesifik apa yang menyebabkan masalah tersebut.
|
||||
Apakah masalah tersebut dapat diulang? Dapatkah Anda membuat serangkaian langkah yang menyebabkan masalah berulang kali? Dapatkah Anda mempersempit masalahnya, misalnya hanya terjadi pada satu browser tetapi tidak pada browser lainnya, atau satu distro tetapi tidak pada distro lainnya?
|
||||
|
||||
Meskipun Anda tidak tahu apa yang menyebabkan masalah, upaya yang Anda lakukan untuk mempersempit masalah akan memudahkan orang lain untuk memperbaikinya.
|
||||
Apa pun yang Anda temukan, tambahkan ke tiket di sistem bug agar semua orang dapat melihatnya.
|
||||
|
||||
5. **Tutup bug yang sudah diperbaiki**: Sering kali bug diperbaiki di basis kode tetapi tiket yang dilaporkan tidak diperbarui di sistem tiket.
|
||||
Membersihkan kesalahan ini dapat memakan waktu, tetapi sangat berharga bagi keseluruhan proyek.
|
||||
|
||||
Mulailah dengan menanyakan sistem tiket untuk tiket yang lebih tua dari satu tahun dan lihat apakah bug masih ada.
|
||||
Periksa log perubahan rilis proyek untuk melihat apakah bug telah diperbaiki dan dapat ditutup.
|
||||
Jika diketahui sudah diperbaiki, catat nomor versi di tiket dan tutup.
|
||||
|
||||
Coba buat ulang bug dengan versi terbaru perangkat lunak.
|
||||
Jika tidak dapat dibuat ulang dengan versi terbaru, catat dalam tiket dan tutup.
|
||||
Jika masih ada, catat juga di tiket dan biarkan terbuka.
|
||||
|
||||
Bekerja dengan Kode
|
||||
Programmer dari semua tingkat pengalaman dapat membantu dengan kode dalam proyek.
|
||||
Jangan berpikir bahwa Anda harus menjadi seorang jenius pengkodean untuk memberikan kontribusi nyata pada proyek favorit Anda.
|
||||
|
||||
Jika pekerjaan Anda melibatkan modifikasi kode, selidiki metode yang digunakan proyek untuk mendapatkan kode dari kontributor.
|
||||
Setiap proyek memiliki alur kerjanya sendiri, jadi tanyakan tentang cara melakukannya sebelum Anda mulai mengirimkan kode.
|
||||
|
||||
Sebagai contoh, proyek PostgreSQL sangat ketat dalam prosesnya: Modifikasi kode dikirim dalam bentuk tambalan ke milis di mana para pengembang inti meneliti setiap aspek perubahan. Di sisi lain adalah proyek seperti Parrot di mana mudah untuk mendapatkan hak komit ke basis kode. Jika proyek menggunakan GitHub, mungkin ada alur kerja yang menggunakan fitur pull request dari GitHub. Tidak ada dua proyek yang sama.
|
||||
|
||||
Setiap kali Anda memodifikasi kode, pastikan Anda bertindak sebagai anggota komunitas yang bertanggung jawab dan menjaga gaya kode Anda agar sesuai dengan basis kode lainnya. Kode yang Anda tambahkan atau modifikasi harus terlihat seperti yang lainnya. Anda mungkin tidak menyukai gaya bracing atau penanganan spasi untuk lekukan, tetapi tidak sopan untuk mengirimkan perubahan kode yang tidak sesuai dengan standar yang ada. Ini sama saja dengan mengatakan “Saya tidak suka gaya Anda, dan menurut saya gaya saya lebih baik, jadi Anda harus melakukannya dengan cara saya.”
|
||||
|
||||
6. **Menguji versi beta atau kandidat rilis**: Setiap proyek yang dirancang untuk berjalan di berbagai platform dapat memiliki berbagai macam masalah portabilitas.
|
||||
Ketika sebuah rilis mendekati dan sebuah beta atau kandidat rilis diterbitkan, pemimpin proyek berharap bahwa hal itu akan diuji oleh banyak orang yang berbeda di berbagai platform.
|
||||
Anda dapat menjadi salah satu dari orang-orang tersebut dan membantu memastikan bahwa paket tersebut bekerja pada platform Anda.
|
||||
|
||||
Biasanya Anda hanya perlu mengunduh, membangun, dan menguji perangkat lunak, tetapi nilainya bagi proyek bisa sangat besar jika Anda menggunakan distribusi atau perangkat keras yang tidak umum.
|
||||
Hanya dengan melaporkan kembali bahwa pembuatan dan pengujian telah berhasil, akan membantu para pemimpin proyek untuk mengetahui bahwa rilis yang akan datang sudah solid.
|
||||
|
||||
7. **Memperbaiki bug**: Ini biasanya merupakan tempat kontributor yang ingin mulai mengerjakan kode.
|
||||
Sederhana saja: Temukan bug yang terdengar menarik dalam sistem tiket dan coba perbaiki dalam kode.
|
||||
Dokumentasikan perbaikannya dalam kode jika sesuai.
|
||||
Sebaiknya tambahkan tes ke dalam test suite untuk menguji bagian kode yang telah Anda perbaiki; beberapa proyek memerlukan perbaikan bug untuk menyertakan tes. Buatlah catatan saat Anda mengutak-atik basis kode yang tidak Anda kenal. Bahkan jika Anda tidak dapat memperbaiki bug, dokumentasikan dalam tiket apa yang Anda temukan sebagai bagian dari upaya perbaikan. Apa yang Anda temukan akan membantu mereka yang datang setelah Anda.
|
||||
|
||||
8. **Menulis tes**: Sebagian besar proyek memiliki test suite yang menguji kode, tetapi sulit untuk membayangkan sebuah test suite yang tidak dapat menambahkan lebih banyak tes ke dalamnya.
|
||||
Gunakan alat bantu cakupan pengujian seperti gcov untuk C, atau Devel::Cover untuk Perl untuk mengidentifikasi area dalam kode sumber yang tidak diuji oleh rangkaian pengujian.
|
||||
Kemudian, tambahkan sebuah tes ke dalam rangkaian tes untuk menutupinya.
|
||||
|
||||
9. **Diamkan peringatan kompiler**: Proses build untuk banyak proyek berbasis C sering memuntahkan bendera peringatan kompiler yang aneh ke layar.
|
||||
Peringatan ini biasanya bukan merupakan indikator dari sebuah masalah, tetapi bisa terlihat seperti itu.
|
||||
Terlalu banyak peringatan dapat membuat kompiler terdengar seperti serigala yang menangis.
|
||||
Periksa untuk melihat apakah kode tersebut benar-benar menyembunyikan bug. Jika tidak, memodifikasi sumbernya untuk tidak bersuara akan membantu menyembunyikan kesalahan positif ini.
|
||||
|
||||
10. **Tambahkan komentar**:
|
||||
Ketika Anda menggali kode, Anda mungkin menemukan beberapa bagian yang membingungkan.
|
||||
Kemungkinan besar jika Anda bingung, orang lain juga akan bingung. Dokumentasikan dalam kode dan kirimkan patch.
|
||||
Bekerja dengan Dokumentasi
|
||||
Dokumentasi biasanya merupakan bagian dari sebuah proyek yang mendapat waktu singkat.
|
||||
Dokumentasi juga dapat mengalami kesulitan karena ditulis dari sudut pandang mereka yang sudah terbiasa dengan proyek tersebut, bukan dari sudut pandang seseorang yang baru saja masuk ke dalamnya.
|
||||
Jika Anda pernah membaca dokumen untuk sebuah proyek di mana Anda berpikir, “Sepertinya manual ini mengharapkan bahwa saya sudah tahu cara menggunakan paket ini,” Anda tahu apa yang saya bicarakan.
|
||||
Seringkali, satu set mata yang segar dapat menunjukkan kekurangan dalam dokumentasi yang tidak disadari oleh mereka yang dekat dengan proyek.
|
||||
|
||||
11. **Buatlah sebuah contoh**: Tidak ada proyek yang memiliki terlalu banyak contoh cara.
|
||||
Entah itu API web, pustaka rutinitas, aplikasi GUI seperti Gimp, atau alat baris perintah,
|
||||
contoh penggunaan yang baik dapat menjelaskan penggunaan perangkat lunak dengan lebih jelas dan cepat daripada halaman-halaman dokumentasi.
|
||||
Untuk API atau pustaka, buatlah contoh program yang menggunakan alat tersebut. Ini bahkan dapat diekstrak dari kode yang telah Anda tulis, dipangkas hingga ke hal-hal yang diperlukan.
|
||||
Untuk sebuah alat, tunjukkan contoh dunia nyata tentang bagaimana Anda menggunakannya dalam kehidupan sehari-hari. Jika Anda berorientasi pada visual,
|
||||
pertimbangkan untuk membuat tangkapan layar dari proses penting, seperti cara menginstal aplikasi.
|
||||
|
||||
Bekerja dengan Komunitas
|
||||
Open source hanya sebagian dari kode. Komunitaslah yang membuat open source bekerja. Berikut adalah cara-cara yang dapat Anda lakukan untuk membantu membangunnya.
|
||||
|
||||
12. **Menjawab pertanyaan**: Cara terbaik untuk membantu membangun komunitas adalah dengan membantu orang lain.
|
||||
Menjawab pertanyaan, terutama dari seseorang yang baru saja memulai, sangat penting untuk membantu proyek tumbuh dan berkembang.
|
||||
Waktu yang Anda luangkan untuk membantu seorang pemula, bahkan jika mereka mengajukan pertanyaan di mana Anda dapat dengan mudah menjawab “RTFM” dengan cepat, akan terbayar di kemudian hari dengan mendapatkan anggota aktif lainnya di dalam komunitas.
|
||||
Semua orang memulai dari suatu tempat, dan proyek membutuhkan arus masuk orang yang konstan jika ingin tetap hidup.
|
||||
|
||||
13. **Tulislah sebuah postingan blog**:
|
||||
Jika Anda memiliki sebuah blog, tulislah tentang pengalaman Anda dengan proyek yang Anda gunakan.
|
||||
Ceritakan tentang masalah yang Anda hadapi dengan menggunakan perangkat lunak dan apa yang Anda lakukan untuk menyelesaikannya.
|
||||
Anda akan membantu dengan dua cara, yaitu dengan membantu menjaga proyek tetap berada di benak orang lain di sekitar Anda,
|
||||
dan dengan membuat catatan untuk orang lain yang memiliki masalah yang sama dengan Anda di masa depan dan mencari jawabannya di web.
|
||||
(Sebuah blog tentang petualangan teknis Anda juga merupakan cara yang sangat baik untuk menunjukkan pengalaman dunia nyata dengan perangkat lunak yang bersangkutan saat Anda mencari pekerjaan dengan menggunakan perangkat lunak tersebut).
|
||||
|
||||
14. **Memperbaiki situs web**:
|
||||
Jika Anda memiliki keahlian dalam desain web dan dapat membantu meningkatkan situs web, dan dengan demikian citra proyek yang dihadapi publik, itu adalah waktu yang dihabiskan dengan baik.
|
||||
Mungkin proyek tersebut dapat menggunakan perbaikan grafis, atau logo untuk mengidentifikasi proyek.
|
||||
Hal ini mungkin merupakan keterampilan yang kurang dimiliki oleh komunitas. Saya tahu saya akan sangat senang jika saya bisa mendapatkan bantuan desain grafis di situs web proyek saya.
|
||||
|
||||
15. **Menulis dokumentasi teknis**
|
||||
Jika Anda dapat menulis tentang bagaimana sebuah aplikasi atau perangkat lunak bekerja, Anda dapat menulis dokumentasi teknis tentangnya. Terutama proyek-proyek open source yang ingin memperbarui, mengubah, memperluas, atau membuat dokumen teknis untuk dibaca oleh masyarakat umum. Semakin banyak Anda menulis dalam bahasa Inggris, semakin baik. Bagian terbaiknya, Anda tidak harus menjadi seorang programmer untuk menulis dokumen teknis.
|
||||
|
||||
Yang terpenting, dengarkan apa yang orang-orang di sekitar Anda diskusikan. Lihat apakah Anda dapat mengenali kebutuhan yang mendesak. Sebagai contoh, baru-baru ini di milis pengembang Parrot, diputuskan untuk menggunakan GitHub sebagai sistem tiket masalah, meninggalkan instalasi Trac lama yang mereka miliki. Beberapa orang menentang langkah tersebut karena tidak ada cara untuk mengubah tiket ke sistem GitHub. Setelah seharian berdebat, saya akhirnya berkata, “Bagaimana jika saya menulis konverter?” Orang-orang sangat senang dengan ide tersebut. Saya menghabiskan waktu untuk menulis program konversi untuk 450+ tiket, jadi kami tidak kehilangan riwayat tiket kami. Itu adalah sebuah kesuksesan besar. Saya bisa ikut serta, dan para pengembang inti tetap fokus pada bisnis pengerjaan Parrot.
|
||||
|
||||
16. **Mengajar dan Membantu orang lain**:
|
||||
Cara terbaik untuk mempelajari lebih lanjut tentang suatu topik adalah dengan mencoba mengajarkannya.
|
||||
Guru terbaik adalah guru yang dapat menjelaskan hal-hal yang rumit dengan contoh-contoh sederhana. Jadi, Anda perlu mencoba menjadi guru terbaik untuk menjadi pelajar terbaik dan yang terbaik di dunia pemrograman Anda. Mengajar orang lain akan membuat Anda merasa lebih baik tentang diri Anda sendiri dan akan membantu Anda mendapatkan keterampilan dan pengetahuan yang lebih baik dalam profesi Anda. Ketika Anda mendapatkan bantuan dari seseorang, jangan menyimpannya sendiri, tetapi bagikanlah dengan orang lain. Jadikan dunia tempat yang lebih baik untuk ditinggali.
|
||||
@@ -0,0 +1,124 @@
|
||||
プログラマーでなくてもできること
|
||||
聞くことから始めよう
|
||||
|
||||
オープンソースはすべて、他の人々を巻き込むことです。
|
||||
あなたはチームに加わろうとしており、それにはコミュニティとその仕組みを理解する必要があります。
|
||||
プロジェクトに参加して「こんにちは、このプロジェクトにはこうしたほうがいいと思います」と言うのは、通常あまり歓迎されません。
|
||||
一部のプロジェクトではそのようなアプローチを歓迎するかもしれませんが、長く続いているプロジェクトでは、その考え方はあまり受け入れられません。
|
||||
プロジェクトのニーズを理解するには、まず聞くことが最も重要です。
|
||||
|
||||
1. メーリングリストに参加する
|
||||
|
||||
多くのプロジェクトでは、メーリングリストが開発に関する主なコミュニケーション手段となっています。
|
||||
大規模なプロジェクトには、複数のメーリングリストがあります。
|
||||
たとえば、PostgreSQLプロジェクトには、少なくとも12のユーザー向けリストと6つの開発者リストがあります。
|
||||
主要なユーザー向けと開発者向けリストをフォローし、まずは「聞くこと」から始めましょう。
|
||||
2. ブログをフォローする
|
||||
|
||||
主要な開発者が運営しているブログでは、今後のリリースや現在進行中の作業についての情報が得られます。
|
||||
Planetサイトは、関連する複数のニュースソースやブログ投稿を一か所でまとめて表示します。
|
||||
たとえば planet.gnome.org や planet.mysql.com のようなサイトがそうです。
|
||||
Googleで「Planet <プロジェクト名>」と検索してみましょう。
|
||||
|
||||
3. IRCチャンネルに参加する
|
||||
|
||||
多くのオープンソースプロジェクトにはIRC（インターネットリレーチャット）チャンネルがあり、開発者やユーザーが問題や開発について話し合っています。
|
||||
プロジェクトのWebサイトで、チャンネル名や使用しているIRCネットワークを確認しましょう。
|
||||
チケットを使った作業
|
||||
|
||||
コードはオープンソースプロジェクトの中心ですが、貢献方法はそれだけではありません。
|
||||
コードの周囲のシステムの保守は、新機能の追加やバグ修正の際に見過ごされがちです。
|
||||
こうした分野に関わることは、プロジェクトへの入り口となります。
|
||||
多くのプロジェクトには、公開されているトラブルチケットシステムがあり、公式Webサイトのトップページやドキュメントからリンクされています。
|
||||
これはユーザーと開発者間の主なコミュニケーション手段です。これを最新に保つことは、大きな貢献となります。
|
||||
一部の操作には特別な権限が必要ですが、多くのプロジェクトリーダーは喜んで協力してくれます。
|
||||
|
||||
4. バグの診断
|
||||
|
||||
バグはしばしば不正確に報告されます。
|
||||
バグを診断して説明することは、開発者が問題の原因を特定する助けになります。
|
||||
たとえば「Xをしたときにソフトが動かない」と報告された場合、再現できるか確認しましょう。
|
||||
特定のブラウザでのみ発生するのか、特定のディストリビューションでのみ発生するのかを絞り込むことが重要です。
|
||||
原因が分からなくても、可能な限り情報を絞り込むことで他の人が修正しやすくなります。
|
||||
見つけたことはすべてチケットに記録しましょう。
|
||||
|
||||
5. 修正されたバグを閉じる
|
||||
|
||||
バグがコードで修正されても、チケットが更新されていないことがあります。
|
||||
このような「ごみ」を掃除するのは時間がかかりますが、プロジェクト全体にとっては非常に重要です。
|
||||
1年以上前のチケットを検索し、バグがまだ存在するか確認してください。
|
||||
リリースの変更ログを確認し、修正されたことが明らかであればチケットを閉じてください。
|
||||
バグが再現できなければそれを記録し、閉じます。再現できれば、続けてオープンにしておきます。
|
||||
コードを使った作業
|
||||
|
||||
経験レベルに関係なく、誰でもコードで貢献できます。
|
||||
貢献するために天才である必要はありません。
|
||||
コードの修正を行う場合は、そのプロジェクトがどのようにコードを受け入れているか確認してください。
|
||||
各プロジェクトには独自のワークフローがあります。
|
||||
たとえば PostgreSQL ではパッチをメーリングリストに送る厳格なルールがありますが、Parrot のようなプロジェクトではもっと簡単です。
|
||||
GitHubを使用している場合は、Pull Requestを通じて貢献できます。
|
||||
修正時は、既存のコードスタイルに従い、責任あるメンバーとして行動してください。
|
||||
|
||||
6. ベータ版やリリース候補版をテストする
|
||||
|
||||
さまざまな環境で動作するソフトウェアには、移植性に関する問題が多く存在します。
|
||||
リリース前にベータ版やRC版が公開された際は、異なる環境でのテストが期待されます。
|
||||
あなたもその一員となり、自分の環境でビルド・実行・テストをして、動作報告を送りましょう。
|
||||
|
||||
7. バグを修正する
|
||||
|
||||
これはコードに貢献したい人のための一般的な方法です。
|
||||
チケットシステムから興味のあるバグを探し、修正に挑戦してください。
|
||||
テストが必要であれば、それも追加しましょう。
|
||||
修正できなかった場合でも、調査内容を記録することが次の人の助けになります。
|
||||
|
||||
8. テストを書く
|
||||
|
||||
ほとんどのプロジェクトにはテストスイートがありますが、十分にカバーされていないこともあります。
|
||||
テストカバレッジツールを使用して未カバー部分を探し、そこに対するテストを追加しましょう。
|
||||
|
||||
9. コンパイラ警告を修正する
|
||||
|
||||
多くのC系プロジェクトでは、ビルド時に警告が出ます。
|
||||
それらの多くは深刻な問題ではありませんが、見た目が悪く、重要な警告を埋もれさせてしまうことがあります。
|
||||
警告を解消するためのコード変更は、プロジェクトにとって役立ちます。
|
||||
|
||||
10. コメントを追加する
|
||||
|
||||
コードを読む中で混乱する箇所があれば、他の人も同じように困る可能性があります。
|
||||
そこにコメントを追加し、パッチとして提出しましょう。
|
||||
ドキュメントで貢献する
|
||||
|
||||
ドキュメントはしばしば軽視されがちであり、経験者の視点で書かれていることが多いため、初心者にはわかりにくいことがあります。
|
||||
新しい視点から欠点を見つけ、改善することができます。
|
||||
|
||||
11. 使用例を作成する
|
||||
|
||||
どんなプロジェクトでも、How-toの使用例は歓迎されます。
|
||||
API、GUIアプリ、CLIツールなど、実用的な例を作りましょう。
|
||||
セットアップ手順のスクリーンショットを追加するのも良いアイデアです。
|
||||
コミュニティとの関わり方
|
||||
|
||||
オープンソースはコードだけではありません。コミュニティこそがそれを支える柱です。
|
||||
|
||||
12. 質問に答える
|
||||
|
||||
他人を助けることは、コミュニティを強くする最高の方法です。
|
||||
特に初心者の質問に親切に答えることで、活発な参加者が増え、プロジェクトの将来が明るくなります。
|
||||
|
||||
13. ブログ投稿を書く
|
||||
|
||||
使っているソフトウェアに関して、経験や問題・解決策を書いてください。
|
||||
他のユーザーが同様の問題に直面したとき、あなたのブログが役立つかもしれません。
|
||||
また、将来そのソフトを使って職探しをする際の実績としても使えます。
|
||||
|
||||
14. Webサイトを改善する
|
||||
|
||||
もしWebデザインのスキルがあれば、プロジェクトのWebサイトを改善することで貢献できます。
|
||||
新しいロゴやバナー、レイアウトの改善など、あなたのスキルが生かされる場面は多くあります。
|
||||
|
||||
最も重要なのは、周囲の人々がどんな話をしているのか、耳を傾けることです。
|
||||
必要なものに気づき、積極的に提案・行動することで、大きなインパクトを残すことができます。
|
||||
|
||||
たとえば、Parrotの開発者がTracからGitHubへチケットを移行するか議論していた際、
|
||||
「コンバーターを書きましょうか？」と申し出たことで、450以上のチケットを失わずに済み、大きな成功となりました。
|
||||
+64
@@ -0,0 +1,64 @@
|
||||
|
||||
# ಓಪನ್ ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ಗಳಿಗೆ ಹೇಗೆ ಕೊಡುಗೆ ನೀಡುವುದು: ಆರಂಭಿಕರಿಗಾಗಿ ಸಂಪೂರ್ಣ ಮಾರ್ಗದರ್ಶಿ
|
||||
|
||||
**ಸಂಕ್ಷಿಪ್ತವಾಗಿ:** ನೀವು ನಿಮ್ಮ ಮೊದಲ Pull Request ಅನ್ನು ಒಂದು ಓಪನ್ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ಗೆ ಸಲ್ಲಿಸಲು ಕಾತರರಾಗಿದ್ದರೆ, ಈ ಸೂಚನೆಗಳನ್ನು ಅನುಸರಿಸಿ: [Readme](https://github.com/firstcontributions/first-contributions)
|
||||
|
||||
ಓಪನ್ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ಗಳಿಗೆ ಕೊಡುಗೆ ನೀಡುವುದು ಒಬ್ಬ ಪ್ರೋಗ್ರಾಮರ್ ಆಗಿ ಬೆಳೆಯಲು, ನಿಮ್ಮ ಪೋರ್ಟ್ಫೋಲಿಯೋವನ್ನು ನಿರ್ಮಿಸಲು ಮತ್ತು ಸಮುದಾಯಕ್ಕೆ ಹಿಂದಿರುಗಿಸಲು ಅತ್ಯುತ್ತಮ ಮಾರ್ಗಗಳಲ್ಲಿ ಒಂದು. ನೀವು ಅನುಭವಸಂಪನ್ನ ಪ್ರೋಗ್ರಾಮರ್ ಆಗಿರಲಿ ಅಥವಾ ಪ್ರಾರಂಭದಲ್ಲೇ ಇರಲಿ, ಓಪನ್ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ಗಳು ಕಲಿಯಲು, ಸಹಕರಿಸಲು ಮತ್ತು ಸಕಾರಾತ್ಮಕ ಪರಿಣಾಮವನ್ನುಂಟುಮಾಡಲು ಹಲವಾರು ಅವಕಾಶಗಳನ್ನು ಒದಗಿಸುತ್ತವೆ. ಈ ಮಾರ್ಗದರ್ಶಿಯಲ್ಲಿ, ಸರಿಯಾದ ಪ್ರಾಜೆಕ್ಟ್ನ್ನು ಹುಡುಕುವುದರಿಂದ ಹಿಡಿದು ನಿಮ್ಮ ಮೊದಲ ಕೊಡುಗೆಯನ್ನು ನೀಡುವವರೆಗಿನ ಎಲ್ಲಾ ಹಂತಗಳನ್ನು ನೋಡೋಣ.
|
||||
|
||||
## ಏಕೆ ಓಪನ್ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ಗಳಿಗೆ ಕೊಡುಗೆ ನೀಡಬೇಕು?
|
||||
|
||||
"ಹೇಗೆ" ಎಂಬುದರ ಮೊದಲು, "ಏಕೆ" ಎಂಬುದನ್ನು ತಿಳಿಯೋಣ:
|
||||
|
||||
* **ಕೌಶಲ್ಯ ಅಭಿವೃದ್ಧಿ:** ನೈಜ ಪ್ರಾಜೆಕ್ಟ್ಗಳ ಕೋಡ್ಗಳನ್ನು ನೋಡಿ ಕಲಿಯುವ ಮೂಲಕ ನಿಮ್ಮ ಪ್ರೋಗ್ರಾಮಿಂಗ್, ಡಿಬಗ್ಗಿಂಗ್ ಮತ್ತು ಸಹಕಾರದ ಕೌಶಲ್ಯಗಳು ಬೆಳೆಯುತ್ತವೆ.
|
||||
* **ಪೋರ್ಟ್ಫೋಲಿಯೋ ನಿರ್ಮಾಣ:** ಪ್ರಸಿದ್ಧ ಪ್ರಾಜೆಕ್ಟ್ಗಳಲ್ಲಿ ಕೊಡುಗೆ ನೀಡುವುದು ನಿಮ್ಮ CV ಮತ್ತು GitHub ಪ್ರೊಫೈಲ್ ಅನ್ನು ಬಲಪಡಿಸುತ್ತದೆ.
|
||||
* **ನೆಟ್ವರ್ಕಿಂಗ್:** ಜಗತ್ತಿನಾದ್ಯಂತದ ಡೆವಲಪರ್ಗಳ ಜೊತೆ ಸಂಪರ್ಕ ಬೆಳೆಸಿ, ತಜ್ಞರಿಂದ ಕಲಿಯಿರಿ ಮತ್ತು ಸಮುದಾಯದ ಭಾಗವಾಗಿರಿ.
|
||||
* **ಹಿಂದಿರುಗಿಸುವುದು:** ನಾವು ಪ್ರತಿದಿನ ಬಳಸುವ ಅನೇಕ ಸಾಫ್ಟ್ವೇರ್ಗಳ ಆಧಾರ ಓಪನ್ಸೋರ್ಸ್ ಆಗಿದೆ. ಕೊಡುಗೆ ನೀಡುವುದು ಧನ್ಯವಾದ ಹೇಳುವ ಮಾರ್ಗ.
|
||||
* **ವೃತ್ತಿ ಅವಕಾಶಗಳು:** ಅನೇಕ ಕಂಪನಿಗಳು ಓಪನ್ಸೋರ್ಸ್ ಅನುಭವ ಹೊಂದಿರುವ ಡೆವಲಪರ್ಗಳನ್ನು ಹುಡುಕುತ್ತವೆ ಏಕೆಂದರೆ ಇದು ಪ್ರೊಆಕ್ಟಿವಿಟಿ ಮತ್ತು ತಂಡದ ಕೆಲಸವನ್ನು ತೋರಿಸುತ್ತದೆ.
|
||||
|
||||
## ಹೇಗೆ ಪ್ರಾರಂಭಿಸಬೇಕು?
|
||||
|
||||
### 1. ಸರಿಯಾದ ಪ್ರಾಜೆಕ್ಟ್ ಆಯ್ಕೆಮಾಡಿ
|
||||
|
||||
ನಿಮ್ಮ ಆಸಕ್ತಿಗಳು ಮತ್ತು ಕೌಶಲ್ಯಗಳಿಗೆ ಹೊಂದಿಕೊಳ್ಳುವ ಪ್ರಾಜೆಕ್ಟ್ಗಳನ್ನು ಆರಿಸಿ:
|
||||
|
||||
* **GitHub ಅನ್ವೇಷಿಸಿ:** `good-first-issue`, `help-wanted` ಮುಂತಾದ ಲೇಬಲ್ಗಳಿರುವ ಟಾಸ್ಕ್ಗಳನ್ನು ಹುಡುಕಿ.
|
||||
* **ಪ್ರೋಗ್ರಾಂಗಳಲ್ಲಿ ಭಾಗವಹಿಸಿ:** Google Summer of Code, Hacktoberfest ಮುಂತಾದವು ಉತ್ತಮ ಅವಕಾಶಗಳು.
|
||||
* **ನೀವು ಬಳಸುವ ಉಪಕರಣಗಳು:** ನೀವು ಬಳಸುವ ಲೈಬ್ರರಿ ಅಥವಾ ಫ್ರೇಮ್ವರ್ಕ್ಗಳಲ್ಲಿ ಕೊಡುಗೆ ನೀಡಿ.
|
||||
|
||||
### 2. ಪ್ರಾಜೆಕ್ಟ್ನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ
|
||||
|
||||
* **ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಓದಿ:** README ಮತ್ತು ಕೊಡುಗೆ ಮಾರ್ಗಸೂಚಿಗಳನ್ನು ಗಮನಿಸಿ.
|
||||
* **ಕೋಡ್ನ್ನು ಅಧ್ಯಯನ ಮಾಡಿ:** ಪ್ರಾಜೆಕ್ಟ್ನ ರಚನೆ ಮತ್ತು ಕೋಡಿಂಗ್ ಶೈಲಿಯನ್ನು ತಿಳಿದುಕೊಳ್ಳಿ.
|
||||
* **ಸಮುದಾಯಕ್ಕೆ ಸೇರಿ:** Slack, Discord ಅಥವಾ ಫೋರಮ್ಗಳಲ್ಲಿ ಚರ್ಚೆಗಳಲ್ಲಿ ಭಾಗವಹಿಸಿ.
|
||||
|
||||
### 3. ಚಿಕ್ಕ ಹಂತಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ
|
||||
|
||||
* **ಬಗ್ಗಳನ್ನು ಸರಿಪಡಿಸಿ:** ಆರಂಭಿಕರಿಗೆ ಅನುಕೂಲಕರವಾದ issues ಹುಡುಕಿ.
|
||||
* **ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಸುಧಾರಿಸಿ:** ಬಹಳ ಉಪಯುಕ್ತವಾದರೂ ಹೆಚ್ಚಾಗಿ ಗಮನಿಸದೆ ಬಿಡಲಾಗುತ್ತದೆ.
|
||||
* **ಟೆಸ್ಟ್ಗಳನ್ನು ಬರೆಯಿರಿ:** ಕೋಡ್ ತಿಳಿಯಲು ಉತ್ತಮ ವಿಧಾನ.
|
||||
|
||||
### 4. ಉತ್ತಮ ಅಭ್ಯಾಸಗಳನ್ನು ಅನುಸರಿಸಿ
|
||||
|
||||
* **Fork ಮತ್ತು Clone ಮಾಡಿ**
|
||||
* **ಪ್ರತ್ಯೇಕ branch ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ**
|
||||
* **ಸ್ವಚ್ಛ ಕೋಡ್ ಬರೆಯಿರಿ**
|
||||
* **ನಿಮ್ಮ ಬದಲಾವಣೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ**
|
||||
* **Pull Request ಕಳುಹಿಸಿ:** ಸ್ಪಷ್ಟ ವಿವರಣೆ ನೀಡಿ, ಸಂಬಂಧಿತ issueಗಳನ್ನು ಉಲ್ಲೇಖಿಸಿ ಮತ್ತು feedback ಸ್ವೀಕರಿಸಲು ತೆರೆದಿರಲಿ.
|
||||
|
||||
## ಯಶಸ್ಸಿಗೆ ಸಲಹೆಗಳು
|
||||
|
||||
* **ಸಮರ್ಪಕ ಸಂವಹನ ಮಾಡಿ:** ಗೌರವಪೂರ್ವಕವಾಗಿ ವರ್ತಿಸಿ ಮತ್ತು ಸ್ಪಷ್ಟವಾಗಿ ಪ್ರಶ್ನೆ ಮಾಡಿ.
|
||||
* **ಸ್ಥಿರತೆಯಿಂದಿರಿ:** ಸಣ್ಣ ಕೊಡುಗೆಗಳೂ ಸಮಯದೊಂದಿಗೆ ದೊಡ್ಡ ಪರಿಣಾಮ ಬೀರುತ್ತವೆ.
|
||||
* **ಫೀಡ್ಬ್ಯಾಕ್ನಿಂದ ಕಲಿಯಿರಿ:** ಕೋಡ್ ರಿವ್ಯೂ ಒಳ್ಳೆಯ ಕಲಿಕೆಯ ಅವಕಾಶ.
|
||||
* **ಇತರರಿಗೆ ಸಹಾಯ ಮಾಡಿ:** ನೀವು ಅನುಭವ ಹೊಂದಿದ ಮೇಲೆ ಹೊಸಬರಿಗೆ ಮಾರ್ಗದರ್ಶನ ನೀಡಿ.
|
||||
|
||||
## ಸಾಮಾನ್ಯ ಸವಾಲುಗಳು ಮತ್ತು ಪರಿಹಾರಗಳು
|
||||
|
||||
* **Impostor Syndrome:** ಚಿಕ್ಕ ಕೊಡುಗೆಗಳೂ ಮುಖ್ಯ. ಎಲ್ಲರೂ ಎಲ್ಲಿಂದೋ ಆರಂಭಿಸಿದ್ದಾರೆ.
|
||||
* **ಸಮಯದ ಕೊರತೆ:** ಸಣ್ಣ ಟಾಸ್ಕ್ಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ. ವಾರಕ್ಕೆ 30 ನಿಮಿಷ ಕೂಡ ಸಾಕು.
|
||||
* **ದೊಡ್ಡ ಕೋಡ್ಬೇಸ್ ಅನ್ನು ನಾವಿಗೇಟ್ ಮಾಡುವುದು:** ಒಂದೊಂದೇ ಘಟಕ concentrate ಮಾಡಿ, documentation ಓದಿ, ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಿ.
|
||||
|
||||
## ಸಮಾರೋಪ
|
||||
|
||||
ಓಪನ್ಸೋರ್ಸ್ಗೆ ಕೊಡುಗೆ ನೀಡುವುದು ವೈಯಕ್ತಿಕ ಮತ್ತು ವೃತ್ತಿಪರ ಬೆಳವಣಿಗೆಗೆ ದೊಡ್ಡ ಅವಕಾಶ. ಸಣ್ಣ ಹಂತಗಳಿಂದ ಆರಂಭಿಸಿ, ನಿಯಮಿತವಾಗಿರಿ, ಸಮುದಾಯದೊಂದಿಗೆ ಸಂವಹನ ಮಾಡಿ — ಹೀಗೆ ನಿಮ್ಮ ಕೌಶಲ್ಯಗಳನ್ನು ಬೆಳೆಸುತ್ತಾ ಪರಿಣಾಮಕಾರಿ ಕೊಡುಗೆಗಳನ್ನು ನೀಡಬಹುದು. ಪ್ರತಿಯೊಂದು ಕೊಡುಗೆಯೂ ಮಹತ್ವದ್ದೇ. ಇಂದೇ ಪ್ರಾರಂಭಿಸಿ — ನಿಮಗೆ ಇಷ್ಟವಾದ ಪ್ರಾಜೆಕ್ಟ್ ಹುಡುಕಿ, ಮೊದಲ ಕೊಡುಗೆ ನೀಡಿ ಮತ್ತು ಜಾಗತಿಕ ಓಪನ್ಸೋರ್ಸ್ ಚಳುವಳಿಯ ಭಾಗವಾಗಿರಿ!
|
||||
|
||||
@@ -0,0 +1,81 @@
|
||||
## 오픈소스 프로젝트는 프로그래머만 기여할 수 있는 것이 아닙니다. 코딩 실력이 없어도 오픈소스 프로젝트에 참여하고 기여할 수 있는 다양한 방법들이 있습니다.
|
||||
|
||||
## 경청하기
|
||||
|
||||
오픈소스의 모든 것은 다른 사람들과의 상호작용을 포함합니다. 여러분은 팀에 합류하려는 것이므로, 커뮤니티와 그 작동 방식을 이해하는 것이 중요합니다. 프로젝트에 불쑥 끼어들어 "안녕하세요, 이 프로젝트는 이렇게 해야 한다고 생각합니다"라고 말하는 것은 일반적으로 좋게 받아들여지지 않습니다. 그런 접근 방식을 환영하는 프로젝트도 있겠지만, 프로젝트가 오랫동안 진행되어 온 경우 그러한 태도가 받아들여질 가능성은 적습니다.
|
||||
**경청하는 것이 프로젝트에 필요한 것을 아는 가장 좋은 방법입니다.**
|
||||
|
||||
1. **메일링 리스트 가입하기**: 많은 프로젝트에서 메일링 리스트는 프로젝트 개발에 대한 주요 커뮤니케이션 수단입니다. 대규모 프로젝트에는 선택할 수 있는 메일링 리스트가 많습니다. 예를 들어, PostgreSQL 프로젝트는 메일링 리스트 페이지에 사용자 중심 리스트 12개 이상과 개발자 리스트 6개를 보유하고 있습니다. 시작하려면 주요 사용자 중심 리스트와 핵심 개발자 리스트를 팔로우하여 경청하는 것을 추천합니다.
|
||||
|
||||
2. **블로그 팔로우하기**: 핵심 개발자들이 운영하는 블로그는 종종 향후 릴리스에 대한 정보와 그 과정에 대한 정보를 제공합니다. 플래닛 사이트는 프로젝트와 관련된 여러 출처의 뉴스 및 블로그 게시물을 모아 보여줍니다. planet.gnome.org나 planet.mysql.com과 같은 플래닛 사이트가 있다면 거기서부터 시작하세요. Google에서 "planet <프로젝트 이름>"으로 검색해보세요.
|
||||
|
||||
3. **IRC 채널 가입하기**: 많은 오픈소스 프로젝트에는 개발자와 사용자가 문제 및 개발에 대해 논의하는 전용 IRC(Internet Relay Chat) 채널이 있습니다. 프로젝트 웹사이트에서 채널 이름과 IRC 네트워크 세부 정보를 확인하세요.
|
||||
|
||||
|
||||
## 티켓 작업하기
|
||||
|
||||
코드는 모든 오픈소스 프로젝트의 핵심이지만, 코드를 작성하는 것만이 기여하는 유일한 방법이라고 생각하지 마세요. 코드 유지 보수 및 코드를 둘러싼 시스템은 새로운 기능을 만들고 버그를 수정하는 데 급급하여 종종 소홀히 다루어집니다. 이러한 영역을 프로젝트에 발을 들여놓을 수 있는 쉬운 방법으로 살펴보세요. 대부분의 프로젝트에는 프로젝트 웹사이트 첫 페이지에 링크되어 있고 문서에 포함된 공개적으로 볼 수 있는 문제 티켓 시스템이 있습니다. 이는 사용자와 개발자 간의 주요 커뮤니케이션 수단입니다. 이를 최신 상태로 유지하는 것은 프로젝트를 돕는 좋은 방법입니다. 티켓 시스템에서 특별한 권한을 얻어야 할 수도 있는데, 대부분의 프로젝트 리더는 티켓 정리를 돕고 싶다고 말하면 기꺼이 권한을 부여할 것입니다.
|
||||
|
||||
4. **버그 진단하기**: 버그는 종종 제대로 보고되지 않습니다.
|
||||
버그를 진단하고 분류하는 것은 개발자가 문제의 세부 사항을 파악하는 데 드는 수고를 덜어줄 수 있습니다. 사용자가 "X를 하면 소프트웨어가 작동하지 않습니다"라고 보고했다면, 그 문제의 구체적인 내용이 무엇인지 파악하는 데 시간을 투자하세요. 반복 가능한가요? 문제를 반복적으로 발생시킬 수 있는 일련의 단계를 만들 수 있나요? 특정 브라우저에서만 발생하거나 특정 배포판에서만 발생하는 등 문제를 좁힐 수 있나요?
|
||||
|
||||
문제의 원인을 모르더라도, 상황을 좁히기 위해 기울인 노력은 다른 사람이 문제를 해결하는 것을 더 쉽게 만듭니다. 발견한 모든 것을 모든 사람이 볼 수 있도록 버그 시스템의 티켓에 추가하세요.
|
||||
|
||||
5. **수정된 버그 닫기**: 종종 버그는 코드베이스에서 수정되지만, 이에 대해 보고된 티켓은 티켓 시스템에서 업데이트되지 않습니다. 이러한 불필요한 것들을 정리하는 것은 시간이 많이 걸릴 수 있지만, 전체 프로젝트에 매우 중요합니다.
|
||||
|
||||
먼저 1년 이상 된 티켓을 티켓 시스템에서 쿼리하여 버그가 여전히 존재하는지 확인하세요. 프로젝트의 릴리스 변경 로그를 확인하여 버그가 수정되었고 닫을 수 있는지 확인하세요. 수정된 것으로 알려져 있다면 티켓에 버전 번호를 기록하고 닫으세요.
|
||||
|
||||
소프트웨어의 최신 버전으로 버그를 재현해보세요. 최신 버전으로 재현할 수 없다면 티켓에 기록하고 닫으세요. 여전히 존재한다면 티켓에 기록하고 열어 두세요.
|
||||
|
||||
|
||||
|
||||
## 코드 작업하기
|
||||
|
||||
모든 경험 수준의 프로그래머가 프로젝트의 코드를 도울 수 있습니다. 좋아하는 프로젝트에 실질적인 기여를 하기 위해 코딩 천재가 되어야 한다고 생각하지 마세요.
|
||||
|
||||
작업에 코드 수정이 포함된다면, 프로젝트가 기여자로부터 코드를 받는 데 사용하는 방법을 조사하세요. 각 프로젝트마다 고유한 워크플로우가 있으므로, 코드를 제출하기 전에 어떻게 해야 하는지 물어보세요.
|
||||
|
||||
예를 들어, PostgreSQL 프로젝트는 매우 엄격한 프로세스를 따릅니다. 코드 수정은 핵심 개발자들이 변경 사항의 모든 측면을 면밀히 조사하는 메일링 리스트에 패치 형태로 전송됩니다. 반대편에는 Parrot과 같이 코드베이스에 커밋 권한을 쉽게 얻을 수 있는 프로젝트도 있습니다. 프로젝트가 GitHub를 사용하는 경우, GitHub의 풀 리퀘스트 기능을 사용하는 워크플로우가 있을 수 있습니다. 어떤 프로젝트도 똑같지 않습니다.
|
||||
|
||||
코드를 수정할 때마다 커뮤니티의 책임 있는 구성원으로서 행동하고 코드 스타일을 나머지 코드베이스와 일치시키도록 하세요. 추가하거나 수정하는 코드는 다른 코드와 같아야 합니다. 중괄호 스타일이나 들여쓰기를 위한 공백 처리가 마음에 들지 않을 수도 있지만, 기존 표준과 일치하지 않는 코드 변경을 제출하는 것은 무례한 행동입니다. 이는 "당신의 스타일이 마음에 들지 않고 내 스타일이 더 낫다고 생각하므로 내 방식대로 해야 합니다"라고 말하는 것과 같습니다.
|
||||
|
||||
6. **베타 또는 릴리스 후보 테스트하기**: 여러 플랫폼에서 실행되도록 설계된 모든 프로젝트는 온갖 종류의 이식성 문제를 겪을 수 있습니다. 릴리스가 다가오고 베타 또는 릴리스 후보가 게시되면 프로젝트 리더는 많은 다른 사람들이 많은 다른 플랫폼에서 테스트하기를 바랍니다. 여러분은 그 사람들 중 한 명이 되어 패키지가 자신의 플랫폼에서 작동하는지 확인하는 데 도움을 줄 수 있습니다.
|
||||
|
||||
일반적으로 소프트웨어를 다운로드, 빌드 및 테스트하기만 하면 되지만, 흔하지 않은 배포판이나 하드웨어를 사용하고 있다면 프로젝트에 엄청난 가치를 제공할 수 있습니다. 빌드 및 테스트가 작동한다고 보고하는 것만으로도 프로젝트 리더는 임박한 릴리스가 견고하다는 것을 알 수 있습니다.
|
||||
|
||||
|
||||
7. **버그 수정하기**: 이것은 일반적으로 코드 작업을 시작하려는 기여자들의 시작점입니다. 간단합니다. 티켓 시스템에서 흥미롭게 들리는 버그를 찾아 코드에서 수정하려고 시도하세요. 적절하다면 코드에 수정 사항을 문서화하세요. 수정한 코드 부분을 테스트하기 위해 테스트 스위트에 테스트를 추가하는 것이 좋습니다. 일부 프로젝트에서는 버그 수정에 테스트를 포함하도록 요구합니다. 이 익숙하지 않은 코드베이스를 살펴보면서 메모를 계속 작성하세요. 버그를 수정할 수 없더라도 수정 시도의 일환으로 발견한 내용을 티켓에 문서화하세요. 여러분이 발견한 내용은 다음에 오는 사람들에게 도움이 됩니다.
|
||||
|
||||
|
||||
8. **테스트 작성하기**: 대부분의 프로젝트에는 코드를 테스트하는 테스트 스위트가 있지만, 더 많은 테스트를 추가할 수 없는 테스트 스위트는 상상하기 어렵습니다. C 언어용 gcov 또는 Perl용 Devel::Cover와 같은 테스트 커버리지 도구를 사용하여 테스트 스위트에서 테스트되지 않는 소스 코드 영역을 식별하세요. 그런 다음, 테스트를 스위트에 추가하여 해당 영역을 커버하세요.
|
||||
|
||||
|
||||
9. **컴파일러 경고 잠재우기**: 많은 C 기반 프로젝트의 빌드 프로세스는 종종 이상한 컴파일러 경고 플래그를 화면에 뿜어냅니다. 이러한 경고는 일반적으로 문제의 지표는 아니지만 그렇게 보일 수 있습니다. 너무 많은 경고는 컴파일러가 거짓 경고를 하는 것처럼 들리게 할 수 있습니다. 코드가 실제로 버그를 숨기고 있는지 확인하세요. 그렇지 않다면, 소스를 수정하여 잠재우는 것은 이러한 오탐을 숨기는 데 도움이 됩니다.
|
||||
|
||||
|
||||
10. **주석 추가하기**: 코드를 살펴보는 동안 혼란스러운 부분이 있을 수 있습니다. 여러분이 혼란스러웠다면 다른 사람들도 마찬가지일 가능성이 높습니다. 코드에 문서화하고 패치를 제출하세요.
|
||||
|
||||
|
||||
## 문서 작업하기
|
||||
|
||||
문서는 일반적으로 프로젝트에서 소홀히 다루어지는 부분입니다. 또한 프로젝트에 익숙한 사람들의 관점에서 작성되어, 막 시작하는 사람의 관점이 아닌 경우도 있습니다. "이 매뉴얼은 내가 이미 이 패키지를 사용하는 방법을 알고 있다고 기대하는 것 같아"라고 생각한 적이 있다면 제가 무슨 말을 하는지 아실 겁니다. 종종 새로운 시선은 프로젝트와 가까운 사람들이 알아차리지 못하는 문서의 결함을 지적할 수 있습니다.
|
||||
|
||||
11. **예시 만들기**: 예시가 너무 많은 프로젝트는 없습니다. 웹 API든, 루틴 라이브러리든, Gimp와 같은 GUI 앱이든, 명령줄 도구든, 올바른 사용법에 대한 좋은 예시는 수백 페이지의 문서보다 더 명확하고 빠르게 소프트웨어의 올바른 사용법을 설명할 수 있습니다. API나 라이브러리의 경우, 도구를 사용하는 예시 프로그램을 만드세요. 이는 여러분이 작성한 코드에서 최소한의 필수적인 부분만 추출하여 만들 수도 있습니다. 도구의 경우, 일상생활에서 어떻게 사용했는지에 대한 실제 사례를 보여주세요. 시각적인 것을 선호한다면, 애플리케이션 설치 방법과 같은 중요한 프로세스의 화면 캡처를 만드는 것을 고려해 보세요.
|
||||
|
||||
|
||||
|
||||
## 커뮤니티와 함께 작업하기
|
||||
|
||||
오픈소스는 코드에 관한 것만이 아닙니다. 커뮤니티가 오픈소스가 작동하도록 만듭니다. 커뮤니티를 구축하는 데 도움을 줄 수 있는 방법은 다음과 같습니다.
|
||||
|
||||
12. **질문에 답하기**: 커뮤니티를 구축하는 가장 좋은 방법은 다른 사람들을 돕는 것입니다. 특히 막 시작하는 사람들의 질문에 답하는 것은 프로젝트가 성장하고 번성하는 데 매우 중요합니다. 초보자를 돕는 데 시간을 투자하는 것은, 비록 "RTFM(매뉴얼을 읽으세요)"이라고 간단히 대답할 수 있는 질문일지라도, 나중에 또 다른 활발한 커뮤니티 구성원을 얻는 데 도움이 됩니다. 모든 사람은 어디서든 시작하며, 프로젝트는 활력을 유지하려면 꾸준한 인력 유입이 필요합니다.
|
||||
|
||||
13. **블로그 게시물 작성하기**: 블로그가 있다면, 사용하고 있는 프로젝트에 대한 경험에 대해 글을 써보세요. 소프트웨어를 사용하면서 직면했던 문제와 그것을 해결하기 위해 무엇을 했는지 이야기해 주세요. 이렇게 하면 두 가지 방식으로 도움이 됩니다. 하나는 프로젝트를 주변 사람들의 마음에 계속 각인시키는 데 도움이 되고, 다른 하나는 미래에 여러분과 같은 문제를 겪고 웹에서 해결책을 검색하는 모든 사람을 위한 기록을 만드는 데 도움이 됩니다. (기술적인 모험에 대한 블로그는 나중에 해당 소프트웨어를 사용하는 직업을 찾을 때 실제 경험을 보여주는 훌륭한 방법이기도 합니다.)
|
||||
|
||||
14. **웹사이트 개선하기**: 웹 디자인 기술이 있고 웹사이트를 개선하여 프로젝트의 대중적인 이미지를 향상시킬 수 있다면, 이는 잘 보낸 시간입니다. 아마도 프로젝트는 그래픽 전면 개편이나 프로젝트를 식별할 로고가 필요할 수도 있습니다. 이러한 기술은 커뮤니티에 부족할 수 있습니다. 저도 제 프로젝트 웹사이트에 그래픽 디자인 지원을 받을 수 있다면 좋을 것 같습니다.
|
||||
|
||||
15. **기술 문서 작성하기**: 애플리케이션이나 소프트웨어가 어떻게 작동하는지 설명할 수 있다면, 그것에 대한 기술 문서를 작성할 수 있습니다. 특히 일반 대중이 읽을 수 있도록 기술 문서를 업데이트, 개편, 확장 또는 만들고자 하는 오픈소스 프로젝트라면 더욱 그렇습니다. 일반 영어로 더 많이 쓸수록 좋습니다. 가장 좋은 점은 기술 문서를 작성하기 위해 프로그래머가 될 필요가 없다는 것입니다.
|
||||
|
||||
무엇보다도, 주변 사람들이 논의하는 내용을 경청하세요. 절실한 필요를 알아볼 수 있는지 살펴보세요. 예를 들어, 최근 Parrot 개발자 메일링 리스트에서 기존 Trac 설치를 버리고 GitHub를 문제 티켓 시스템으로 사용하기로 결정했습니다. 일부 사람들은 티켓을 GitHub 시스템으로 변환할 방법이 없었기 때문에 이 결정에 반대했습니다. 하루 동안 논쟁이 오고 간 후, 제가 끼어들어 "제가 변환기를 작성하면 어떨까요?"라고 말했습니다. 사람들은 그 아이디어에 열광했습니다. 저는 450개 이상의 티켓에 대한 변환 프로그램을 작성하는 데 시간을 보냈고, 그래서 티켓 기록을 하나도 잃지 않았습니다. 큰 성공이었습니다. 저는 참여할 수 있었고, 핵심 개발자들은 Parrot 작업에 집중할 수 있었습니다.
|
||||
|
||||
16. **다른 사람들을 가르치고 돕기**: 어떤 주제에 대해 더 많이 배우는 가장 좋은 방법은 그것을 가르치려고 노력하는 것입니다. 최고의 교사는 복잡한 내용을 간단한 예시로 설명할 수 있는 사람입니다. 따라서 최고의 학습자가 되고 프로그래밍 세계에서 최고가 되려면 최고의 교사가 되기 위해 노력해야 합니다. 다른 사람들을 가르치는 것은 자신에 대해 더 나은 기분을 느끼게 하고 직업에서 더 나은 기술과 지식을 얻는 데 도움이 될 것입니다. 누군가에게 도움을 받으면 혼자 간직하지 말고 다른 사람들과 공유하세요. 세상을 더 살기 좋은 곳으로 만드세요.
|
||||
+71
@@ -0,0 +1,71 @@
|
||||
# Cum sa contribuiti la proiectele Open Source: Un ghid detaliat pentru incepatori
|
||||
|
||||
Pe scurt: Daca sunteti nerabdator/nerabdatoare sa creati primul Pull Request pe un proiect Open Source, folositi instructiunile de aici: [Readme](https://github.com/firstcontributions/first-contributions)
|
||||
|
||||
Contributiile la proiectele Open Source reprezinta una dintre cele mai bune metode de a te dezvolta ca programator/programatoare, a-ti dezvolta portofoliul si a da ceva inapoi comunitatii. Fie ca esti un programator senior sau doar ai inceput, proiectele Open Source ofera foarte multe oportunitati de a invata, colabora si a avea un impact pozitiv. In acest ghid, vom trece prin tot ceea ce trebuie sa stiti pentru a contribui la proiectele Open Source, de la a gasi proiectul protrivit si pana la a realiza prima contributie.
|
||||
|
||||
## De ce sa contribuiti la proiectele Open Source?
|
||||
|
||||
Inainte sa vorbim despre "cum", sa exploram "de ce". Contribuirea la proiectele Open Source ofera numeroase beneficii:
|
||||
|
||||
* Dezvoltarea abilitatilor: Proiectele Open Source va expun la cod sursa din proiecte reale, ajutandu-va la imbunatatirea abilitatilor dvs. de programare, depanare si colaborare.
|
||||
* Construirea unui Portofoliu: Contributiile la proiectele bine cunoscute va pot imbogati CV-ul si profilul dvs. de pe Github, ajutandu-va sa iesiti in evidenta in fata potentialilor angajatori.
|
||||
* Networking (Colaborarea, socializarea cu scop profesional): Va veti conecta cu dezvoltatori din intreaga lume, veti invata de la experti si veti face parte la randul dvs. din aceasta comunitate globala.
|
||||
* Sa dai inapoi (ca multumire): Proiectele Open Source stau la baza multor aplicatii/programe software pe care le folosim zilnic. Contributiile sunt un mod de a sustine uneltele si tehnologiile pe care va bazati/de care depindeti.
|
||||
* Oportunitati de cariera: Multe companii cauta in mod activ programatori cu experienta pe proiecte Open Source deoarece astfel se demonstreaza initiativa, proactivitatea si lucrul in echipa.
|
||||
|
||||
## Cum sa incepeti sa contribuiti pe proiectele Open Source
|
||||
|
||||
### 1. Alegeti Proiectul potrivit
|
||||
|
||||
Identificarea proiectului potrivit este cruciala. Cautati proiecte care se aliniaza intereselor, nivelurilor abilitatilor si telurilor dvs.. Le puteti gasi intr-unul din modurile urmatoare:
|
||||
|
||||
* Explorati Github: Folositi pagina Github Explore sau cautati topicurile precum "necesita-ajutor", "ajutor-cerut", "good-first-issue", "help-wanted" etc.
|
||||
* Cautati programe dedicate Open Source: Programe ca Google Summer of Code, Hacktoberfest si altele sunt bune pentru incepatori.
|
||||
* Urmariti proiectele dedicate uneltelor/programelor tale (favorite): Contribuie la librarii, frameworks, unelte sau programe pe care deja le folositi.
|
||||
|
||||
### 2. Intelegeti proiectul
|
||||
|
||||
Inainte sa contribuiti, este indicat sa dedicati timp pentru a intelege proiectul:
|
||||
|
||||
* Cititi documentatia: Incepeti cu fisierul README, cele mai bune practici, reguli si indicatii pentru contributii si regulamentul de conduita.
|
||||
* Exploreaza codul sursa: Familiarizati-va cu structura proiectului si stilul de programare (indentari, conventii de nume, etc.).
|
||||
* Alaturati-va comunitatii: Participati la discutiile de pe forumuri, Slack sau Discord pentru a va acomoda mai usor in comunitate.
|
||||
|
||||
### 3. Incepeti cu pasi mici
|
||||
|
||||
Incepeti cu pasi mici, sarcini de lucru pe care le puteti dezvolta, care va vor ajuta sa deveniti mai increzator/increzatoare, precum:
|
||||
|
||||
* Repararea defectelor: Cauta "issues" ((cerinte de) sarcini de lucru) pe pagina dedicata, care au etichete precum "sarcina-buna-de-inceput", "pentru-incepatori", "incepatori", "good-first-issue", "beginner-friendly" etc.
|
||||
* Imbunatatiti documentatia: Actualizarile documentatiei sunt adesea trecute cu vederea, insa aduc multa plus-valoare.
|
||||
* Scrieti teste: Adaugarea de teste (teste unitare, teste de integrare, etc.) este un mod foarte bun de a contribui si a invata mai bine codul sursa.
|
||||
|
||||
### 4. Folositi cele mai bune practici
|
||||
|
||||
Cand contribuiti, este bine sa respectati indicatiile pentru cele mai bune practici:
|
||||
|
||||
* Bifurca si Cloneaza: Bifurcati (fork) si clonati codul sursa (depozitul) pe masina dvs. locala.
|
||||
* Creati o ramura: Lucrati pe o ramura separata pentru a face modificarile dvs..
|
||||
* Scrieti cod curat: Urmariti standardele de a scrie cod sursa si scrieti cod clar, curat, citibil, concis.
|
||||
* Testati modificarile: Asigurati-va ca modificarile dvs. nu vor afecta functionalitatea existenta.
|
||||
* Creati un Pull Request (cerere de unificare cod sursa intre doua ramuri): Faceti o cerere de unificare a versiunii dvs. de cod sursa cu cel existent pe alta ramura (de obicei cea principala), unde trebuie sa aveti o descriere clara a PR-ului, referentiati alte sarcini de lucru corelate si fiti deschisi la feedback.
|
||||
|
||||
## Sfaturi pentru a avea succes in proiectele Open Source
|
||||
|
||||
Comunicati eficient si eficace: Fiti respectuosi si comportati-va in mod profesional in toate interactiunile. Puneti intrebari cand nu sunteti siguri de cerinte. Aveti rabdare in timpul procesului de evaluare/revizuire.
|
||||
|
||||
Fiti consistenti: Contributiile regulate, chiar si cele mici, pot avea un impact mare in timp.
|
||||
|
||||
Invatati din feedback: Evaluarile de cod sursa sunt un prilej de invatare. Acceptati rezultatele acestor evaluari si va veti imbunatati abilitatile.
|
||||
|
||||
Dati inapoi (ceva comunitatii): Odata ce sunteti comfortabil(a) cu procesul de PR, ajutati-i si pe altii in acest proces, raspundeti-le la intrebari sau chiar fiti mentor pentru incepatori.
|
||||
|
||||
## Provocari comune si cum sa le depasiti
|
||||
|
||||
* Sindromul Impostorului: Multi incepatori simt ca nu au destule abilitati pentru a contribui. Retineti ca toti au inceput de undeva si ca pana si contributiile mici conteaza.
|
||||
* Gasirea timpului necesari: Incepeti cu sarcini de lucru mici, pe care le puteti face. Pana si 30 de minute pe saptamana pot face o diferenta.
|
||||
* Navigarea unui depozit mare de cod sursa: Impartiti procesul de invatare: Incepeti prin a citi in detaliu documentatia - Concentrati-va pe intelegerea unei singure componente la un moment dat - Folositi toate uneltele pentru depanare de care dispuneti - Nu ezitati sa puneti intrebari pentru clarificari
|
||||
|
||||
## Concluzie
|
||||
|
||||
Contributia la proiectele Open Source este o calatorie/aventura/un proces care va ofera imense posibilitati de dezvoltare personala si profesionala. Incepand cu pasi mici, ramanand consistenti si interactionand cu comunitatea, puteti face contributii de impact in timp ce va imbunatatiti abilitatile. Tineti minte ca proiectele Open Source se dezvolta prin colaborare si ca fiecare contributie - indiferent de cat de mica ar fi - ajuta la imbunatatirea mediului digital. Sunteti gata sa incepeti? Gasiti un proiect care va atrage, realizati prima contributie si alaturati-va miscarii globale Open Source astazi!
|
||||
@@ -0,0 +1,124 @@
|
||||
# Cosas que un no programador puede hacer
|
||||
## Empieza a escuchar
|
||||
|
||||
Todo en código abierto involucra a otras personas.
|
||||
Estás buscando unirte a un equipo y eso significa comprender la comunidad y cómo funciona.
|
||||
Entrar en un proyecto y decir "Hola, esto es lo que creo que debería hacer este proyecto." generalmente no se considera algo bueno.
|
||||
Algunos proyectos pueden acoger con agrado ese tipo de enfoque, pero si el proyecto lleva funcionando un tiempo, las posibilidades de que se adopte esa actitud son pequeñas.
|
||||
**Escuchar es la mejor manera de saber qué necesita el proyecto.**
|
||||
|
||||
1. **Únase a una lista de correo** : para muchos proyectos, la lista de correo es el principal conducto de comunicación sobre el desarrollo del proyecto.
|
||||
En proyectos grandes, hay muchas listas de correo para elegir.
|
||||
Por ejemplo, el proyecto PostgreSQL tiene no menos de 12 listas orientadas a usuarios y seis listas de desarrolladores en su página de lista de correo.
|
||||
Le sugiero que siga la lista principal orientada al usuario y la lista principal de desarrolladores para comenzar a escuchar.
|
||||
|
||||
2. **Siga un blog** : los blogs mantenidos por desarrolladores principales a menudo brindan información sobre lo que se avecina en futuras versiones.
|
||||
y lo que se necesita para llegar allí. Un sitio planetario agrega noticias y entradas de blogs de muchas fuentes relacionadas con el proyecto.
|
||||
Si hay un sitio planetario, como planet.gnome.org o planet.mysql.com, comience allí. Simplemente busque en Google "planeta <nombre del proyecto>".
|
||||
|
||||
3. **Únase a un canal IRC** : muchos proyectos de código abierto tienen canales de chat de retransmisión (IRC) de Internet dedicados donde desarrolladores y usuarios se reúnen para discutir problemas y desarrollo.
|
||||
Consulte el sitio web del proyecto para obtener detalles sobre cómo se llama el canal y en qué red IRC se encuentra.
|
||||
|
||||
**Trabajar con tickets**
|
||||
El código es el corazón de cualquier proyecto de código abierto, pero no crea que escribir código es la única forma de contribuir.
|
||||
El mantenimiento del código y de los sistemas que lo rodean a menudo se descuidan en la prisa por crear nuevas funciones y corregir errores.
|
||||
Considere estas áreas como una manera fácil de involucrarse en un proyecto.
|
||||
La mayoría de los proyectos tienen un sistema de notificación de problemas visible públicamente, vinculado desde la página principal del sitio web del proyecto e incluido en la documentación.
|
||||
Es el conducto principal de comunicación entre los usuarios y los desarrolladores. Mantenerlo actualizado es una excelente manera de ayudar al proyecto.
|
||||
Es posible que necesite obtener permisos especiales en el sistema de tickets, que la mayoría de los líderes de proyecto estarán encantados de otorgarle cuando diga que quiere ayudar a limpiar los tickets.
|
||||
|
||||
4. **Diagnosticar un error** : los errores a menudo no se informan correctamente.
|
||||
Diagnosticar y clasificar un error puede ayudar a los desarrolladores a ahorrar tiempo con el trabajo preliminar de descubrir los detalles del problema.
|
||||
Si un usuario informó: "El software no funciona cuando hago X", dedique algún tiempo a descubrir los detalles de ese problema.
|
||||
¿Es repetible? ¿Puedes crear un conjunto de pasos para causar el problema repetidamente? ¿Puedes limitar el problema, por ejemplo, si solo ocurre en un navegador pero no en otro, o en una distribución pero no en otra?
|
||||
|
||||
Incluso si no sabes qué causa el problema, el esfuerzo que pones en delimitar las circunstancias hace que sea más fácil para otra persona solucionarlo.
|
||||
Cualquier cosa que descubras, agrégala al ticket en el sistema de errores para que todos lo vean.
|
||||
|
||||
5. **Cerrar errores solucionados** : a menudo, los errores se corrigen en el código base, pero los tickets informados sobre ellos no se actualizan en el sistema de emisión de tickets.
|
||||
Limpiar este trozo de papel puede llevar mucho tiempo, pero es valioso para todo el proyecto.
|
||||
|
||||
Comience consultando el sistema de tickets en busca de tickets con más de un año y vea si el error aún existe.
|
||||
Consulte el registro de cambios de versión del proyecto para ver si el error se solucionó y se puede cerrar.
|
||||
Si se sabe que está solucionado, anote el número de versión en el ticket y ciérrelo.
|
||||
|
||||
Intente recrear el error con la última versión del software.
|
||||
Si no se puede recrear con la última versión, anótelo en el ticket y ciérrelo.
|
||||
Si todavía existe, anótelo también en el ticket y déjelo abierto.
|
||||
|
||||
Trabajar con código
|
||||
Los programadores de todos los niveles de experiencia pueden ayudar con el código del proyecto.
|
||||
No creas que tienes que ser un genio de la programación para hacer contribuciones reales a tu proyecto favorito.
|
||||
|
||||
Si su trabajo implica modificar el código, investigue el método que utiliza el proyecto para obtener el código de los contribuyentes.
|
||||
Cada proyecto tiene su propio flujo de trabajo, así que pregunte cómo hacerlo antes de enviar el código.
|
||||
|
||||
Por ejemplo, el proyecto PostgreSQL es muy riguroso en su proceso: las modificaciones del código se envían en forma de parche a una lista de correo donde los desarrolladores principales examinan cada aspecto del cambio. En el otro extremo hay un proyecto como Parrot donde es fácil obtener privilegios de confirmación para el código base. Si el proyecto usa GitHub, puede haber un flujo de trabajo que use la función de solicitud de extracción de GitHub. No hay dos proyectos iguales.
|
||||
|
||||
Siempre que modifique el código, asegúrese de actuar como un miembro responsable de la comunidad y de mantener el estilo de su código para que coincida con el resto del código base. El código que agregue o modifique debería verse como el resto. Puede que no le guste el estilo de refuerzo o el manejo de los espacios para la sangría, pero es de mala educación enviar un cambio de código que no coincide con los estándares existentes. Es lo mismo que decir "No me gusta tu estilo y creo que el mío es mejor, así que deberías hacerlo a mi manera".
|
||||
|
||||
6. **Pruebe una versión beta o candidata** : cualquier proyecto diseñado para ejecutarse en múltiples plataformas puede tener todo tipo de problemas de portabilidad.
|
||||
Cuando se acerca una versión y se publica una versión beta o candidata, el líder del proyecto espera que sea probada por muchas personas diferentes en muchas plataformas diferentes.
|
||||
Usted puede ser una de esas personas y ayudar a garantizar que el paquete funcione en su plataforma.
|
||||
|
||||
Por lo general, solo necesita descargar, compilar y probar el software, pero el valor para el proyecto puede ser enorme si utiliza una distribución o hardware poco común.
|
||||
Simplemente informar que la compilación y la prueba funcionan ayuda a los líderes del proyecto a saber que el lanzamiento inminente es sólido.
|
||||
|
||||
7. **Corregir un error** : aquí es donde generalmente comienzan los contribuyentes que desean comenzar a trabajar en el código.
|
||||
Es simple: encuentre un error que parezca interesante en el sistema de tickets e intente corregirlo en el código.
|
||||
Documente la solución en el código si es apropiado.
|
||||
Es una buena idea agregar una prueba al conjunto de pruebas para probar el código que corrigió; algunos proyectos requieren correcciones de errores para incluir pruebas. Tome notas mientras hurga en este código base desconocido. Incluso si no puede corregir el error, documente en el ticket lo que descubrió como parte del intento de solucionarlo. Lo que encuentres ayudará a quienes te sucedan.
|
||||
|
||||
8. **Escribe una prueba** : la mayoría de los proyectos tienen un conjunto de pruebas que prueba el código, pero es difícil imaginar un conjunto de pruebas al que no se le puedan agregar más pruebas.
|
||||
Utilice una herramienta de cobertura de pruebas como gcov para C o Devel::Cover para Perl para identificar áreas en el código fuente que no han sido probadas por el conjunto de pruebas.
|
||||
Luego, agregue una prueba a la suite para cubrirlo.
|
||||
|
||||
9. **Silenciar una advertencia del compilador** : el proceso de compilación de muchos proyectos basados en C a menudo arroja algún que otro indicador de advertencia del compilador en la pantalla.
|
||||
Estas advertencias generalmente no son indicadores de un problema, pero pueden parecerlo.
|
||||
Tener demasiadas advertencias puede hacer que el compilador suene como si estuviera llorando.
|
||||
Verifique si el código realmente podría estar ocultando un error. De lo contrario, modificar la fuente para silenciarla ayuda a ocultar estos falsos positivos.
|
||||
|
||||
10. **Agrega un comentario** :
|
||||
Cuando exploras el código, es posible que encuentres algunos puntos que te resulten confusos.
|
||||
Lo más probable es que si usted estaba confundido, otros también lo estarán. Documentarlos en el código y enviar un parche.
|
||||
Trabajar con documentación
|
||||
La documentación suele ser la parte de un proyecto que recibe poca atención.
|
||||
También puede verse afectado por haber sido escrito desde el punto de vista de quienes están familiarizados con el proyecto, en lugar de desde los ojos de alguien que recién se está involucrando en él.
|
||||
Si alguna vez ha leído documentos de un proyecto en el que piensa: "Es como si este manual esperara que yo ya supiera cómo utilizar el paquete", sabe de lo que estoy hablando.
|
||||
A menudo, un par de ojos nuevos pueden señalar deficiencias en la documentación que quienes están cerca del proyecto no notan.
|
||||
|
||||
11. **Crea un ejemplo** : No hay ningún proyecto que tenga demasiados ejemplos prácticos.
|
||||
Ya sea una API web, una biblioteca de rutinas, una aplicación GUI como Gimp o una herramienta de línea de comandos,
|
||||
un buen ejemplo de uso adecuado puede explicar más clara y rápidamente el uso adecuado del software que las páginas de documentación.
|
||||
Para una API o biblioteca, cree un programa de ejemplo que utilice la herramienta. Esto incluso podría extraerse del código que haya escrito y reducirlo a lo estrictamente necesario.
|
||||
Para una herramienta, muestre ejemplos del mundo real de cómo la ha utilizado en su vida diaria. Si estás orientado visualmente,
|
||||
Considere la posibilidad de crear una captura de pantalla de un proceso importante, como por ejemplo cómo instalar la aplicación.
|
||||
|
||||
Trabajar con la comunidad
|
||||
El código abierto se trata sólo en parte de código. La comunidad hace que el código abierto funcione. A continuación le presentamos formas en las que puede ayudar a desarrollarlo.
|
||||
|
||||
12. **Responda una pregunta** : La mejor manera de ayudar a construir la comunidad es ayudando a los demás.
|
||||
Responder una pregunta, especialmente de alguien que recién se está iniciando, es crucial para ayudar a que el proyecto crezca y prospere.
|
||||
El tiempo que se toma para ayudar a un principiante, incluso si está haciendo una pregunta en la que fácilmente se podría responder con un rápido "RTFM", vale la pena en el futuro para conseguir otro miembro activo de la comunidad.
|
||||
Todo el mundo empieza en alguna parte y los proyectos necesitan un flujo constante de personas para que sigan siendo vitales.
|
||||
|
||||
13. **Escribe una publicación de blog** :
|
||||
Si tienes un blog, escribe sobre tus experiencias con el proyecto que estás utilizando.
|
||||
Cuéntanos sobre un problema que enfrentaste al usar el software y qué hiciste para resolverlo.
|
||||
Ayudarás de dos maneras: ayudando a mantener el proyecto en la mente de quienes te rodean,
|
||||
y creando un registro para cualquier otra persona que tenga su problema en el futuro y busque la respuesta en la web.
|
||||
(Un blog de sus aventuras técnicas también es una excelente manera de mostrar su experiencia en el mundo real con el software en cuestión la próxima vez que busque trabajo usándolo).
|
||||
|
||||
14. **Mejorar un sitio web** :
|
||||
Si tiene habilidades en diseño web y puede ayudar a mejorar el sitio web y, por lo tanto, la imagen pública del proyecto, es tiempo bien invertido.
|
||||
Quizás el proyecto podría necesitar una revisión gráfica o un logotipo para identificarlo.
|
||||
Estas pueden ser habilidades que faltan en la comunidad. Sé que me encantaría poder obtener ayuda con el diseño gráfico de los sitios web de mis proyectos.
|
||||
|
||||
15. **Escribir documentación técnica**
|
||||
Si puede escribir sobre cómo funciona una aplicación o software, puede escribir documentación técnica al respecto. Especialmente proyectos de código abierto que buscan actualizar, renovar, ampliar o crear documentos técnicos para que los lea el público en general. Cuanto más escribas en inglés sencillo, mejor. La mejor parte es que no es necesario ser programador para escribir documentos técnicos.
|
||||
|
||||
Sobre todo, escuche lo que discuten las personas que lo rodean. Vea si puede reconocer una necesidad urgente. Por ejemplo, recientemente en la lista de correo de los desarrolladores de Parrot, se decidió utilizar GitHub como sistema de notificación de problemas, abandonando la antigua instalación de Trac que tenían. Algunas personas estaban en contra de la medida porque no había forma de convertir los tickets al sistema de GitHub. Después de un día de discusiones de ida y vuelta, hablé y dije: "¿Qué tal si escribo un convertidor?" La gente estaba encantada con la idea. Dediqué tiempo a escribir un programa de conversión para más de 450 boletos, por lo que no perdimos nada de nuestro historial de boletos. Fue un gran éxito. Pude colaborar y los desarrolladores principales se mantuvieron concentrados en el negocio de trabajar en Parrot.
|
||||
|
||||
16. **Enseñar y ayudar a otros** :
|
||||
La mejor manera de aprender más sobre un tema es intentar enseñarlo.
|
||||
El mejor profesor es el que puede explicar cosas complejas con ejemplos sencillos. Por lo tanto, debes intentar ser el mejor maestro para ser el mejor alumno y el mejor en tu mundo de programación. Enseñar a otros te hará sentir mejor contigo mismo y te ayudará a adquirir mejores habilidades y conocimientos en tu profesión. Cuando reciba ayuda de alguien, no se la guarde para usted, compártala con los demás. Hacer el mundo un lugar mejor para vivir .
|
||||
@@ -0,0 +1,157 @@
|
||||
# புரோகிராமர் அல்லாதவர் செய்யக்கூடிய விஷயங்கள்
|
||||
## கேட்கத் தொடங்குங்கள்
|
||||
|
||||
திறந்த மூலத்தில் உள்ள அனைத்தும் மற்றவர்களை உள்ளடக்கியது.
|
||||
நீங்கள் ஒரு குழுவில் சேர விரும்புகிறீர்கள், அதாவது சமூகத்தையும் அது எவ்வாறு செயல்படுகிறது என்பதையும் புரிந்துகொள்வது.
|
||||
ஒரு ப்ராஜெக்ட்டில் நுழைந்து, "ஹாய், இதோ இந்த ப்ராஜெக்ட் செய்ய வேண்டும் என்று நான் நினைக்கிறேன்" என்று சொல்வது பொதுவாக நல்ல விஷயமாக எடுத்துக்கொள்ளப்படுவதில்லை.
|
||||
சில திட்டங்கள் அந்த வகையான அணுகுமுறையை வரவேற்கலாம், ஆனால் திட்டம் சிறிது நேரம் இயங்கிக்கொண்டிருந்தால், அந்த அணுகுமுறை ஏற்றுக்கொள்ளப்படுவதற்கான வாய்ப்புகள் சிறியவை.
|
||||
**திட்டத்திற்கு என்ன தேவை என்பதை அறிய சிறந்த வழி கேட்பது.**
|
||||
|
||||
1. **அஞ்சல் பட்டியலில் சேரவும்**: பல திட்டங்களுக்கு, திட்டத்தின் மேம்பாடு பற்றிய தகவல் பரிமாற்றத்தின் முக்கிய வழித்தடமாக அஞ்சல் பட்டியல் உள்ளது.
|
||||
பெரிய திட்டங்களில், தேர்வு செய்ய பல அஞ்சல் பட்டியல்கள் உள்ளன.
|
||||
எடுத்துக்காட்டாக, PostgreSQL திட்டமானது அதன் அஞ்சல் பட்டியல் பக்கத்தில் 12 பயனர் சார்ந்த பட்டியல்களையும் ஆறு டெவலப்பர் பட்டியல்களையும் கொண்டிருக்கவில்லை.
|
||||
முக்கிய பயனர் சார்ந்த பட்டியலையும், கேட்கத் தொடங்கும் முக்கிய டெவலப்பர் பட்டியலையும் நீங்கள் பின்பற்ற பரிந்துரைக்கிறேன்.
|
||||
|
||||
2. **ஒரு வலைப்பதிவைப் பின்தொடரவும்**: முக்கிய டெவலப்பர்களால் பராமரிக்கப்படும் வலைப்பதிவுகள் எதிர்கால வெளியீடுகளில் என்ன வரப்போகிறது என்பது பற்றிய தகவல்களை அடிக்கடி தருகிறது,
|
||||
மற்றும் அங்கு செல்ல என்ன எடுக்கப்பட்டது. திட்டத்துடன் தொடர்புடைய பல மூலங்களிலிருந்து செய்திகள் மற்றும் வலைப்பதிவு உள்ளீடுகளை ஒரு கிரக தளம் ஒருங்கிணைக்கிறது.
|
||||
planet.gnome.org அல்லது planet.mysql.com போன்ற கிரக தளம் இருந்தால், அங்கேயே தொடங்கவும். "planet <projectname>" என்று கூகுளில் தேடினால் போதும்.
|
||||
|
||||
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 ஆப்ஸாக இருந்தாலும் சரி, ஆனால் தற்போதுள்ள தரநிலைகளுடன் பொருந்தாத குறியீட்டு மாற்றத்தைச் சமர்ப்பிப்பது முரட்டுத்தனமானது. "உங்கள் பாணி எனக்குப் பிடிக்கவில்லை, என்னுடையது சிறந்தது என்று நான் நினைக்கிறேன், எனவே நீங்கள் அதை என் வழியில் செய்ய வேண்டும்" என்று சொல்வதும் ஒன்றுதான்.
|
||||
|
||||
6. **பீட்டாவைச் சோதிக்கவும் அல்லது வேட்பாளரை வெளியிடவும்**: பல தளங்களில் இயங்கும் வகையில் வடிவமைக்கப்பட்ட எந்தத் திட்டமும் எல்லா வகையான பெயர்வுத்திறன் சிக்கல்களையும் கொண்டிருக்கலாம்.
|
||||
ஒரு வெளியீடு நெருங்கி, பீட்டா அல்லது வெளியீட்டு வேட்பாளர் வெளியிடப்படும் போது, அது பல்வேறு தளங்களில் பல்வேறு நபர்களால் சோதிக்கப்படும் என்று திட்டத் தலைவர் நம்புகிறார்.
|
||||
நீங்கள் அந்த நபர்களில் ஒருவராக இருக்கலாம் மற்றும் உங்கள் பிளாட்ஃபார்மில் தொகுப்பு செயல்படுவதை உறுதிசெய்ய உதவலாம்.
|
||||
|
||||
பொதுவாக நீங்கள் மென்பொருளைப் பதிவிறக்கம் செய்து, உருவாக்கி, சோதித்துப் பார்க்க வேண்டும், ஆனால் நீங்கள் அசாதாரணமான விநியோகம் அல்லது வன்பொருளில் இருந்தால் திட்டத்திற்கான மதிப்பு மிகப்பெரியதாக இருக்கும்.
|
||||
உருவாக்கம் மற்றும் சோதனை வேலைகள் என்று அறிக்கையிடுவது, வரவிருக்கும் வெளியீடு உறுதியானது என்பதை திட்டத் தலைவர்கள் அறிய உதவுகிறது.
|
||||
|
||||
7. **பிழையை சரிசெய்தல்**: பொதுவாக, பங்களிப்பாளர்கள் குறியீட்டில் வேலை செய்ய விரும்பும் இடமாகும்.
|
||||
இது எளிதானது: டிக்கெட் அமைப்பில் ஒரு சுவாரஸ்யமான-ஒலி பிழையைக் கண்டறிந்து குறியீட்டில் அதை சரிசெய்ய முயற்சிக்கவும்.
|
||||
திருத்தம் பொருத்தமானதாக இருந்தால் குறியீட்டில் ஆவணப்படுத்தவும்.
|
||||
நீங்கள் சரிசெய்த குறியீட்டின் இடத்தைச் சோதிக்க, சோதனைத் தொகுப்பில் ஒரு சோதனையைச் சேர்ப்பது நல்லது; சோதனைகளைச் சேர்க்க சில திட்டங்களுக்கு பிழை திருத்தங்கள் தேவை. இந்த அறிமுகமில்லாத கோட்பேஸை சுற்றிக் கொண்டே குறிப்புகளை வைத்துக் கொள்ளுங்கள். பிழையை உங்களால் சரிசெய்ய முடியாவிட்டாலும், திருத்த முயற்சியின் ஒரு பகுதியாக நீங்கள் கண்டறிந்ததை டிக்கெட்டில் பதிவு செய்யவும். நீங்கள் கண்டுபிடிப்பது உங்களுக்குப் பின் வருபவர்களுக்கு உதவும்.
|
||||
|
||||
8. **சோதனை எழுது**: பெரும்பாலான திட்டங்களில் குறியீட்டைச் சோதிக்கும் ஒரு சோதனைத் தொகுப்பு உள்ளது, ஆனால் கூடுதல் சோதனைகளைச் சேர்க்க முடியாத ஒரு சோதனைத் தொகுப்பைக் கற்பனை செய்வது கடினம்.
|
||||
சோதனைத் தொகுப்பால் சோதிக்கப்படாத மூலக் குறியீட்டில் உள்ள பகுதிகளைக் கண்டறிய, Gcov for C அல்லது Devel::Cover for Perl போன்ற சோதனைக் கவரேஜ் கருவியைப் பயன்படுத்தவும்.
|
||||
பின்னர், அதை மறைக்க ஒரு சோதனையை தொகுப்பில் சேர்க்கவும்.
|
||||
|
||||
9. **ஒரு கம்பைலர் எச்சரிக்கையை அமைதிப்படுத்து**: பல சி-அடிப்படையிலான திட்டங்களுக்கான உருவாக்க செயல்முறை பெரும்பாலும் ஒற்றைப்படை கம்பைலர் எச்சரிக்கைக் கொடியை திரையில் செலுத்துகிறது.
|
||||
இந்த எச்சரிக்கைகள் பொதுவாக ஒரு சிக்கலின் குறிகாட்டிகள் அல்ல, ஆனால் அவை அப்படியே இருக்கும்.
|
||||
பல எச்சரிக்கைகள் இருப்பதால், கம்பைலர் ஓநாய் அழுவது போல் ஒலிக்கும்.
|
||||
குறியீடு உண்மையில் பிழையை மறைக்கிறதா என்பதைப் பார்க்கவும். இல்லையெனில், மூலத்தை அமைதிக்கு மாற்றுவது இந்த தவறான நேர்மறைகளை மறைக்க உதவுகிறது.
|
||||
|
||||
10. **ஒரு கருத்தைச் சேர்**:
|
||||
நீங்கள் குறியீட்டைத் தோண்டி எடுக்கும்போது, குழப்பமான சில இடங்களைக் காணலாம்.
|
||||
நீங்கள் குழப்பமடைந்திருந்தால், மற்றவர்களும் அவ்வாறு இருப்பதற்கான வாய்ப்புகள் உள்ளன. குறியீட்டில் அவற்றை ஆவணப்படுத்தி ஒரு பேட்சைச் சமர்ப்பிக்கவும்.
|
||||
ஆவணங்களுடன் வேலை செய்யுங்கள்
|
||||
ஆவணப்படுத்தல் என்பது ஒரு திட்டத்தின் ஒரு பகுதியாகும், இது குறுகிய மாற்றத்தைப் பெறுகிறது.
|
||||
யாரோ ஒருவரின் பார்வையில் நுழைவதை விட, திட்டத்துடன் நன்கு தெரிந்தவர்களின் பார்வையில் எழுதப்பட்டதால் இது பாதிக்கப்படலாம்.
|
||||
நீங்கள் எப்போதாவது ஒரு ப்ராஜெக்ட்டுக்கான டாக்ஸைப் படித்திருந்தால், "இந்த கையேடு எனக்கு ஏற்கனவே பேக்கேஜை எப்படி பயன்படுத்துவது என்று தெரியும் என்று எதிர்பார்க்கிறது போல் இருக்கிறது", நான் எதைப் பற்றி பேசுகிறேன் என்று உங்களுக்குத் தெரியும்.
|
||||
பெரும்பாலும் புதிய கண்களின் தொகுப்பு, திட்டத்திற்கு நெருக்கமானவர்கள் கவனிக்காத ஆவணங்களில் உள்ள குறைபாடுகளை சுட்டிக்காட்டலாம்.
|
||||
|
||||
11. **உதாரணத்தை உருவாக்கவும்**: பல எப்படி-எப்படி-எடுத்துக்கொள்ளும் உதாரணங்களைக் கொண்ட எந்த திட்டமும் இல்லை.
|
||||
அது ஒரு வலை API, நடைமுறைகளின் நூலகம், Gimp போன்ற GUI ஆப்ஸ் அல்லது கட்டளை வரி கருவியாக இருந்தாலும் சரி,
|
||||
முறையான பயன்பாட்டிற்கான ஒரு சிறந்த எடுத்துக்காட்டு, ஆவணங்களின் பக்கங்களை விட மென்பொருளின் சரியான பயன்பாட்டை மிகவும் தெளிவாகவும் விரைவாகவும் விளக்க முடியும்.
|
||||
API அல்லது நூலகத்திற்கு, கருவியைப் பயன்படுத்தும் ஒரு எடுத்துக்காட்டு நிரலை உருவாக்கவும். இது நீங்கள் எழுதிய குறியீட்டிலிருந்து பிரித்தெடுக்கப்படலாம், தேவைக்கேற்ப குறைக்கலாம்.
|
||||
ஒரு கருவிக்கு, உங்கள் அன்றாட வாழ்க்கையில் அதை எப்படிப் பயன்படுத்துகிறீர்கள் என்பதற்கான நிஜ உலக உதாரணங்களைக் காட்டுங்கள். நீங்கள் பார்வை சார்ந்தவராக இருந்தால்,
|
||||
பயன்பாட்டை எவ்வாறு நிறுவுவது போன்ற முக்கியமான செயல்முறையின் திரை-பிடிப்பை உருவாக்குவதைக் கருத்தில் கொள்ளுங்கள்.
|
||||
|
||||
சமூகத்துடன் வேலை செய்யுங்கள்
|
||||
ஓப்பன் சோர்ஸ் என்பது ஓரளவுக்கு மட்டுமே குறியீடு பற்றியது. சமூகம் திறந்த மூல வேலை செய்கிறது. நீங்கள் அதை உருவாக்க உதவும் வழிகள் இங்கே உள்ளன.
|
||||
|
||||
12. **கேள்விக்கு பதிலளிக்கவும்**: சமூகத்தை கட்டியெழுப்ப சிறந்த வழி மற்றவர்களுக்கு உதவுவதே.
|
||||
ஒரு கேள்விக்கு பதிலளிப்பது, குறிப்பாக கால்களை நனைக்கும் ஒருவரிடமிருந்து, திட்டம் வளரவும் செழிக்கவும் உதவும்.
|
||||
ஒரு தொடக்கநிலையாளருக்கு உதவ நீங்கள் எடுக்கும் நேரம், நீங்கள் விரைவாக "RTFM" ஐ எங்கே எளிதாகத் திரும்பப் பெறலாம் என்று ஒரு கேள்வியைக் கேட்டாலும், சமூகத்தின் மற்றொரு செயலில் உள்ள உறுப்பினரைப் பெறுவதற்கான பாதையைக் குறைக்கிறது.
|
||||
ஒவ்வொருவரும் எங்காவது தொடங்குகிறார்கள், மேலும் அவர்கள் முக்கியமாக இருக்க வேண்டுமென்றால் திட்டங்களுக்கு மக்கள் தொடர்ந்து வர வேண்டும்.
|
||||
|
||||
13. **ஒரு வலைப்பதிவு இடுகையை எழுதுங்கள்**:
|
||||
உங்களிடம் வலைப்பதிவு இருந்தால், நீங்கள் பயன்படுத்தும் திட்டத்தில் உங்கள் அனுபவங்களைப் பற்றி எழுதுங்கள்.
|
||||
மென்பொருளைப் பயன்படுத்தி நீங்கள் எதிர்கொண்ட பிரச்சனை மற்றும் அதைத் தீர்க்க நீங்கள் என்ன செய்தீர்கள் என்று சொல்லுங்கள்.
|
||||
உங்களைச் சுற்றியுள்ள மற்றவர்களின் மனதில் திட்டத்தை வைத்திருக்க உதவுவதன் மூலம், நீங்கள் இரண்டு வழிகளில் உதவுவீர்கள்.
|
||||
எதிர்காலத்தில் உங்கள் பிரச்சனையை எதிர்கொண்டு அதற்கான பதிலை இணையத்தில் தேடும் எவருக்கும் ஒரு பதிவை உருவாக்குவதன் மூலம்.
|
||||
(உங்கள் தொழில்நுட்ப சாகசங்களின் வலைப்பதிவு, கேள்விக்குரிய மென்பொருளின் நிஜ-உலக அனுபவத்தைக் காட்ட, அடுத்த முறை நீங்கள் வேலைக்காக வேட்டையாடச் செல்லும் ஒரு சிறந்த வழியாகும்.)
|
||||
|
||||
14. **ஒரு இணையதளத்தை மேம்படுத்தவும்**:
|
||||
நீங்கள் வலை வடிவமைப்பில் திறமை பெற்றிருந்தால் மற்றும் வலைகளை மேம்படுத்த உதவலாம்இது, மற்றும் திட்டத்தின் பொது முகம் படம், அந்த நேரம் நன்றாக செலவிடப்பட்டது.
|
||||
திட்டமானது ஒரு கிராஃபிக் மாற்றத்தை அல்லது திட்டத்தை அடையாளம் காண ஒரு லோகோவைப் பயன்படுத்தலாம்.
|
||||
இவை சமூகத்தில் இல்லாத திறன்களாக இருக்கலாம். எனது திட்டப்பணிகளின் இணையதளங்களில் ஏதேனும் கிராஃபிக் டிசைன் உதவி கிடைத்தால் நான் அதை விரும்புவேன் என்று எனக்குத் தெரியும்.
|
||||
|
||||
15. **தொழில்நுட்ப ஆவணங்களை எழுதவும்**
|
||||
ஒரு பயன்பாடு அல்லது மென்பொருள் எவ்வாறு செயல்படுகிறது என்பதைப் பற்றி நீங்கள் எழுத முடிந்தால், அதைப் பற்றிய தொழில்நுட்ப ஆவணங்களை நீங்கள் எழுதலாம். குறிப்பாக ஓப்பன் சோர்ஸ் திட்டங்கள், பொது மக்கள் படிக்கும் வகையில் தொழில்நுட்ப ஆவணங்களை புதுப்பிக்க, புதுப்பிக்க, விரிவாக்க அல்லது உருவாக்க வேண்டும். நீங்கள் சாதாரண ஆங்கிலத்தில் எவ்வளவு அதிகமாக எழுதுகிறீர்களோ, அவ்வளவு சிறந்தது. சிறந்த பகுதி, தொழில்நுட்ப ஆவணங்களை எழுத நீங்கள் ஒரு புரோகிராமராக இருக்க வேண்டியதில்லை.
|
||||
|
||||
எல்லாவற்றிற்கும் மேலாக, உங்களைச் சுற்றியுள்ளவர்கள் என்ன பேசுகிறார்கள் என்பதைக் கேளுங்கள். ஒரு அழுத்தமான தேவையை உங்களால் அடையாளம் காண முடியுமா என்று பாருங்கள். உதாரணமாக, சமீபத்தில் கிளி டெவலப்பர்களின் அஞ்சல் பட்டியலில், அவர்கள் வைத்திருந்த பழைய ட்ராக் நிறுவலைக் கைவிட்டு, சிக்கல் டிக்கெட் அமைப்பாக GitHub ஐப் பயன்படுத்த முடிவு செய்யப்பட்டது. டிக்கெட்டுகளை கிட்ஹப் அமைப்பிற்கு மாற்ற வழி இல்லாததால் சிலர் இந்த நடவடிக்கைக்கு எதிராக இருந்தனர். ஒரு நாள் முன்னும் பின்னுமாக வாக்குவாதத்திற்குப் பிறகு, "நான் மாற்றி எழுதினால் எப்படி?" இந்த யோசனையில் மக்கள் மகிழ்ச்சியடைந்தனர். 450+ டிக்கெட்டுகளுக்கு மாற்றும் திட்டத்தை எழுத நான் நேரத்தை செலவிட்டேன், அதனால் எங்களின் டிக்கெட் வரலாறு எதையும் இழக்கவில்லை. இது பெரும் வெற்றி பெற்றது. நான் களமிறங்கினேன், முக்கிய டெவலப்பர்கள் கிளி வேலை செய்யும் வணிகத்தில் கவனம் செலுத்தினர்.
|
||||
|
||||
16. **மற்றவர்களுக்குக் கற்றுக் கொடுங்கள்**:
|
||||
ஒரு தலைப்பைப் பற்றி மேலும் அறிய சிறந்த வழி அதைக் கற்பிக்க முயற்சிப்பதாகும்.
|
||||
சிக்கலான விஷயங்களை எளிய உதாரணங்களுடன் விளக்கக்கூடியவர் சிறந்த ஆசிரியர். எனவே நீங்கள் சிறந்த கற்பவராகவும் உங்கள் நிரலாக்க உலகில் சிறந்தவராகவும் இருக்க சிறந்த ஆசிரியராக இருக்க முயற்சிக்க வேண்டும். மற்றவர்களுக்குக் கற்பிப்பது உங்களைப் பற்றி நன்றாக உணரவைக்கும், மேலும் உங்கள் தொழிலில் சிறந்த திறன்களையும் அறிவையும் பெற உதவும். நீங்கள் ஒருவரிடமிருந்து உதவியைப் பெற்றால், அதை நீங்களே வைத்துக் கொள்ளாதீர்கள், மற்றவர்களுடன் பகிர்ந்து கொள்ளுங்கள். உலகத்தை வாழ சிறந்த இடமாக மாற்றவும்.
|
||||
+94
@@ -0,0 +1,94 @@
|
||||
# ஓபன் சோர்ஸிற்குப் பயனளிக்க எப்படி: ஒரு விரிவான வழிகாட்டி (குவிகட்டிய தொடக்கத்திற்காக)
|
||||
|
||||
**TL;DR** - நீங்கள் ஓபன் சோர்ஸ் திட்டத்தில் உங்கள் முதல் புல் ரிக்வஸ்டை செய்ய விரும்பினால், [Readme](https://github.com/firstcontributions/first-contributions) லுள்ள வழிமுறைகளைப் பின்பற்றுங்கள். நான் ஒரு சிறிய பிழையை திருத்தும் பங்களிப்பை என் முதல் பங்களிப்பாகச் செய்கிறேன்.
|
||||
|
||||
ஓபன் சோர்ஸிற்குப் பயனளிப்பது ஒரு மென்பொருள் டெவலப்பராக வளரவும், உங்கள் போர்ட்ஃபோலியோவை உருவாக்கவும், சமூகத்திற்குப் பங்களிக்கவும் சிறந்த வழிகளில் ஒன்றாகும். நீங்கள் அனுபவம் வாய்ந்த நிரலாளராக இருந்தாலும், அல்லது புதியதாக இருந்தாலும், ஓபன் சோர்ஸ் உங்களுக்கு நிறைய கற்றல், இணைப்பு, மற்றும் தாக்கம் செலுத்தும் வாய்ப்புகளை வழங்குகிறது.
|
||||
|
||||
இந்த வழிகாட்டியில், சரியான திட்டத்தைத் தேர்ந்தெடுப்பதிலிருந்து உங்கள் முதல் பங்களிப்பைச் செய்வது வரை, ஓபன் சோர்ஸில் பங்களிப்பதற்கான அனைத்து முக்கிய விஷயங்களையும் ஆராய்வோம்.
|
||||
|
||||
---
|
||||
|
||||
## ஏன் ஓபன் சோர்ஸில் பங்களிக்க வேண்டும்?
|
||||
|
||||
"எப்படி" என்பதைப் பார்க்கும் முன், "ஏன்" என்பதை ஆராய்வோம். ஓபன் சோர்ஸில் பங்களிப்பது பல நன்மைகளை வழங்குகிறது:
|
||||
|
||||
- **திறமைகளை மேம்படுத்துதல்** – உண்மையான புரொஜெக்ட் கோடுகளைப் பார்க்க வாய்ப்பு கிடைக்கும், எங்கேயும் சேர முடியாத அனுபவம் கிடைக்கும்.
|
||||
- **போர்ட்ஃபோலியோ உருவாக்கம்** – பிரபலமான ஓபன் சோர்ஸ் திட்டங்களில் பங்களிப்பது உங்கள் ரெஸ்யூமேயை மெருகூட்டும்.
|
||||
- **நெட்வொர்க்கிங்** – உலகளாவிய டெவலப்பர்களுடன் இணைவது, புதிய விஷயங்களைப் பழகுவது.
|
||||
- **சமூகத்திற்குப் பங்களிக்க** – நாம் தினமும் பயன்படுத்தும் மென்பொருள்களுக்கு உதவிக்கரம் நீட்டும் வாய்ப்பு.
|
||||
- **வேலை வாய்ப்புகள்** – ஓபன் சோர்ஸ் அனுபவம் கொண்டவர்களை பல நிறுவனங்கள் விரும்பி பணியமர்த்துகின்றன.
|
||||
|
||||
---
|
||||
|
||||
## ஓபன் சோர்ஸில் பங்களிக்க எப்படி தொடங்கலாம்?
|
||||
|
||||
### 1. சரியான திட்டத்தைத் தேர்ந்தெடுங்கள்
|
||||
|
||||
உங்களுக்குப் பொருத்தமான திட்டத்தை கண்டுபிடிப்பது முக்கியம். இதைப் பற்றிச் சில வழிகள்:
|
||||
|
||||
- **GitHub-ஐ ஆராயுங்கள்** – ["good-first-issue"](https://github.com/search?q=label%3Agood-first-issue) போன்ற தொடக்க நபர்களுக்கான குறிச்சொற்களைப் பயன்படுத்தி தேடுங்கள்.
|
||||
- **ஓபன் சோர்ஸ் நிகழ்ச்சிகளைப் பின்பற்றுங்கள்** – Google Summer of Code, Hacktoberfest போன்றவை சிறந்த தொடக்க புள்ளிகள்.
|
||||
- **உங்களுக்குப் பழக்கமான கருவிகளைத் தேர்வு செய்யுங்கள்** – நீங்கள் பயன்படுத்தும் புத்தகங்கள், libraries, frameworks ஆகியவற்றில் பங்களிக்கலாம்.
|
||||
|
||||
---
|
||||
|
||||
### 2. திட்டத்தைப் புரிந்துகொள்ளுங்கள்
|
||||
|
||||
பங்களிக்க முன்பாக, திட்டத்தை முழுமையாகப் புரிந்துகொள்ள முயற்சி செய்யுங்கள்:
|
||||
|
||||
- **README மற்றும் வழிமுறைகளை வாசிக்கவும்** – பங்களிப்பு வழிகாட்டி, கோட்பாடு (code of conduct) போன்றவற்றைப் பாருங்கள்.
|
||||
- **கோட்பணியை ஆராயுங்கள்** – கோப்புகளின் அமைப்பு, கோடிங் ஸ்டைல் போன்றவற்றை அறிந்து கொள்ளுங்கள்.
|
||||
- **சமூகத்தில் ஈடுபடுங்கள்** – Forums, Slack, Discord போன்ற இடங்களில் கலந்துரையாடுங்கள்.
|
||||
|
||||
---
|
||||
|
||||
### 3. சிறிய பங்களிப்புகளுடன் தொடங்குங்கள்
|
||||
|
||||
முதலில் எளிதான விடயங்களில் பங்களிக்கலாம்:
|
||||
|
||||
- **பிழைகளை சரிசெய்யுங்கள்** – "good-first-issue" அல்லது "beginner-friendly" போன்ற குறிச்சொற்களைப் பயன்படுத்தி சரிபாருங்கள்.
|
||||
- **ஆவணங்களை மேம்படுத்துங்கள்** – Documentation முக்கியமான பங்களிப்பு வழியாக இருக்கலாம்.
|
||||
- **Unit Testing எழுதுங்கள்** – Code coverage அதிகரிக்க இது உதவும்.
|
||||
|
||||
---
|
||||
|
||||
### 4. சிறந்த நடைமுறைகளைப் பின்பற்றுங்கள்
|
||||
|
||||
ஒரு நிரல்பாக பங்களிக்கும்போது, திட்ட விதிமுறைகளைப் பின்பற்றுங்கள்:
|
||||
|
||||
- **Fork & Clone செய்யுங்கள்** – உங்கள் கணக்கில் repository-ஐ fork செய்து, அதை local க்கு clone செய்யுங்கள்.
|
||||
- **Branch-ஐ உருவாக்குங்கள்** – தனியான branch-ல் வேலை செய்யுங்கள்.
|
||||
- **சுத்தமான கோட்களை எழுதுங்கள்** – திட்டத்திற்கேற்ப coding style-ஐ பின்பற்றுங்கள்.
|
||||
- **Test செய்யுங்கள்** – உங்கள் மாற்றங்கள் ஏதாவது பிரச்சனை ஏற்படுத்துகிறதா என்று சரிபாருங்கள்.
|
||||
- **Pull Request (PR) சமர்ப்பியுங்கள்** – PR-க்கு சரியான விளக்கம், issue reference, மற்றும் தயார் இருக்கும் மனப்பான்மை ஆகியவற்றுடன் சமர்ப்பியுங்கள்.
|
||||
|
||||
---
|
||||
|
||||
## ஓபன் சோர்ஸில் வெற்றி பெற சில குறிப்புகள்
|
||||
|
||||
✅ **தெளிவாக தொடர்புகொள்ளுங்கள்** – கேள்விகள் கேளுங்கள், புல்ல ரிக்வஸ்டுக்கு மறுமொழி கொடுப்பவர்களுக்கு நன்றி சொல்லுங்கள்.
|
||||
✅ **தொடர்ச்சியாக பங்களியுங்கள்** – சிறிய சிறிய பங்களிப்புகள் கூட பெரிய தாக்கத்தை ஏற்படுத்தும்.
|
||||
✅ **விமர்சனத்திலிருந்து கற்றுக்கொள்ளுங்கள்** – Code review மூலம் மேம்படுங்கள்.
|
||||
✅ **மற்றவர்களுக்கு உதவுங்கள்** – புல்ல ரிக்வஸ்டுகளை மதிப்பாய்வு செய்யுங்கள், புதியவர்களை வழிநடத்துங்கள்.
|
||||
|
||||
---
|
||||
|
||||
## பொதுவான சவால்கள் & அதை சமாளிக்க வழிகள்
|
||||
|
||||
❌ **Imposter Syndrome (நான் போதுமான திறமையுள்ளவரா? 🤔)**
|
||||
➡️ எல்லோருக்கும் இது வரும். சிறிய பங்களிப்புகளாலும் பெரிய தாக்கத்தை ஏற்படுத்தலாம்.
|
||||
|
||||
❌ **நேரம் இல்லாமை**
|
||||
➡️ ஒரு வாரத்திற்கும் 30 நிமிடங்கள் செலுத்தினாலும், நீங்கள் மெல்ல வளர முடியும்.
|
||||
|
||||
❌ **பெரிய கோட்பணியை புரிந்துகொள்வது கடினம்**
|
||||
➡️ டாக்குமென்டேஷனை வாசியுங்கள், ஒரு பிரிவில் கவனம் செலுத்துங்கள், Debugging tool-களை பயன்படுத்துங்கள்.
|
||||
|
||||
---
|
||||
|
||||
## முடிவுரை
|
||||
|
||||
ஓபன் சோர்ஸில் பங்களிப்பது வளர்ச்சிக்கு மிக நல்ல வழியாகும். சிறிய செயல்களில் தொடங்குங்கள், தொடர்ந்து பங்களியுங்கள், சமூகத்தில் ஈடுபடுங்கள். ஒவ்வொரு பங்களிப்பும் ஓபன் சோர்ஸை மேம்படுத்த உதவுகிறது.
|
||||
|
||||
🚀 **தொடங்க தயார்?**
|
||||
உங்களுக்கு பிடித்த திட்டத்தை தேடுங்கள், உங்கள் முதல் பங்களிப்பைச் செய்யுங்கள், மற்றும் உலகளாவிய ஓபன் சோர்ஸ் இயக்கத்தில் சேருங்கள்! 🎉
|
||||
+73
@@ -0,0 +1,73 @@
|
||||
# ఓపెన్ సోర్స్కు ఎలా సహకరించాలి: ప్రారంభకులకు సమగ్ర మార్గదర్శి
|
||||
|
||||
TL;DR మీరు ఓపెన్ సోర్స్ ప్రాజెక్ట్కి మీ మొదటి పుల్ అభ్యర్థనను చేయాలనుకుంటున్నట్లయితే, [Readme](https://github.com/firstcontributions/first-contributions)లోని సూచనలను అనుసరించండి.
|
||||
|
||||
డెవలపర్గా ఎదగడానికి, మీ పోర్ట్ఫోలియోను రూపొందించడానికి మరియు కమ్యూనిటీకి తిరిగి ఇవ్వడానికి ఓపెన్ సోర్స్కు సహకారం అందించడం అనేది అత్యంత బహుమతినిచ్చే మార్గాలలో ఒకటి. మీరు అనుభవజ్ఞుడైన ప్రోగ్రామర్ అయినా లేదా ఇప్పుడే ప్రారంభించినా, ఓపెన్ సోర్స్ తెలుసుకోవడానికి, సహకరించడానికి మరియు ప్రభావం చూపడానికి అంతులేని అవకాశాలను అందిస్తుంది. ఈ గైడ్లో, సరైన ప్రాజెక్ట్ను కనుగొనడం నుండి మీ మొదటి సహకారం అందించడం వరకు ఓపెన్ సోర్స్కు సహకరించడం గురించి మీరు తెలుసుకోవలసిన ప్రతిదానిని మేము మీకు తెలియజేస్తాము.
|
||||
|
||||
## ఓపెన్ సోర్స్కి ఎందుకు సహకరించాలి?
|
||||
|
||||
"ఎలా"లోకి ప్రవేశించే ముందు, "ఎందుకు" అనేదాన్ని అన్వేషిద్దాం. ఓపెన్ సోర్స్కు సహకారం అందించడం వలన అనేక ప్రయోజనాలను అందిస్తుంది:
|
||||
|
||||
* నైపుణ్యాభివృద్ధి: ఓపెన్ సోర్స్ ప్రాజెక్ట్లు మిమ్మల్ని వాస్తవ ప్రపంచ కోడ్బేస్లకు బహిర్గతం చేస్తాయి, మీ కోడింగ్, డీబగ్గింగ్ మరియు సహకార నైపుణ్యాలను మెరుగుపరచడంలో మీకు సహాయపడతాయి.
|
||||
* పోర్ట్ఫోలియో బిల్డింగ్: ప్రసిద్ధ ప్రాజెక్ట్లకు విరాళాలు మీ రెజ్యూమ్ మరియు GitHub ప్రొఫైల్ను మెరుగుపరుస్తాయి, తద్వారా మీరు సంభావ్య యజమానులకు ప్రత్యేకంగా నిలుస్తారు.
|
||||
* నెట్వర్కింగ్: మీరు ప్రపంచవ్యాప్తంగా ఉన్న డెవలపర్లతో కనెక్ట్ అవుతారు, నిపుణుల నుండి నేర్చుకుంటారు మరియు గ్లోబల్ కమ్యూనిటీలో భాగం అవుతారు.
|
||||
* గివింగ్ బ్యాక్: ఓపెన్ సోర్స్ మనం రోజూ ఉపయోగించే చాలా సాఫ్ట్వేర్లకు శక్తినిస్తుంది. మీరు ఆధారపడే సాధనాలు మరియు సాంకేతికతలకు మద్దతు ఇవ్వడానికి సహకారం అందించడం ఒక మార్గం.
|
||||
* కెరీర్ అవకాశాలు: చాలా కంపెనీలు ఓపెన్ సోర్స్ అనుభవంతో డెవలపర్లను చురుకుగా కోరుకుంటాయి, ఎందుకంటే ఇది చొరవ మరియు జట్టుకృషిని ప్రదర్శిస్తుంది.
|
||||
|
||||
## ఓపెన్ సోర్స్ కంట్రిబ్యూషన్లతో ఎలా ప్రారంభించాలి
|
||||
|
||||
### 1. సరైన ప్రాజెక్ట్ను ఎంచుకోండి
|
||||
|
||||
సరైన ప్రాజెక్ట్ను కనుగొనడం చాలా ముఖ్యం. మీ ఆసక్తులు, నైపుణ్యం స్థాయి మరియు లక్ష్యాలకు అనుగుణంగా ఉండే ప్రాజెక్ట్ల కోసం చూడండి. వాటిని ఎలా కనుగొనాలో ఇక్కడ ఉంది:
|
||||
|
||||
* GitHubని అన్వేషించండి: GitHub యొక్క అన్వేషణ పేజీని ఉపయోగించండి లేదా "గుడ్-ఫస్ట్-ఇష్యూ" లేదా "హెల్ప్-వాంటెడ్" వంటి అంశాల కోసం శోధించండి.
|
||||
* ఓపెన్ సోర్స్ ప్రోగ్రామ్లను తనిఖీ చేయండి: గూగుల్ సమ్మర్ ఆఫ్ కోడ్ లేదా హ్యాక్టోబర్ఫెస్ట్ వంటి ప్రోగ్రామ్లు ప్రారంభకులకు గొప్పవి.
|
||||
* మీ సాధనాలను అనుసరించండి: మీరు ఇప్పటికే ఉపయోగిస్తున్న లైబ్రరీలు, ఫ్రేమ్వర్క్లు లేదా సాధనాలకు సహకరించండి.
|
||||
|
||||
### 2. ప్రాజెక్ట్ను అర్థం చేసుకోండి
|
||||
|
||||
సహకరించే ముందు, ప్రాజెక్ట్ను అర్థం చేసుకోవడానికి సమయాన్ని వెచ్చించండి:
|
||||
|
||||
* డాక్యుమెంటేషన్ను చదవండి: README ఫైల్, సహకార మార్గదర్శకాలు మరియు ప్రవర్తనా నియమావళితో ప్రారంభించండి.
|
||||
* కోడ్బేస్ను అన్వేషించండి: ప్రాజెక్ట్ నిర్మాణం మరియు కోడింగ్ శైలితో మిమ్మల్ని మీరు పరిచయం చేసుకోండి.
|
||||
* సంఘంలో చేరండి: కమ్యూనిటీ కోసం ఒక అనుభూతిని పొందడానికి ఫోరమ్లు, స్లాక్ లేదా డిస్కార్డ్పై చర్చల్లో పాల్గొనండి.
|
||||
|
||||
### 3. చిన్నగా ప్రారంభించండి
|
||||
|
||||
విశ్వాసాన్ని పెంపొందించడానికి చిన్న, నిర్వహించదగిన పనులతో ప్రారంభించండి:
|
||||
|
||||
* బగ్లను పరిష్కరించండి: "మంచి-మొదటి సమస్య" లేదా "బిగినర్స్-ఫ్రెండ్లీ" అని లేబుల్ చేయబడిన సమస్యల కోసం చూడండి.
|
||||
* డాక్యుమెంటేషన్ను మెరుగుపరచండి: డాక్యుమెంటేషన్ అప్డేట్లు తరచుగా విస్మరించబడతాయి కానీ చాలా విలువైనవి.
|
||||
* పరీక్షలు రాయండి: పరీక్షలను జోడించడం అనేది కోడ్బేస్ గురించి తెలుసుకోవడానికి మరియు సహకరించడానికి ఒక గొప్ప మార్గం.
|
||||
|
||||
### 4. ఉత్తమ పద్ధతులను అనుసరించండి
|
||||
|
||||
సహకరించేటప్పుడు, ప్రాజెక్ట్ మార్గదర్శకాలకు కట్టుబడి ఉండండి:
|
||||
|
||||
* ఫోర్క్ మరియు క్లోన్: రిపోజిటరీని ఫోర్క్ చేసి మీ స్థానిక మెషీన్కు క్లోన్ చేయండి.
|
||||
* ఒక శాఖను సృష్టించండి: మీ మార్పుల కోసం ప్రత్యేక శాఖలో పని చేయండి.
|
||||
* క్లీన్ కోడ్ వ్రాయండి: ప్రాజెక్ట్ యొక్క కోడింగ్ ప్రమాణాలను అనుసరించండి మరియు స్పష్టమైన, సంక్షిప్త కోడ్ను వ్రాయండి.
|
||||
* మీ మార్పులను పరీక్షించండి: మీ మార్పులు ఇప్పటికే ఉన్న కార్యాచరణను విచ్ఛిన్నం చేయలేదని నిర్ధారించుకోండి.
|
||||
* ఒక పుల్ అభ్యర్థన (PR) సమర్పించండి: స్పష్టమైన PR వివరణ, సూచన సంబంధిత సమస్యలను వ్రాయండి మరియు అభిప్రాయానికి సిద్ధంగా ఉండండి.
|
||||
|
||||
## ఓపెన్ సోర్స్లో విజయం కోసం చిట్కాలు
|
||||
|
||||
ప్రభావవంతంగా కమ్యూనికేట్ చేయండి: అన్ని పరస్పర చర్యలలో గౌరవప్రదంగా మరియు వృత్తిపరంగా ఉండండి. అవసరాల గురించి అస్పష్టంగా ఉన్నప్పుడు ప్రశ్నలు అడగండి. సమీక్షకులకు వారి సమయం మరియు అభిప్రాయానికి ధన్యవాదాలు. సమీక్ష ప్రక్రియలో ఓపికగా ఉండండి
|
||||
|
||||
స్థిరంగా ఉండండి: రెగ్యులర్ కంట్రిబ్యూషన్లు, చిన్నవి కూడా, కాలక్రమేణా పెద్ద ప్రభావాన్ని చూపుతాయి.
|
||||
|
||||
అభిప్రాయం నుండి నేర్చుకోండి: కోడ్ సమీక్షలు నేర్చుకునే అవకాశం. అభిప్రాయాన్ని స్వీకరించండి మరియు మీ నైపుణ్యాలను మెరుగుపరచండి.
|
||||
|
||||
తిరిగి ఇవ్వండి: మీరు సౌకర్యవంతంగా ఉన్న తర్వాత, PRలను సమీక్షించడం, ప్రశ్నలకు సమాధానం ఇవ్వడం లేదా కొత్తవారికి మార్గదర్శకత్వం చేయడం ద్వారా ఇతరులకు సహాయం చేయండి.
|
||||
|
||||
## సాధారణ సవాళ్లు మరియు వాటిని ఎలా అధిగమించాలి
|
||||
|
||||
* ఇంపోస్టర్ సిండ్రోమ్: చాలా మంది ప్రారంభకులు తమకు సహకరించడానికి తగినంత నైపుణ్యం లేదని భావిస్తారు. గుర్తుంచుకోండి, ప్రతి ఒక్కరూ ఎక్కడో ఒకచోట ప్రారంభించబడతారు మరియు చిన్న విరాళాలు కూడా ముఖ్యమైనవి.
|
||||
* సమయాన్ని కనుగొనడం: చిన్న, నిర్వహించదగిన పనులతో ప్రారంభించండి. వారానికి 30 నిమిషాలు కూడా తేడా రావచ్చు.
|
||||
* పెద్ద కోడ్బేస్లను నావిగేట్ చేయడం: అభ్యాస ప్రక్రియను విచ్ఛిన్నం చేయండి: - డాక్యుమెంటేషన్ను పూర్తిగా చదవడం ద్వారా ప్రారంభించండి - ఒక సమయంలో ఒక భాగాన్ని అర్థం చేసుకోవడంపై దృష్టి పెట్టండి - కోడ్ అమలును ట్రేస్ చేయడానికి డీబగ్గింగ్ సాధనాలను ఉపయోగించండి - స్పష్టత కోసం అడగడానికి వెనుకాడకండి
|
||||
|
||||
## తీర్మానం
|
||||
|
||||
ఓపెన్ సోర్స్కు సహకరించడం అనేది అపారమైన వ్యక్తిగత మరియు వృత్తిపరమైన వృద్ధిని అందించే ప్రయాణం. చిన్నగా ప్రారంభించడం ద్వారా, స్థిరంగా ఉండటం మరియు సంఘంతో సన్నిహితంగా ఉండటం ద్వారా, మీరు మీ నైపుణ్యాలను మెరుగుపరుచుకుంటూ అర్ధవంతమైన సహకారాన్ని అందించవచ్చు. గుర్తుంచుకోండి, ఓపెన్ సోర్స్ సహకారంతో అభివృద్ధి చెందుతుంది మరియు ప్రతి సహకారం-ఎంత చిన్నదైనా-మెరుగైన డిజిటల్ ప్రపంచాన్ని నిర్మించడంలో సహాయపడుతుంది. మునిగిపోవడానికి సిద్ధంగా ఉన్నారా? మిమ్మల్ని ఉత్తేజపరిచే ప్రాజెక్ట్ను కనుగొనండి, మీ మొదటి సహకారాన్ని అందించండి మరియు ఈరోజే గ్లోబల్ ఓపెన్ సోర్స్ ఉద్యమంలో చేరండి!
|
||||
|
||||
## చివరి సమాధా
|
||||
@@ -0,0 +1,125 @@
|
||||
#สิ่งที่คนที่ไม่ใช่โปรแกรมเมอร์สามารถทำได้
|
||||
|
||||
## เริ่มฟัง
|
||||
|
||||
ทุกสิ่งในโอเพ่นซอร์สเกี่ยวข้องกับบุคคลอื่น
|
||||
คุณกำลังมองหาที่จะเข้าร่วมทีม และนั่นหมายถึงการทำความเข้าใจชุมชนและวิธีการทำงาน
|
||||
การเดินเข้าไปในโปรเจ็กต์แล้วพูดว่า "สวัสดี นี่คือสิ่งที่ฉันคิดว่าโปรเจ็กต์นี้ควรทำ" มักจะไม่ถือเป็นเรื่องดี
|
||||
บางโครงการอาจยินดีกับแนวทางดังกล่าว แต่หากโครงการดำเนินไประยะหนึ่งแล้ว โอกาสที่ทัศนคตินั้นจะได้รับการยอมรับก็มีน้อย
|
||||
**การฟังเป็นวิธีที่ดีที่สุดในการรู้ว่าโครงการต้องการอะไร**
|
||||
|
||||
1. **เข้าร่วมรายชื่ออีเมล**: สำหรับหลายโครงการ รายชื่ออีเมลเป็นช่องทางหลักในการสื่อสารเกี่ยวกับการพัฒนาโครงการ
|
||||
ในโครงการขนาดใหญ่ มีรายชื่อผู้รับจดหมายให้เลือกมากมาย
|
||||
ตัวอย่างเช่น โครงการ PostgreSQL มีรายชื่อผู้ใช้ไม่น้อยกว่า 12 รายการ และรายชื่อนักพัฒนาอีก 6 รายการในหน้ารายชื่อผู้รับเมล
|
||||
ฉันขอแนะนำให้คุณปฏิบัติตามรายการหลักที่มุ่งเน้นผู้ใช้และรายชื่อนักพัฒนาหลักที่จะเริ่มฟัง
|
||||
|
||||
2. **ติดตามบล็อก**: บล็อกที่ดูแลโดยนักพัฒนาหลักมักจะให้ข้อมูลเกี่ยวกับสิ่งที่จะเกิดขึ้นในอนาคต
|
||||
และสิ่งที่ต้องทำเพื่อไปถึงที่นั่น ไซต์ Planet รวบรวมข่าวสารและบล็อกจากแหล่งต่างๆ ที่เกี่ยวข้องกับโครงการ
|
||||
หากมีไซต์ planet เช่น planet.gnome.org หรือ planet.mysql.com ให้เริ่มต้นจากที่นั่น เพียงค้นหา Google ด้วยคำว่า "planet <projectname>"
|
||||
|
||||
3. **เข้าร่วมช่อง IRC**: โครงการโอเพ่นซอร์สจำนวนมากมีช่อง Internet Relay Chat (IRC) โดยเฉพาะ ซึ่งนักพัฒนาและผู้ใช้ออกไปเที่ยวเพื่อหารือเกี่ยวกับปัญหาและการพัฒนา
|
||||
ตรวจสอบเว็บไซต์ของโครงการเพื่อดูรายละเอียดว่าช่องดังกล่าวเรียกว่าอะไรและพบเครือข่าย IRC ใด
|
||||
|
||||
**ทำงานกับตั๋ว**
|
||||
โค้ดเป็นหัวใจสำคัญของโครงการโอเพ่นซอร์ส แต่อย่าคิดว่าการเขียนโค้ดเป็นเพียงวิธีเดียวที่จะมีส่วนร่วม
|
||||
การบำรุงรักษาโค้ดและระบบที่อยู่รอบๆ โค้ดมักถูกละเลยในการสร้างคุณสมบัติใหม่ๆ และแก้ไขข้อบกพร่อง
|
||||
มองว่าพื้นที่เหล่านี้เป็นวิธีง่ายๆ ในการก้าวเข้าสู่โครงการ
|
||||
โครงการส่วนใหญ่มีระบบตั๋วแจ้งปัญหาที่เปิดเผยต่อสาธารณะ ซึ่งเชื่อมโยงจากหน้าแรกของเว็บไซต์ของโครงการและรวมอยู่ในเอกสารประกอบ
|
||||
เป็นช่องทางหลักในการสื่อสารระหว่างผู้ใช้และนักพัฒนา การทำให้เป็นปัจจุบันเป็นวิธีที่ดีในการช่วยโครงการ
|
||||
คุณอาจต้องได้รับสิทธิ์พิเศษในระบบตั๋ว ซึ่งหัวหน้าโครงการส่วนใหญ่ยินดีที่จะให้คุณเมื่อคุณบอกว่าต้องการช่วยทำความสะอาดตั๋ว
|
||||
|
||||
4. **วินิจฉัยจุดบกพร่อง**: มักมีการรายงานจุดบกพร่องไม่ดี
|
||||
การวินิจฉัยและคัดแยกจุดบกพร่องสามารถช่วยให้นักพัฒนาประหยัดเวลาโดยต้องอาศัยการทำงานที่ถูกต้องในการหาลักษณะเฉพาะของปัญหา
|
||||
หากผู้ใช้รายงานว่า "ซอฟต์แวร์ไม่ทำงานเมื่อฉันทำ X" ใช้เวลาสักพักเพื่อหาสาเหตุเฉพาะของปัญหานั้น
|
||||
มันทำซ้ำได้หรือไม่? คุณสามารถสร้างชุดขั้นตอนเพื่อทำให้เกิดปัญหาซ้ำๆ ได้หรือไม่ คุณสามารถจำกัดปัญหาให้แคบลง เช่น เกิดขึ้นในเบราว์เซอร์เดียวแต่ไม่เกิดขึ้นอีก หรือหนึ่ง distro แต่ไม่ได้เกิดขึ้นที่อื่น
|
||||
|
||||
แม้ว่าคุณจะไม่รู้ว่าอะไรเป็นสาเหตุของปัญหา แต่ความพยายามที่คุณพยายามจำกัดสถานการณ์ให้แคบลงจะทำให้คนอื่นแก้ไขได้ง่ายขึ้น
|
||||
สิ่งที่คุณค้นพบ เพิ่มลงในตั๋วในระบบบั๊กเพื่อให้ทุกคนได้เห็น
|
||||
|
||||
5. **ปิดจุดบกพร่องที่แก้ไขแล้ว**: บ่อยครั้งจุดบกพร่องได้รับการแก้ไขในโค้ดเบส แต่ตั๋วที่รายงานเกี่ยวกับจุดบกพร่องเหล่านั้นไม่ได้รับการอัปเดตในระบบตั๋ว
|
||||
การทำความสะอาดสิ่งที่ค้างอยู่นี้อาจใช้เวลานาน แต่ก็มีคุณค่าต่อทั้งโครงการ
|
||||
|
||||
เริ่มต้นด้วยการสืบค้นระบบตั๋วสำหรับตั๋วที่มีอายุมากกว่าหนึ่งปีและดูว่ายังมีจุดบกพร่องอยู่หรือไม่
|
||||
ตรวจสอบบันทึกการเปลี่ยนแปลงการเปิดตัวของโปรเจ็กต์เพื่อดูว่าจุดบกพร่องได้รับการแก้ไขและสามารถปิดได้หรือไม่
|
||||
หากทราบว่าได้รับการแก้ไขแล้ว ให้จดหมายเลขเวอร์ชันไว้ในตั๋วแล้วปิด
|
||||
|
||||
ลองสร้างจุดบกพร่องขึ้นใหม่ด้วยซอฟต์แวร์เวอร์ชันล่าสุด
|
||||
หากไม่สามารถสร้างใหม่ด้วยเวอร์ชันล่าสุดได้โปรดทราบว่าในตั๋วแล้วปิด
|
||||
หากยังมีอยู่ให้สังเกตในตั๋วด้วยและเปิดทิ้งไว้
|
||||
|
||||
การทำงานกับโค้ด
|
||||
โปรแกรมเมอร์ทุกระดับประสบการณ์สามารถช่วยเขียนโค้ดในโปรเจ็กต์ได้
|
||||
อย่าคิดว่าคุณจะต้องเป็นอัจฉริยะด้านการเขียนโค้ดจึงจะมีส่วนร่วมกับโปรเจ็กต์ที่คุณชื่นชอบได้อย่างแท้จริง
|
||||
|
||||
หากงานของคุณเกี่ยวข้องกับการแก้ไขโค้ด ให้ตรวจสอบวิธีการที่โปรเจ็กต์ใช้ในการรับโค้ดจากผู้ร่วมให้ข้อมูล
|
||||
แต่ละโปรเจ็กต์มีขั้นตอนการทำงานของตัวเอง ดังนั้นโปรดสอบถามวิธีการดำเนินการก่อนที่คุณจะเริ่มส่งโค้ด
|
||||
|
||||
ตัวอย่างเช่น โครงการ PostgreSQL มีกระบวนการที่เข้มงวดมาก: การแก้ไขโค้ดจะถูกส่งในรูปแบบแพตช์ไปยังรายชื่ออีเมล ซึ่งนักพัฒนาหลักจะพิจารณาทุกแง่มุมของการเปลี่ยนแปลง อีกด้านหนึ่งเป็นโปรเจ็กต์อย่าง Parrot ที่ง่ายต่อการรับสิทธิ์ในโค้ดเบส หากโปรเจ็กต์ใช้ GitHub อาจมีเวิร์กโฟลว์ที่ใช้ฟีเจอร์คำขอดึงของ GitHub ไม่มีสองโครงการที่เหมือนกัน
|
||||
|
||||
เมื่อใดก็ตามที่คุณแก้ไขโค้ด ตรวจสอบให้แน่ใจว่าคุณทำหน้าที่เป็นสมาชิกที่มีความรับผิดชอบของชุมชน และรักษารูปแบบโค้ดของคุณให้ตรงกับโค้ดเบสที่เหลือ โค้ดที่คุณเพิ่มหรือแก้ไขควรมีลักษณะเหมือนกับโค้ดที่เหลือ คุณอาจไม่ชอบรูปแบบการค้ำยันหรือการจัดการช่องว่างสำหรับการเยื้อง แต่การส่งการเปลี่ยนแปลงโค้ดที่ไม่ตรงกับมาตรฐานที่มีอยู่ถือเป็นเรื่องหยาบคาย มันเหมือนกับการพูดว่า "ฉันไม่ชอบสไตล์ของคุณ และฉันคิดว่าสไตล์ของฉันดีกว่า ดังนั้นคุณควรทำในแบบของฉัน"
|
||||
|
||||
6. **ทดสอบตัวเลือกเบต้าหรือรีลีส**: โปรเจ็กต์ใดๆ ก็ตามที่ออกแบบมาให้ทำงานบนหลายแพลตฟอร์มอาจมีปัญหาด้านการพกพาได้ทุกประเภท
|
||||
เมื่อใกล้ถึงการเปิดตัวและมีการเผยแพร่ตัวเลือกเบต้าหรือตัวเลือกการเปิดตัว หัวหน้าโครงการหวังว่าจะได้รับการทดสอบโดยผู้คนจำนวนมากบนแพลตฟอร์มที่แตกต่างกัน
|
||||
คุณสามารถเป็นหนึ่งในคนเหล่านั้นและช่วยให้แน่ใจว่าแพ็คเกจใช้งานได้บนแพลตฟอร์มของคุณ
|
||||
|
||||
โดยทั่วไปคุณเพียงแค่ต้องดาวน์โหลด สร้าง และทดสอบซอฟต์แวร์ แต่มูลค่าของโปรเจ็กต์อาจมีมหาศาลหากคุณใช้การแจกจ่ายหรือฮาร์ดแวร์ที่ไม่ธรรมดา
|
||||
เพียงรายงานกลับมาว่างานสร้างและทดสอบช่วยให้ผู้นำโครงการทราบว่าการเปิดตัวที่กำลังจะเกิดขึ้นนั้นแข็งแกร่ง
|
||||
|
||||
7. **แก้ไขข้อบกพร่อง**: โดยปกติจะเป็นจุดที่ผู้มีส่วนร่วมต้องการเริ่มเขียนโค้ด
|
||||
ง่ายมาก: ค้นหาข้อบกพร่องที่ฟังดูน่าสนใจในระบบตั๋วแล้วลองแก้ไขในโค้ด
|
||||
บันทึกการแก้ไขไว้ในโค้ดหากเหมาะสม
|
||||
เป็นความคิดที่ดีที่จะเพิ่มการทดสอบลงในชุดการทดสอบเพื่อทดสอบจุดของโค้ดที่คุณแก้ไข บางโครงการจำเป็นต้องมีการแก้ไขข้อบกพร่องเพื่อรวมการทดสอบ จดบันทึกเมื่อคุณสำรวจโค้ดเบสที่ไม่คุ้นเคยนี้ แม้ว่าคุณจะไม่สามารถแก้ไขจุดบกพร่องได้ ให้บันทึกสิ่งที่คุณค้นพบไว้ในตั๋วเพื่อเป็นส่วนหนึ่งของความพยายามในการแก้ไข สิ่งที่คุณพบจะช่วยเหลือผู้ที่ตามหลังคุณ
|
||||
|
||||
8. **เขียนแบบทดสอบ**: โปรเจ็กต์ส่วนใหญ่มีชุดทดสอบที่ทดสอบโค้ด แต่ก็ยากที่จะจินตนาการถึงชุดทดสอบที่ไม่สามารถเพิ่มการทดสอบเข้าไปได้อีก
|
||||
ใช้เครื่องมือความครอบคลุมการทดสอบ เช่น gcov สำหรับ C หรือ Devel::Cover สำหรับ Perl เพื่อระบุพื้นที่ในซอร์สโค้ดที่ไม่ได้รับการทดสอบโดยชุดทดสอบ
|
||||
จากนั้นจึงเพิ่มการทดสอบลงในชุดเพื่อให้ครอบคลุม
|
||||
|
||||
9. **ปิดเสียงคำเตือนคอมไพเลอร์**: กระบวนการสร้างสำหรับโปรเจ็กต์ที่ใช้ C จำนวนมากมักจะพ่นแฟล็กคำเตือนคอมไพเลอร์แปลก ๆ ไปที่หน้าจอ
|
||||
คำเตือนเหล่านี้มักจะไม่ใช่ตัวบ่งชี้ปัญหา แต่อาจมีลักษณะเช่นนั้นได้
|
||||
การมีคำเตือนมากเกินไปอาจทำให้คอมไพเลอร์ดูเหมือนกำลังร้องไห้
|
||||
ตรวจสอบว่าโค้ดสามารถซ่อนจุดบกพร่องได้จริงหรือไม่ ถ้าไม่เช่นนั้น การแก้ไขแหล่งที่มาเป็นความเงียบจะช่วยซ่อนผลบวกลวงเหล่านี้ได้
|
||||
|
||||
10. **เพิ่มความคิดเห็น**:
|
||||
เมื่อคุณค้นหาโค้ด คุณอาจพบจุดที่สร้างความสับสน
|
||||
มีโอกาสเกิดขึ้นว่าหากคุณสับสน คนอื่นๆ ก็จะสับสนเช่นกัน บันทึกไว้ในโค้ดและส่งแพตช์
|
||||
ทำงานกับเอกสาร
|
||||
โดยทั่วไปการจัดทำเอกสารจะเป็นส่วนหนึ่งของโครงการที่ใช้เวลาไม่นาน
|
||||
นอกจากนี้ยังอาจต้องทนทุกข์ทรมานจากการเขียนจากมุมมองของผู้ที่คุ้นเคยกับโครงการ แทนที่จะผ่านสายตาของคนที่เพิ่งเข้ามา
|
||||
หากคุณเคยอ่านเอกสารของโครงการโดยคิดว่า "ดูเหมือนว่าคู่มือนี้คาดหวังให้ฉันรู้วิธีใช้แพ็คเกจอยู่แล้ว" คุณจะรู้ว่าฉันกำลังพูดถึงอะไร
|
||||
บ่อยครั้งที่สายตาที่สดใสสามารถชี้ให้เห็นข้อบกพร่องในเอกสารที่ผู้ใกล้ชิดกับโครงการไม่สังเกตเห็น
|
||||
|
||||
11. **สร้างตัวอย่าง**: ไม่มีโปรเจ็กต์ใดที่มีตัวอย่างวิธีปฏิบัติมากเกินไป
|
||||
ไม่ว่าจะเป็นเว็บ API, ไลบรารีของกิจวัตร, แอป GUI เช่น Gimp หรือเครื่องมือบรรทัดคำสั่ง
|
||||
ตัวอย่างที่ดีของการใช้งานที่เหมาะสมสามารถอธิบายการใช้งานซอฟต์แวร์ที่เหมาะสมได้ชัดเจนและรวดเร็วกว่าหน้าเอกสารประกอบ
|
||||
สำหรับ API หรือไลบรารี ให้สร้างโปรแกรมตัวอย่างที่ใช้เครื่องมือนี้ สิ่งนี้สามารถดึงออกมาจากโค้ดที่คุณเขียนได้ โดยตัดทอนให้เหลือเพียงสิ่งจำเป็นเท่านั้น
|
||||
สำหรับเครื่องมือ ให้แสดงตัวอย่างการใช้งานจริงของคุณในชีวิตประจำวัน หากคุณมุ่งเน้นด้านการมองเห็น
|
||||
ลองพิจารณาสร้างภาพหน้าจอของกระบวนการสำคัญ เช่น วิธีการติดตั้งแอพพลิเคชั่น
|
||||
|
||||
ทำงานร่วมกับชุมชน
|
||||
โอเพ่นซอร์สเป็นเพียงบางส่วนเกี่ยวกับโค้ดเท่านั้น ชุมชนทำให้โอเพ่นซอร์สทำงานได้ ต่อไปนี้เป็นวิธีที่คุณสามารถช่วยสร้างมันขึ้นมาได้
|
||||
|
||||
12. **ตอบคำถาม**: วิธีที่ดีที่สุดในการช่วยสร้างชุมชนคือการช่วยเหลือผู้อื่น
|
||||
การตอบคำถาม โดยเฉพาะอย่างยิ่งจากคนที่เพิ่งเริ่มสนใจ เป็นสิ่งสำคัญอย่างยิ่งในการช่วยให้โครงการเติบโตและประสบความสำเร็จ
|
||||
เวลาที่คุณใช้ในการช่วยเหลือผู้เริ่มต้น แม้ว่าพวกเขาจะถามคำถามที่คุณสามารถยกเลิก "RTFM" สั้นๆ ได้อย่างง่ายดาย แต่ก็ให้ผลตอบแทนที่คุ้มค่าในการรับสมาชิกที่กระตือรือร้นอีกคนในชุมชน
|
||||
ทุกคนเริ่มต้นจากที่ไหนสักแห่ง และโครงการต่างๆ จำเป็นต้องมีผู้คนหลั่งไหลเข้ามาอย่างต่อเนื่องหากพวกเขายังคงมีความสำคัญ
|
||||
|
||||
13. **เขียนโพสต์บนบล็อก**:
|
||||
หากคุณมีบล็อก ให้เขียนเกี่ยวกับประสบการณ์ของคุณกับโครงการที่คุณกำลังใช้อยู่
|
||||
บอกเกี่ยวกับปัญหาที่คุณพบในการใช้ซอฟต์แวร์และสิ่งที่คุณทำเพื่อแก้ไข
|
||||
คุณจะช่วยเหลือได้สองวิธี โดยทั้งสองวิธีช่วยให้โครงการนี้อยู่ในใจของผู้อื่นรอบตัวคุณ
|
||||
และด้วยการสร้างบันทึกสำหรับใครก็ตามที่มีปัญหาของคุณในอนาคตและค้นหาคำตอบในเว็บ
|
||||
(บล็อกเกี่ยวกับการผจญภัยทางเทคนิคของคุณยังเป็นวิธีที่ยอดเยี่ยมในการแสดงประสบการณ์ในโลกแห่งความเป็นจริงกับซอฟต์แวร์ดังกล่าวในครั้งต่อไปที่คุณหางานโดยใช้ซอฟต์แวร์ดังกล่าว)
|
||||
|
||||
14. **ปรับปรุงเว็บไซต์**:
|
||||
หากคุณมีทักษะในการออกแบบเว็บไซต์และสามารถช่วยปรับปรุงเว็บไซต์ได้ และส่งผลให้โครงการมีภาพลักษณ์ที่เปิดเผยต่อสาธารณะ ก็ถือว่าใช้เวลาอย่างดี
|
||||
บางทีโปรเจ็กต์อาจใช้การยกเครื่องกราฟิกหรือโลโก้เพื่อระบุโปรเจ็กต์
|
||||
สิ่งเหล่านี้อาจเป็นทักษะที่ขาดในชุมชน ฉันรู้ว่าฉันจะยินดีมากหากได้รับความช่วยเหลือด้านการออกแบบกราฟิกบนเว็บไซต์โครงการของฉัน
|
||||
|
||||
15. **เขียนเอกสารทางเทคนิค**
|
||||
หากคุณสามารถเขียนเกี่ยวกับวิธีการทำงานของแอปพลิเคชันหรือซอฟต์แวร์ได้ คุณสามารถเขียนเอกสารทางเทคนิคเกี่ยวกับแอปพลิเคชันหรือซอฟต์แวร์นั้นได้ โดยเฉพาะโครงการโอเพ่นซอร์สที่ต้องการอัปเดต ปรับปรุง ขยาย หรือสร้างเอกสารทางเทคนิคให้บุคคลทั่วไปได้อ่าน ยิ่งคุณเขียนภาษาอังกฤษธรรมดามากเท่าไรก็ยิ่งดีเท่านั้น ส่วนที่ดีที่สุด คุณไม่จำเป็นต้องเป็นโปรแกรมเมอร์จึงจะเขียนเอกสารทางเทคนิคได้
|
||||
|
||||
สิ่งสำคัญที่สุดคือฟังสิ่งที่คนรอบตัวคุณพูดคุยกัน ดูว่าคุณสามารถรับรู้ถึงความจำเป็นเร่งด่วนหรือไม่ ตัวอย่างเช่น เมื่อเร็ว ๆ นี้ในรายชื่อผู้รับจดหมายของนักพัฒนา Parrot มีการตัดสินใจที่จะใช้ GitHub เป็นระบบตั๋วปัญหา โดยละทิ้งการติดตั้ง Trac แบบเก่าที่พวกเขามี บางคนไม่เห็นด้วยกับการเคลื่อนไหวนี้เนื่องจากไม่มีทางที่จะแปลงตั๋วเป็นระบบของ GitHub ได้ หลังจากทะเลาะกันมาทั้งวัน ฉันก็พูดขึ้นและพูดว่า "ถ้าฉันเขียนตัวแปลงล่ะ" ผู้คนต่างตื่นเต้นกับความคิดนี้ ฉันใช้เวลาเขียนโปรแกรมแปลงตั๋วสำหรับตั๋วมากกว่า 450 ใบ ดังนั้นเราจึงไม่สูญเสียประวัติตั๋วเลย มันเป็นความสำเร็จที่ยิ่งใหญ่. ฉันได้เข้าร่วม และนักพัฒนาหลักยังคงมุ่งเน้นไปที่ธุรกิจการทำงานกับ Parrot
|
||||
|
||||
16. **สอนและช่วยเหลือผู้อื่น**:
|
||||
วิธีที่ดีที่สุดในการเรียนรู้เพิ่มเติมเกี่ยวกับหัวข้อใดหัวข้อหนึ่งคือการพยายามสอนหัวข้อนั้น
|
||||
ครูที่ดีที่สุดคือผู้ที่สามารถอธิบายเรื่องที่ซับซ้อนด้วยตัวอย่างง่ายๆ ดังนั้นคุณต้องพยายามเป็นครูที่ดีที่สุดเพื่อเป็นผู้เรียนที่ดีที่สุดและดีที่สุดในโลกการเขียนโปรแกรมของคุณ การสอนผู้อื่นจะทำให้คุณรู้สึกดีกับตัวเองมากขึ้น และจะช่วยให้คุณได้รับทักษะและความรู้ในวิชาชีพที่ดีขึ้นด้วย เมื่อคุณได้รับความช่วยเหลือจากใครสักคน อย่าเก็บมันไว้คนเดียว แบ่งปันกับผู้อื่น ทำให้โลกน่าอยู่ยิ่งขึ้น
|
||||
@@ -0,0 +1,135 @@
|
||||
# Programcı Olmayan Birinin Yapabileceği Şeyler
|
||||
|
||||
## Dinlemeye Başlayın
|
||||
|
||||
Açık kaynak dünyasında her şey diğer insanlarla ilgilidir.
|
||||
Bir ekibe katılmak istiyorsunuz, bu da topluluğu ve nasıl çalıştığını anlamanız gerektiği anlamına gelir.
|
||||
Bir projeye girip *"Merhaba, bu projenin böyle olması gerektiğini düşünüyorum."* demek genellikle iyi bir yaklaşım olarak görülmez.
|
||||
Bazı projeler bu tür bir yaklaşımı kabul edebilir, ancak proje uzun süredir devam ediyorsa bu tavrın benimsenme ihtimali düşüktür.
|
||||
**Dinlemek, projenin neye ihtiyacı olduğunu anlamanın en iyi yoludur.**
|
||||
|
||||
### 1. **Bir e-posta listesine katılın**
|
||||
Birçok proje için e-posta listesi, proje gelişimi hakkında ana iletişim kanalıdır.
|
||||
Özellikle büyük projelerde birden fazla e-posta listesi bulunabilir.
|
||||
Örneğin, *PostgreSQL* projesinin kullanıcı odaklı en az 12 ve geliştiricilere yönelik 6 farklı e-posta listesi vardır.
|
||||
Başlangıç olarak, ana kullanıcı listesi ve ana geliştirici listesine abone olmanızı öneririm.
|
||||
|
||||
### 2. **Bir blog takip edin**
|
||||
Ana geliştiriciler tarafından tutulan bloglar, gelecekteki sürümler ve gereksinimler hakkında bilgi verir.
|
||||
Bazı projeler için *planet sitesi* (örneğin, `planet.gnome.org` veya `planet.mysql.com`) tüm güncellemeleri bir araya getirir.
|
||||
Google'da `"planet <proje adı>"` şeklinde arama yaparak başlayabilirsiniz.
|
||||
|
||||
### 3. **Bir IRC kanalına katılın**
|
||||
Birçok açık kaynak projesinin geliştiriciler ve kullanıcılar için özel IRC kanalları vardır.
|
||||
Projenin web sitesini ziyaret ederek kanal adı ve bulunduğu IRC ağı hakkında bilgi edinebilirsiniz.
|
||||
|
||||
---
|
||||
|
||||
## Ticket (Hata Bildirimi) ile Çalışmak
|
||||
|
||||
Kod, her açık kaynak projesinin kalbidir, ancak kod yazmak tek katkı yolu değildir.
|
||||
Projelerde yeni özellikler eklemeye ve hataları düzeltmeye odaklanılırken, sistemlerin bakımına yeterince zaman ayrılmayabilir.
|
||||
Bu alanlara katkıda bulunarak bir projeye dahil olabilirsiniz.
|
||||
|
||||
### 4. **Bir hatayı teşhis edin**
|
||||
Hatalar çoğu zaman eksik rapor edilir.
|
||||
Bir hatayı analiz etmek ve sınıflandırmak, geliştiricilere zaman kazandırır.
|
||||
Bir kullanıcı *"Yazılım X yaptığımda çalışmıyor"* dediyse, şu sorulara cevap arayarak sorunu detaylandırabilirsiniz:
|
||||
|
||||
- Hata tekrar edilebilir mi?
|
||||
- Aynı hatayı oluşturmak için belirli adımlar var mı?
|
||||
- Belirli bir tarayıcıda veya işletim sisteminde mi ortaya çıkıyor?
|
||||
|
||||
Bulduğunuz her şeyi hata raporuna ekleyerek projenin ilerlemesine yardımcı olabilirsiniz.
|
||||
|
||||
### 5. **Çözülen hataları kapatın**
|
||||
Birçok hata raporu çözüldükten sonra sistemde açık olarak kalır.
|
||||
Bunları temizlemek zaman alıcı olabilir, ancak proje için çok değerlidir.
|
||||
|
||||
- Eski hata raporlarını (1 yıl veya daha eski) gözden geçirin.
|
||||
- Projenin sürüm notlarını kontrol ederek hatanın çözülüp çözülmediğini belirleyin.
|
||||
- Hatayı yeni sürümde test edin, eğer hata artık yoksa raporu kapatın.
|
||||
|
||||
---
|
||||
|
||||
## Kod ile Çalışmak
|
||||
|
||||
Her seviyeden programcı, bir projeye katkıda bulunabilir.
|
||||
Bir projede kod yazmak istiyorsanız, projeye nasıl katkı sağlandığını öğrenin.
|
||||
Bazı projeler değişiklikleri doğrudan kabul ederken, bazıları kodun önce bir inceleme sürecinden geçmesini ister.
|
||||
|
||||
### 6. **Beta veya aday sürümü test edin**
|
||||
Çoklu platform desteği olan projelerde, yeni sürümlerin test edilmesi büyük önem taşır.
|
||||
Sürüm yöneticileri, beta sürümünü farklı platformlarda test etmek isteyen kullanıcılara ihtiyaç duyar.
|
||||
Yapmanız gereken:
|
||||
|
||||
- Yazılımın son sürümünü indirip derlemek
|
||||
- Farklı donanım ve işletim sistemlerinde çalışıp çalışmadığını kontrol etmek
|
||||
- Test sonuçlarını geliştiricilere bildirmek
|
||||
|
||||
### 7. **Bir hatayı düzeltin**
|
||||
Geliştiricilerin genellikle başladığı nokta burasıdır.
|
||||
|
||||
- Bir hata bularak çözmeye çalışın
|
||||
- Çözümünüzü kod içinde belgeleyin
|
||||
- Gerekirse bir test ekleyin
|
||||
- Eğer hatayı çözemezseniz bile bulgularınızı hata kaydına ekleyin
|
||||
|
||||
### 8. **Bir test yazın**
|
||||
Projelerin test sistemleri genellikle eksik olabilir.
|
||||
*gcov* (C için) veya *Devel::Cover* (Perl için) gibi test kapsamı araçlarını kullanarak eksik alanları tespit edin.
|
||||
Ardından bu alanları kapsayan testler yazın.
|
||||
|
||||
### 9. **Derleyici uyarılarını giderin**
|
||||
Özellikle *C tabanlı projelerde*, derleyiciler bazen uyarılar verir.
|
||||
Bunlar gerçek bir hataya işaret etmese bile, fazla uyarı almak kodun daha karışık görünmesine sebep olabilir.
|
||||
Uyarıyı analiz edin ve gerçekten bir hata olup olmadığını belirleyin.
|
||||
|
||||
### 10. **Yorum ekleyin**
|
||||
Eğer bir kod parçasını anlamakta zorlandıysanız, başkaları da zorlanabilir.
|
||||
Kod içindeki kafa karıştırıcı bölgelere açıklayıcı yorumlar ekleyerek projeye katkıda bulunabilirsiniz.
|
||||
|
||||
---
|
||||
|
||||
## Dokümantasyon ile Çalışmak
|
||||
|
||||
Dokümantasyon genellikle projelerin ihmal edilen kısmıdır.
|
||||
Projeyi uzun süredir geliştirenler, yeni gelenlerin nelere ihtiyacı olabileceğini gözden kaçırabilir.
|
||||
|
||||
### 11. **Bir örnek oluşturun**
|
||||
Kodun veya aracın nasıl çalıştığını gösteren iyi örnekler, en az teknik belgeler kadar önemlidir.
|
||||
|
||||
- API veya kütüphane kullanımı için örnek kodlar yazın
|
||||
- Komut satırı araçları için gerçek hayattan kullanım senaryoları oluşturun
|
||||
- Arayüzlü uygulamalar için ekran görüntüleri ile açıklamalar ekleyin
|
||||
|
||||
---
|
||||
|
||||
## Topluluk ile Çalışmak
|
||||
|
||||
Açık kaynak sadece koddan ibaret değildir, topluluk da büyük önem taşır.
|
||||
|
||||
### 12. **Bir soruya cevap verin**
|
||||
Birine yardımcı olmak, projenin büyümesine katkıda bulunmanın en iyi yollarından biridir.
|
||||
Özellikle yeni başlayanlara karşı sabırlı olun ve onlara yol gösterin.
|
||||
|
||||
### 13. **Bir blog yazısı yazın**
|
||||
Projeyle ilgili deneyimlerinizi paylaşarak iki şekilde yardımcı olabilirsiniz:
|
||||
|
||||
1. Projeye olan ilgiyi artırabilirsiniz.
|
||||
2. Karşılaştığınız sorunlara çözümler sunarak başkalarına rehber olabilirsiniz.
|
||||
|
||||
### 14. **Bir web sitesini geliştirin**
|
||||
Eğer web tasarımı konusunda bilginiz varsa, projenin web sitesini geliştirebilirsiniz.
|
||||
Grafik tasarım ve logo gibi görsel öğeler konusunda da destek sağlayabilirsiniz.
|
||||
|
||||
### 15. **Teknik dokümantasyon yazın**
|
||||
Bir yazılımın nasıl çalıştığını açıklamak için teknik dokümanlar oluşturabilirsiniz.
|
||||
Özellikle açık kaynak projeler, güncellenmiş ve anlaşılır dokümanlara her zaman ihtiyaç duyar.
|
||||
|
||||
### 16. **Öğretin ve başkalarına yardımcı olun**
|
||||
Bir konuyu öğretmek, onu öğrenmenin en iyi yoludur.
|
||||
Açık kaynak projelerine katılan insanlara rehberlik ederek hem kendinizi geliştirir hem de topluluğa katkıda bulunmuş olursunuz.
|
||||
Paylaşılan bilgi, daha fazla kişinin açık kaynak ekosistemine katkıda bulunmasını sağlar.
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user