ჩემს ახალ ღია კოდის პროექტს უკვე ჰყავს კონტრიბუტორები. აი, რა გავაკეთე.

Hacktoberfest-ის სულისკვეთებით, ოქტომბრის ბოლო დღეს, მინდოდა გამეზიარებინა ჩემი ისტორია ღია კოდისა და საჯაროდ შექმნის შესახებ.

მე DevRel ვარ. ჩემს ძირითად სამუშაოში ვეხმარები ადამიანებს, რომლებსაც ღია კოდში არასდროს უმუშავიათ, გამოაქვეყნონ თავიანთი პირველი კოდი. ამიტომ, როცა დავიწყე answerLoops-ის შექმნა, ღია კოდის, საკუთარ სერვერზე გასაშვები AI მხარდაჭერის ინსტრუმენტის, ერთი რამ მაწუხებდა: იყო ჩემი საკუთარი პროექტი მართლა მარტივად ასათვისებელი?

რა არის answerLoops?

answerLoops თქვენს ცოდნის წყაროს თქვენი საზოგადოებისთვის პასუხებად აქცევს. მისი დაყენება საკუთარ სერვერზეა შესაძლებელი, ისე რომ შეგიძლიათ გაუშვათ თქვენს ინფრასტრუქტურაზე იმ AI პროვაიდერით, რომელსაც თავად აირჩევთ, ან გამოიყენოთ ჰოსტირებული აპლიკაცია.

აი, სამუშაო პროცესი:

1. შეკითხვა მოდის საზოგადოების არხიდან, როგორიცაა Discord, Slack, Discourse, GitHub ან ვებსაიტის ჩათი.
2. answerLoops ეძებს თქვენს ცოდნაში: თქვენს დოკუმენტაციაში, ფაილებში, GitHub-ის რეპოზიტორიებსა და Notion-ის გვერდებზე.
3. ის ადგენს პასუხის პროექტს წყაროების მითითებით.
4. მეორე AI აგენტი ამოწმებს პროექტს ამ წყაროებთან მიმართებაში.
5. თქვენი გუნდი ამტკიცებს პასუხს, ან თქვენ ჩართავთ ავტომატურ პასუხს იმ შეკითხვებზე, რომლებიც შემოწმებას გაივლის.
6. სასარგებლო გადაწყვეტები ინახება როგორც ცოდნა, ხოლო ცოდნის ხარვეზები გვიჩვენებს, რა აკლია თქვენს დოკუმენტაციას.

სწორედ ამ სამუშაო პროცესის გამო აქვს აზრი ქვემოთ მოცემულ ეტიკეტებს. frontend სამუშაო ეხება დაფას, სადაც გუნდი ამოწმებს და ამტკიცებს პასუხებს. backend სამუშაო ეხება პროცესს და მის უკან არსებულ არხების ინტეგრაციებს.

პროექტი ახალია, ამიტომ ახლა ყველაზე რთული ამოცანაა სწორად დაწყება და ადამიანების მიერ მისი პოვნა. Reddit-ზე და X-ზე დავწერე მის შესახებ. ბევრი ვარსკვლავი არ მოუტანია. ამიტომ შევცვალე, სად ვაკეთებდი ძალისხმევას. ყველას მიღწევის ნაცვლად, კონცენტრირება მოვახდინე დეველოპერებზე, რომლებსაც სურთ რაიმეს შექმნა, და იმაზე, რომ მათთვის დაწყება ადვილი ყოფილიყო.

წინა კვირის განმავლობაში დეველოპერები გამოჩნდნენ. მათ pull request-ები გამომიგზავნეს და მე ისინი გავაერთიანე. ზოგმა გახსნილი issue-დან რაღაც შექმნა. სხვებმა თავად იპოვეს პრობლემა და გაასწორეს.

ვერ დავამტკიცებ, რომ ეს ყველაფერი მიზეზ-შედეგობრივი კავშირია. მაქვს რამდენიმე მონაცემი, და ზოგიერთმა საერთოდ არ აიღო issue. მაგრამ წინასწარ რამდენიმე რამ მოვაწესრიგე და ვფიქრობ, ღირს მათი ჩაწერა ყველასთვის, ვინც იწყებს.

1. Issue-ები ვაეტიკეტე უნარის მიხედვით და არა მხოლოდ ტიპის

თავდაპირველად ჩემს issue-ებს მხოლოდ ჩვეულებრივი ეტიკეტები ჰქონდათ: enhancement, bug, documentation. ეს კონტრიბუტორს ეუბნება, რა ტიპის ცვლილებაა, მაგრამ არა იმას, აქვს თუ არა მას ამასთან საქმე.

დავამატე ორი ეტიკეტი: frontend და backend. ახლა მაქვს 58 ღია issue, საიდანაც 41 ნიშნავს frontend-ს და 33 backend-ს. ვიღაცას შეუძლია ერთ ეტიკეტზე დაჭერით ნახოს მხოლოდ თავისი უნარების შესაბამისი სამუშაო, 58-ის წაკითხვის გარეშე.

ასევე ვიყენებ good first issue-სა და help wanted-ს. good first issue უკვე ბევრმა იცის. უნარის ეტიკეტები ახალი ნაწილია.

ჩემი შერწყმული PR-ების უმრავლესობა ამ ეტიკეტებიდან ერთ-ერთ issue-ს ხურავდა, ამიტომ ისინი საქმიანად გამოიყურებიან. ამას მაინც ფრთხილად ვაფასებ.

ერთი გვერდითი ეფექტი: ახლა მხოლოდ 8 good first issue ბილეთია ღია. ეტიკეტები მხოლოდ მაშინ მუშაობს, როცა მათ უკან სამუშაო დგას, ამიტომ მეტს ვწერ.

2. Issue-ები ისე დავწერე, როგორც სპეციფიკაციები

ამ ნაწილს არასწორად წარმოვაჩენდი, მხოლოდ ეტიკეტებზე რომ დამეწერა.

პირველმა კონტრიბუტორმა აიღო issue, რომელსაც ჰქონდა ეტიკეტები frontend, good first issue და help wanted. ის ისე იყო დაწერილი, რომ ვინმეს, ვინც კოდბაზა არასდროს უნახავს, მაინც შეეძლო დაწყება. მასში იყო:

• სექცია Problem: მონაცემები უკვე გროვდებოდა და ინახებოდა, მაგრამ UI-ში არაფერი აჩვენებდა მათ.
• სექცია Scope: ზუსტად რა უნდა გამოჩნდეს, სად დაიწყოს ძებნა კოდში და როგორი უნდა იყოს ტექსტი.
• სექცია Not in this issue: რისი შეხება არ უნდა მოხდეს, რომ ვინმე არ გადავიდეს უფრო დიდ პროექტზე.
• Acceptance criteria ჩამონათვალის სახით.

ასევე ეწერა, რომ ის უფრო დიდი სათვალთვალო issue-ის ნაწილი იყო, რათა კონტრიბუტორს დაენახა, სად ეგება.

ბუნდოვანი issue, როგორიცაა „გამოაჩინე გამოყენება სტატიის გვერდზე“, მსგავს ახალბედას აიძულებს, გამოიცნოს ფარგლები, ტექსტი და ის, რას ნიშნავს „დასრულება“. კონკრეტული issue კი საშუალებას აძლევს დაიწყოს. თუ ერთი რამის კოპირება მომიწევდა, ეს იქნებოდა.

ყოველი issue ახლა ბოლოვდება კონტრიბუციის სახელმძღვანელოს ბმულით, და ეს უკვე Issues შაბლონშია ჩაშენებული.

3. პროექტი გასაშვებად მარტივი გავხადე

იმაში ვერ დაეხმარები, რაც ვერ გაუშვი. README მოკლე მიმოხილვად გადავწერე და დავამატე CONTRIBUTING სახელმძღვანელო, ასევე issue-ის ფორმები შეცდომებისთვის, ფუნქციებისთვის, ინტეგრაციებისა და დოკუმენტაციისთვის, რათა ახალი შეტყობინებები მოვიდეს საჭირო დეტალებით.

