#mainteiner: @zgorcsos

Együttműködési szabályok

1. A develop branchet nem használjuk szerkesztésre!

2. 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:

     1. 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!

     2. 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!)

     3. 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!

   • 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!

3. A develeop branchen lévő dokumentációk is csak "strawman"-nak tekintendőek!

4. 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.

5. 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.

6. A fueture brancheket az elvégzett merge-eket követően töröljük.

7. A nyilvánossá tett dokumentáció hivatkozások mindig a master brancre irányulnak (gitlab linkek)

A branch modell vizuálisan szemléltetve: