**v1.0.0** 
  

  *#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 branching modell vizuálisan szemléltetve:
  

  ![][#contribution-branching-model]
  

  [#contribution-branching-model]:<http://web.vonalkod.hu/fejlesztes/devprocdoc/contribution-branching-model.PNG>