დაყენების პირველი ვერსია საკმარისად კარგი არ იყო. ის Docker-ის გზას გვთავაზობდა, შემდეგ წერდა „ან გაუშვი ნატიურად“, და მე თვითონაც ვერ გეტყოდი, რომელი ამირჩიო. თუ მე დავიბენი, ახალბედაც დაიბნევა. გადავწერე სამ ნაბიჯად: დააკლონე აპლიკაცია, დააყენე მნიშვნელობები ერთ .env-ში და გაუშვი. შემდეგ თავად გავუშვი ნატიური ნაბიჯები ახალ მონაცემთა ბაზაზე, რომ დამერწმუნებინა, რომ მუშაობენ.

მას შემდეგ კონტრიბუტორებმა უკვე გააუმჯობესეს დოკუმენტაცია, მათ შორის დაყენების პროცესის დიაგრამა თვითჰოსტინგის სწრაფ დაწყების გვერდზე.

4. შეფასება სწრაფი იყო, და PR-ები ამას აადვილებდა

PR-ები მოდიოდა ნათელი აღწერით: რა შეიცვალა, რატომ და როგორ გამოვცადოთ. ეს მათ შეფასებას აადვილებდა და სწრაფად შევძელი შერწყმა.

სწრაფი უკუკავშირი მნიშვნელოვანია. პირველად კონტრიბუტორს, რომელიც ორ კვირას ელოდება პასუხს, იშვიათად უბრუნდება.

5. საჯაროდ მადლობა გადავუხადე

კონტრიბუტორები მოხსენიებულები არიან გამოშვების შენიშვნებსა და დოკუმენტაციაში, და მე მათ საჯაროდ მადლობა გადავუხადე. ღია კოდი ძირითადად მოხალისეებზეა დამყარებული, ასე რომ ეს მინიმუმია, რისი გაკეთებაც შემიძლია. ასევე ეს აჩვენებს მომდევნო ადამიანს, რა ხდება, როცა კონტრიბუციას იძლევი.

ასევე დავწერე LinkedIn-ზე და X-ზე.

მადლობა Aaqibhafeez Khan-ს კეთილი სიტყვებისთვის

რაში ვცდებოდი, ან რაში არ ვარ დარწმუნებული

• არ ვიცი, მუშაობდა თუ არა ეტიკეტები 100%-ით. პროექტის სხვა არაფერი ბევრად არ შეცვლილა, მაგრამ რამდენიმე ადგილას დავწერე მის შესახებ, რაც თავისთავად მოზიდავს ადამიანებს.
• ყველამ არ აიღო ეტიკეტირებული issue. ზოგიერთმა კონტრიბუტორმა იპოვა პრობლემა, რომელიც ვინმეს არ დაუფიქსირებია, და ეტიკეტები ამას ვერ ხსნის.
• ნამდვილი გამოცდა განმეორებითი ვიზიტებია. მნიშვნელოვანია, უბრუნდებიან თუ არა ადამიანები მეორე PR-ისთვის.
• მარაგი იწურება. კონტრიბუტორები სწრაფად ასრულებენ good first issue ბილეთებს. კარგი ბილეთების წერა ახლა ჩემთვის რეგულარული საქმეა.

თუ გსურთ ამის გამოცდა

• issue-ები დააეტიკეტეთ საჭირო უნარის მიხედვით და არა მხოლოდ ცვლილების ტიპით.
• ერთი issue დაწერეთ როგორც სპეციფიკაცია: პრობლემა, ფარგლები, რა არის ფარგლებს გარეთ და მიღების კრიტერიუმები.
• დარწმუნდით, რომ ვინმეს შეუძლია პროექტის გაშვება, და თავად გამოსცადეთ ეს ნაბიჯები.
• შეაფასეთ სწრაფად.
• მადლობა გადაუხადეთ ადამიანებს საჯაროდ.

თუ ღია კოდში ახალი ხართ და პირველ PR-თან დახმარება გჭირდებათ, დატოვეთ კომენტარი ან მომწერეთ. სიამოვნებით დაგეხმარებით. ღია issue-ები აქ არის: https://github.com/answerLoops/answerLoops/issues

და თუ თქვენ მართავთ პროექტს: რამ მოიზიდა თქვენი პირველი გარე კონტრიბუტორები?

P.S. თუ ეს წერილი კითხულობთ, ⭐️ რეპოზიტორიის მონიშვნა აქ ასევე ძალიან ეხმარება ადამიანებს მის პოვნაში :)

მადლობა კითხვისთვის!