v1.0.0
#mainteiner: @zgorcsos
Együttműködési szabályok
- A develop branchet nem használjuk szerkesztésre!
Bármilyen változtatáshoz a develop brench-ből egy feauture branch-et kell származtatni.
Ezen branchek elnevezése szigorúan kötött! Jelenleg az alábbi három prefix közül kell kötelezően az egyiket alkalmazni:
- editorial_: Ilyen címkével ellátott branch-en, kizárólag olyan módosítás végezhető egy létező dokumentumon, amely szerkesztési jellegű változtatást jelent. Nagyon fontos, hogy ilyen branch-en nem végezhető el semmilyen olyan jellegű módosítás, amelyik a dokumentáció szemantikai tartalmán érdemben változtat!
- editorial_ branch-en végezhető módosítások:
- Helyesírási hibák, elírások javítása
- Rossz nyelvi konstrukciók egyértelműsítése, javítása
- Szerencsétlen, nem sikerült megfogalmazások kiigazítása
- editorial_ branch lezárása:
- A szerkesztés lezárása, és a szerkesztési módosítás javaslattétele egy a develop branchre létrehozott MR (merge request segítségével történik).
- Ezen MR célszemélye ("Assign to") a dokumentációban feltüntetett dokumentum legelején "#mainteiner:" címkével feltüntetett felelős, ha nincs ilyen feltüntetve, akkor a fejlesztési vezető
- editorial_ brancról való olvasztást kizárólag az MR célszemélye, vagy a fejlesztési vezető végezheti el!
- editorial_ branch-en végezhető módosítások:
rfc_: Minden érdemi tartalmi módosításnak, új dokumentáció létrehozásának egy rfc_ prefixxel ellátott branch-en kell történnie, függetlenül attól, hogy az adott módosítást ki kívánja végrehajtani a dokumentáción! Ez alól a dokumentum felelőse, és a fejlesztési vezető sem kivétel! (Az RFC a Request For Comments rövidítése és általánosan elterjedt elnevezés együttműködés alapú dokumentációk előállításakor. Az RFC arra hívja fel a közösséget, hogy alakítsanak ki közös konszenzusos álláspontot az adott kérdésben, és a lépésben létrehozott eredmény ezt tükrözze. Ez természetesen lehet a kérés elutasítása is.)
Szabályok az rfc_ branchen:
- Egy rfc_-ben elvégzett módosítás mindig egy a develop brancre létreozott MR (merge request) formájában kerül publikálásra
- Egy rfc_-nek egyértelműen egy tulajdonosa van (editor) nem indítunk konkurens commitot egy rfc-re.
- Ehelyett az érdemi szerkesztést megvalósító együttműködés az rfc-ből származtatott contribution_ prefixxel ellátott branch-en történik, és az eredeti rfc_ branchre létrehozott MR (merge request) formájában ölt testet. Részletesen lásd a contribution_ prefix leírásánál!
Az rfc_ branchekből létrehozott MR-ek „célzása”:
- Csakis a develop branch-re irányulhat - Az MR célszemélye ("assign to") minden esetben a fejlesztési vezető, a Merge kizárólag általa végezhető el!Megengedett ugyanakkor, hogy egy dokumentumra párhuzamosan több rfc_ fusson. (Értelemszerűen ezek nem vonatkoznak ugyanazon részekre, mielőtt rfc-t nyitsz, mindig nézd meg, nincs-e már folyamatban egy az adott témára (dokumentum részre)! Ezért fontosak az érthető, beszédes branch elnevezések!)
contribution_: Ha egy futó rfc_-re a commenteken (legyen az egy nyitott issue, commit, vagy MR comment) túlmutató javaslat szükséges, akkor az alábbiak szerint kell eljárni:
- rfc_ brancből egy contribution_ prefixxel ellátott branch-et kell származtatni
- A módosításokat itt megejteni, majd egy az eredeti rfc_ brancre irányuló MR (merge request) formájában publikálni. Szabályok:
- A szerkesztési szándékot egyeztetni kell a kommunikáció során!
- Az MR célszemélye az rfc eredeti tulajdonosa. A merge-et ő vagy a fejlesztési vezető végezheti el!
- editorial_: Ilyen címkével ellátott branch-en, kizárólag olyan módosítás végezhető egy létező dokumentumon, amely szerkesztési jellegű változtatást jelent. Nagyon fontos, hogy ilyen branch-en nem végezhető el semmilyen olyan jellegű módosítás, amelyik a dokumentáció szemantikai tartalmán érdemben változtat!
Branchek elnevezése:
- A prefixek jobb láthatósága érdekében ne használjuk a branchek elnevezésében a "_" jelet az elnevezés tagolására.
- Javasolt helyette a kötőjelek alkalmazása. CamelCase írásmód is megengedett.
- Tagolás nélküli elnevezések használata kerülendő!
- Ne használjunk rövidítéseket, hacsak azok nem vitán felül közismert és egyértelmű jelölések a szakmai nyelvben!
A develeop branchen lévő dokumentációk is csak "strawman"-nak tekintendőek!
Ha egy dokumentáció végleges változatként elkészül, akkor a fejlesztési vezető MR-t készít és végez a master branchre.
Hogy a félkész dokumentációk ne blokkolják más dokumentációk publikálását, ezért minden rfc_-t addig tartunk meg, amíg a strawman állapota publikálásra kész változatot nem ér el. A merge a develop brancre csak ezután történik, amelyet általában azonnali „develop to master” merge követ.
A fueture brancheket az elvégzett merge-eket követően töröljük.
A nyilvánossá tett dokumentáció hivatkozások mindig a master brancre irányulnak (gitlab linkek)
A branching modell vizuálisan szemléltetve:
