CONTRIBUTING.hu.md

Közreműködési útmutató

A hibajelentések, funkciókérések és hozzájárulások minden formáját szívesen fogadjuk és bátorítjuk!

Tartalom

• Magatartási kódex
• Kérdések feltevése
• Egy probléma megnyitása
• Funkció-kérések
• Problémák kezelése
• Pull Requestek benyújtása
• Commit üzenetek írása
• Kód-ellenőrzés
• Kódolási stílus
• Eredetiségi tanúsítvány
• Szerzők

Ez az útmutató arra szolgál, hogy egyértelmű elvárásokat fogalmazzon meg a projektben részt vevők számára, hogy együtt fejleszthessük azt, miközben mindenki számára befogadó teret teremt a részvételre. Ezen irányelvek betartása segít biztosítani a pozitív tapasztalatokat a közreműködők és a karbantartók számára.

📖 Magatartási kódex

Kérjük, olvasd el Magatartási kódexünket. Ez mindenkor érvényben van. Elvárjuk, hogy mindenki betartsa, aki hozzájárul ehhez a projekthez. A seggfejként való viselkedést nem toleráljuk.

💡 Kérdések feltevése

Lásd a Támogatási útmutatót. Röviden, a GitHub kérdések nem a megfelelő hely az adott projekted hibakeresésére, hanem a hibák és funkciókérések bejelentésére tartjuk fenn.

📥 Egy probléma megnyitása

Mielőtt problémát hoznál létre, ellenőrizd, hogy a projekt legújabb verzióját használod-e. Ha nem vagy naprakész, először nézd meg, hogy a frissítés megoldja-e a problémádat.

🔒 Biztonsági problémák jelentése

Tekintse át a Biztonsági szabályzatunkat. Ne jelentsen be nyilvános problémát biztonsági résről.

🪲 Hibajelentések és egyéb problémák

Egy nagyszerű módja a projekthez való hozzájárulásnak, ha részletes hibajelentést küldesz, amikor problémával találkozol. Mindig nagyra értékeljük a jól megírt, alapos hibajelentéseket ✌️

Röviden, mivel nagy valószínűséggel fejlesztő vagy, nyiss egy hibajegyet, amire választ szeretnél kapni.

• Új probléma megnyitása előtt olvasd el a dokumentációt és a Támogatási útmutatót.

• Ne nyiss duplikált problémát! Keressd meg a meglévő problémákat, hogy megnézd, nem jelentették-e már korábban a problémád. Ha a probléma már létezik, írd meg megjegyzésben a további információkat. Egyszerűen megjegyezheted, hogy "Nekem is van ilyen problémám", ami segít a leggyakoribb problémák és kérések rangsorolásában.

• Használd inkább a reakciók opciót, ne a hozzászólásokat, ha egyszerűen csak "+1"-et szeretnél adni egy meglévő problémához.

• Teljesen töltsd ki a megadott hibajelentés-sablont. A hibajelentés-sablon minden olyan információt kér, amelyre szükségünk van ahhoz, hogy gyorsan és hatékonyan tudjunk foglalkozni a problémáddal. Legyen világos, tömör és leíró. Adj meg annyi információt, amennyit csak tudsz, beleértve a reprodukálás lépéseit, veremkövetési nyomokat, fordítóhibákat, könyvtárverziókat, operációs rendszer verziókat és képernyőképeket (ha vannak ilyenek).

• Használj GitHub-flavored Markdown-t. Különösen a kódblokkokat és a konzol kimeneteket tedd backtickek közé (```). Ez javítja az olvashatóságot.

💌 Funkció kérések

Szívesen fogadjuk a funkció kéréseket! Bár minden kérést megfontolunk, nem tudjuk garantálni, hogy kérésedet elfogadjuk. Szeretnénk elkerülni a feature creep jelenséget. Lehet, hogy az ötleted nagyszerű, de a projekt keretein kívül esik. Ha elfogadjuk, nem tudunk kötelezettséget vállalni a megvalósítás és a kiadás ütemtervét illetően. Azonban szívesen látjuk, ha benyújtasz egy pull requestet, hogy segítsd!

• Ne nyiss duplikált funkcióigénylést. Először keress rá a meglévő funkcióigénylésekre. Ha találsz egy korábban kért funkciót (vagy egy nagyon hasonlót), kommentáld azt a kérdést.

• Töltsd ki teljesen a megadott probléma sablonját. A funkciókérelem sablonja minden szükséges információt megad ahhoz, hogy eredményes beszélgetést kezdhessünk.

• Pontosan határozd meg a funkció javasolt eredményét, és azt, hogy az hogyan kapcsolódik a meglévő funkciókhoz. Ha lehetséges, csatold a megvalósítás részleteit is.

🔍 Problémák kezelése

A problémák kezelése magában foglalhatja a hibajelentések reprodukálását vagy további információk, például verziószámok vagy reprodukálási utasítások kérését. Minden segítséget, amit egy probléma gyors megoldásához nyújtani tudsz, nagyra értékelünk!

🔁 Pull Requestek benyújtása

Mi szeretjük a pull requesteket! A tároló forkolása és pull request létrehozása előtt a nem triviális változtatások esetén általában az a legjobb, ha először nyitsz egy issue-t, hogy megvitasd a változtatásokat, vagy egy meglévő issue kommentjeiben megbeszéled a probléma megoldására tervezett megközelítésedet.

A legtöbb hozzászólás esetén, miután az első pull requestedet elfogadták és egyesítették, meghívást kapsz a projektbe és push access-t kapsz. :tada:

Megjegyzés: Minden hozzájárulás a projekt licensze alatt lesz kiadva.

• A kisebb jobb. Küldj egy pull requestet hibajavításonként vagy funkcióként. A pull requestnek egyetlen hibajavításhoz vagy funkció megvalósításához tartozó elszigetelt változtatásokat kell tartalmaznia. Ne alakíts át vagy formázz át olyan kódot, amely nem kapcsolódik a változtatáshoz. Jobb, ha több kis pull requestet nyújtasz be, mint egyetlen nagyot. A hatalmas pull-kérelmek átnézése rengeteg időt vesz igénybe, vagy akár el is utasíthatjuk őket.

• Koordináld a nagyobb változtatásokat. Nagy és nem triviális változtatások esetén nyiss egy issue-t, hogy megbeszélhessük a stratégiát a karbantartókkal. Ellenkező esetben azt kockáztatod, hogy sokat dolgozol a semmiért!

• A megértést helyezd előtérbe az okossággal szemben. Írd a kódot világosan és tömören. Ne feledd, hogy a forráskódot általában egyszer írják és gyakran olvassák. Gondoskodj arról, hogy a kód világos legyen az olvasó számára. A célnak és a logikának nyilvánvalónak kell lennie egy kellően képzett fejlesztő számára, ellenkező esetben adj hozzá egy magyarázó megjegyzést.

• Kövesd a meglévő kódolási stílust és konvenciókat. Tarts a kódod összhangban a kódbázis többi részének stílusával, formázásával és konvencióival. Ha lehetséges, ezeket egy linterrel kényszerítjük ki. A következetesség megkönnyíti a jövőbeni felülvizsgálatot és módosítást.

• Tesztlefedettség beépítése. Adj hozzá unit teszteket vagy UI-teszteket, ha lehetséges. Kövesd a tesztek megvalósításának meglévő mintáit.

• Frissítsd a példaprojektet, ha van ilyen, hogy gyakorold a hozzáadott új funkciókat.

• Adj hozzá dokumentációt. Dokumentáljuk a változtatásokat a kóddokumentáció megjegyzéseivel vagy a meglévő útmutatókban.

• Frissítsd a CHANGELOG-ot minden fejlesztésről és hibajavításról. Add meg a megfelelő hibaszámot, ha létezik, és a GitHub felhasználóneved. (példa: "- Fixed crash in profile view. #123 @krisztianmukli")

• Használd a repo alapértelmezett ágát. Új ágak létrehozásához és a pull request beküldéséhez mindig a kódtároló alapértelmezett ágát használd. Általában ez a main, de lehet dev, develop vagy master is.

• Old fel a felmerülő összeolvadási konfliktusokat.

• Azonnal kezeld az esetleges CI-hibákat. Ha a pull request-ed nem épül be vagy nem megy át a teszteken, kérlek, tegyél be egy másik commitot a javításhoz.

• Amikor megjegyzéseket írsz, használj megfelelően felépített mondatokat, beleértve az írásjeleket is.

• Használjon szóközöket, ne tabulátorokat.

📝 Commit üzenetek írása

Kérlek írj konvencionális commit üzeneteket.

1. Válaszd el a tárgyat a törzstől egy üres sorral.
2. Korlátozd a tárgy sort 50 karakterre
3. A tárgysort nagy kezdőbetűvel kezd
4. A tárgysor ne záruljon ponttal
5. Használj felszólító módot a tárgysorban (példa: "Hálózati probléma megoldása").
6. Körülbelül 72 karakteresre tördeld a szövegtörzset
7. A szövegtörzset használd a miért, nem a mit és hogyan magyarázatára (a kódból ez látszik!).
8. A cím elé írd be a commit típusát. (példák: "docs: Elírás javítása", "fix: Hiányzó komponens javítása").

type: A változtatások rövid összefoglalása 50 karakterben vagy annál rövidebben

Szükség esetén adj hozzá részletesebb magyarázatot. Esetleg add meg 
a javított probléma hátterét, stb. A szöveg törzsszövege 
commit üzenete több bekezdésből állhat. További bekezdések 
üres sorok után következnek, és kérjük, hogy megfelelően tömöríts is.

Körülbelül 72 karakterig tördeld fel a szöveget. Bizonyos kontextusokban, 
az első sort a commit tárgyaként kezelik, és a második sor és a 
a szöveg többi része pedig a szövegtörzs. Az összefoglalót elválasztó üres sor 
a törzstől elválasztó rész kritikus (kivéve, ha a törzset teljesen elhagyja); 
a különböző eszközök, mint például a `log`, `shortlog` és `rebase` 
összekeveredhetnek ha a kettőt együtt futtatjuk.

Magyarázd el, hogy milyen problémát old meg ez a commit. Koncentrálj arra, hogy 
miért a változtatás, nem pedig arra, hogy hogyan vagy mit. A kód megmagyarázza 
hogyan vagy mit. A kritikusok és a jövőbeli önmagad is elolvashatja a javítást, 
de lehet, hogy nem értik, hogy egy adott megoldás miért került bevezetésre.
Vannak-e mellékhatásai vagy egyéb nem intuitív következményei ennek a
változtatásnak? Itt a megfelelő hely, hogy elmagyarázd ezeket.

 - A pontok is megfelelnek

 - A felsoroláshoz egy kötőjelet vagy csillagot kell használni, amelyet megelőz
   egy szóközzel, a kettő között üres sorokkal.

A végén tüntesd fel a javított vagy releváns GitHub-issue-t:

Resolves: #123
Lásd még: #456, #789

✅ Kód ellenőrzés

• Nézd át a kódot, ne a szerzőt. Keress és javasolj javításokat anélkül, hogy a szerzőt becsmérelnéd vagy megsértenéd. Adj használható visszajelzést, és indokold meg az érvelésed.

• Nem te vagy a kódod. Amikor a kódodat kritizálják, megkérdőjelezik vagy konstruktívan kritizálják, ne feledd, hogy nem te vagy a kódod. Ne vedd személyeskedésnek a kódod felülvizsgálatát.

• Mindig a legjobbat hozd ki magadból. Senki sem ír hibákat szándékosan. Tedd meg a legjobbat, és tanulj a hibáidból.

• Kérjük, vedd figyelembe az ebben a dokumentumban meghatározott irányelvek megsértését.

💅 Kódolási stílus

A következetesség a legfontosabb. A módosítandó fájl és a teljes projekt meglévő stílusának, formázásának és elnevezési konvencióinak követése. Ennek elmulasztása elhúzódó felülvizsgálati folyamatot eredményez, amelynek során a kódod felszínes aspektusainak frissítésére kell összpontosítanod, ahelyett, hogy a funkcionalitást és a teljesítményt javítanád.

Például, ha minden privát tulajdonságot egy _ aláhúzással jelölünk, akkor az újonnan hozzáadott tulajdonságokat is ugyanígy kell jelölni. Vagy, ha a metódusok elnevezése camelcase használatával történik, mint például thisIsMyMyNewMethod, akkor ne térj el ettől a this_is_my_new_method írásmóddal. Érted a lényeget. Ha kétségeid vannak, kérdezz vagy keress a kódbázisban valami hasonlót.

Ha lehetséges, a stílust és a formátumot linterrel fogjuk kikényszeríteni.

🏅 Eredetiségi tanúsítvány

Fejlesztők eredetiségi tanúsítványa 1.1

Azzal, hogy hozzájárulok ehhez a projekthez, tanúsítom, hogy:

(a) A hozzájárulást részben vagy egészben én hoztam létre, és jogom van a fájlban feltüntetett nyílt forráskódú licenc alapján benyújtani; vagy

(b) A hozzájárulás olyan korábbi munkán alapul, amely legjobb tudomásom szerint megfelelő nyílt forráskódú licenc alá tartozik, és az adott licenc alapján jogom van arra, hogy az adott munkát - akár részben, akár egészben általam készített módosításokkal - ugyanazon nyílt forráskódú licenc alatt nyújtsam be (kivéve, ha engedélyezik, hogy más licenc alatt nyújtsam be), ahogy az a fájlban szerepel; vagy

(c) A hozzájárulást közvetlenül nekem juttatta el egy másik személy, aki az (a), (b) vagy (c) pontot igazolta, és én nem módosítottam azt.

(d) Tudomásul veszem és elfogadom, hogy ez a projekt és a hozzájárulás nyilvános, és hogy a hozzájárulásról (beleértve az összes személyes adatot, amelyet benyújtok vele együtt, beleértve az én aláírásomat is) határozatlan ideig megmarad, és a projektnek vagy az érintett nyílt forráskódú licenc(ek)nek megfelelően tovább terjeszthető.

Nincs barna M&M's

Ha ezt olvasod, gratulálunk kedves felhasználó és (remélhetőleg) közreműködő, hogy idáig eljutottál! Fantasztikus vagy 💯

Hogy megerősítsd, hogy elolvastad ezt az útmutatót, és a lehető legjobban követed, helyezd el ezt az emojit a problémád vagy pull requested tetején: :baseball: :baseball:

🙏 Szerzők

A fájl eredeti példányát @jessesquires írta. Fordította és saját igényei szerint módosította @krisztianmukli.

Kérlek, bátran használd el ezt az útmutatót a saját projektjeidben. Forkoljátok nagyban vagy remixeljétek a saját igényeitekre.

Az ebben a dokumentumban szereplő kijelentések ötleteinek és kifejezéseinek nagy része a következő közösségek munkáján alapul, vagy azok inspirálták őket:

• Alamofire
• CocoaPods
• Docker
• Linux

Elismerésünket fejezzük ki nekik a projektjeikben való együttműködés megkönnyítésére tett erőfeszítéseikért.