Commit ea975dcb72f027c92524e4d585ed8b7de349de34
1 parent
42f0eebd
Editorial clean up
Showing
1 changed file
with
22 additions
and
22 deletions
Show diff stats
contribution.md
| 1 | -### Dokumentum változtatási szabályok: | 1 | +*#mainteiner:* @zgorcsos |
| 2 | +# Együttműködési szabályok | ||
| 2 | 1. A *develop* branchet **nem** használjuk szerkesztésre! | 3 | 1. A *develop* branchet **nem** használjuk szerkesztésre! |
| 3 | -2. Bármilyen változtatáshoz a __develop__ brenchből egy feauture branch-et kell származtatni. | ||
| 4 | - * Ezen branchek elnevezése kötött! Jelenleg az alábbi három prefix közül kell **kötelezően** az egyiket alkalmazni: | ||
| 5 | - 1. **editorial_**: Ilyen cimkével elá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 branchen nem végezhető el **semmilyen** olyan jellegű módósítás, amelyik a dokumentáció szemantikai tartalmán érdemben változtat! | ||
| 6 | - * editorial_ branchen végezhető módosítások: | 4 | +2. **Bármilyen** változtatáshoz a __develop__ brench-ből egy feauture branch-et kell származtatni. |
| 5 | + * 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: | ||
| 6 | + 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! | ||
| 7 | + * editorial_ branch-en végezhető módosítások: | ||
| 7 | - Helyesírási hibák, elírások javítása | 8 | - Helyesírási hibák, elírások javítása |
| 8 | - - Rossz nyelvi konstrukciók egyélrtelműsítése, javítása | ||
| 9 | - - Szerencsétlen, nem sikerült megfogalamazások kiigazítása | 9 | + - Rossz nyelvi konstrukciók egyértelműsítése, javítása |
| 10 | + - Szerencsétlen, nem sikerült megfogalmazások kiigazítása | ||
| 10 | * editorial_ branch lezárása: | 11 | * editorial_ branch lezárása: |
| 11 | - 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). | 12 | - 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). |
| 12 | - 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ő | 13 | - 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ő |
| 13 | - editorial_ brancról való olvasztást kizárólag az MR célszemélye, vagy a fejlesztési vezető végezheti el! | 14 | - editorial_ brancról való olvasztást kizárólag az MR célszemélye, vagy a fejlesztési vezető végezheti el! |
| 14 | - 2. **rfc_**: Minden érdemi tratlami módosításnak, új dokumentáció létrehozáésának egy rfc_ prefixxel elátott branchen kell történnie, függetlenül attól, hogy az adott módosítást ki kivá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ütmüködés alapú dokumentációk előállításakor.*) | 15 | + 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.*) |
| 15 | * Szabályok az rfc_ branchen: | 16 | * Szabályok az rfc_ branchen: |
| 16 | - - Egy rfc_-ben elvégzett módosítás mindig egy a develop brancre létreozott MR (mereg request) formájában kerül publikálásra | 17 | + - 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 |
| 17 | - Egy rfc_-nek egyértelműen egy tulajdonosa van (editor) nem indítunk konkurens commitot egy rfc-re. | 18 | - Egy rfc_-nek egyértelműen egy tulajdonosa van (editor) nem indítunk konkurens commitot egy rfc-re. |
| 18 | - - Ehelyett a szerkesztési együtműködés az rfc-ből származtatott contribution_ prefixxel elátott branchen történik, és az eredeti rfc_ branchre létrehozott MR (merge request) formájában valósul meg. Részletesen lásd a contribution_ prefix leírásánál! | ||
| 19 | - - Az rfc_ branchekből létrehozott MR-ek célzása: | 19 | + - 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! |
| 20 | + - Az rfc_ branchekből létrehozott MR-ek „célzása”: | ||
| 20 | 21 | ||
| 21 | - Csakis a develop branch-re irányulhat | 22 | - Csakis a develop branch-re irányulhat |
| 22 | - Az MR célszemélye ("assign to") minden esetben a fejlesztési vezető, a Merge kizárólag általa végezhető el! | 23 | - Az MR célszemélye ("assign to") minden esetben a fejlesztési vezető, a Merge kizárólag általa végezhető el! |
| 23 | - - 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ézde meg, nincs-e már folyamatban egy rá! Ezért fontosak az érthető, beszédes branch elnevezések!) | ||
| 24 | - 3. **contribution_**: Ha egy futó rfc_-re a commenteken (legyen az egy nyitott issue, commit comment, vagy MR comment) túlmutató javaslat szükséges, akkor az alábbiak szerint kell eljárni: | ||
| 25 | - * rfc_ brancből egy contribution_ prefixxel elátott branchet kell származtatni | ||
| 26 | - * A módosításokat itt megejteni, majd majd egy az eredeti rfc_ brancre irányuló MR (merge request) formájában publikálni. Szabályok: | ||
| 27 | - * A szerkesztési szándékot egyeztetni kell! | ||
| 28 | - * Az MR célszemélye az rfc eredeti tulajdonosa. A merge-et ő vagy a fejhlesztési vezető végezheti el! | 24 | + - 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!) |
| 25 | + 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: | ||
| 26 | + * rfc_ brancből egy contribution_ prefixxel ellátott branch-et kell származtatni | ||
| 27 | + * 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: | ||
| 28 | + * A szerkesztési szándékot egyeztetni kell a kommunikáció során! | ||
| 29 | + * Az MR célszemélye az rfc eredeti tulajdonosa. A merge-et ő vagy a fejlesztési vezető végezheti el! | ||
| 29 | * **Branchek elnevezése:** | 30 | * **Branchek elnevezése:** |
| 30 | * 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. | 31 | * 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. |
| 31 | - * Javasolt helyette a kötöjelek alklamazása. Camel Case írásmód is megengedett. | 32 | + * Javasolt helyette a kötőjelek alkalmazása. CamelCase írásmód is megengedett. |
| 32 | * Tagolás nélküli elnevezések használata kerülendő! | 33 | * Tagolás nélküli elnevezések használata kerülendő! |
| 33 | * 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! | 34 | * 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! |
| 34 | 3. A **develeop** branchen lévő dokumentációk is csak "strawman"-nak tekintendőek! | 35 | 3. A **develeop** branchen lévő dokumentációk is csak "strawman"-nak tekintendőek! |
| 35 | 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. | 36 | 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. |
| 36 | -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 azonali develop to master merge követ. | 37 | +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. |
| 37 | 6. A fueture brancheket az elvégzett merge-eket követően töröljük. | 38 | 6. A fueture brancheket az elvégzett merge-eket követően töröljük. |
| 38 | -7. Dokumentáció hivatkozások mindig a master brancre irányulnak | 39 | +7. A nyilvánossá tett dokumentáció hivatkozások mindig a master brancre irányulnak (gitlab linkek) |
| 39 | 40 | ||
| 40 | A branch modell vizuálisan szemléltetve: | 41 | A branch modell vizuálisan szemléltetve: |
| 41 | - | ||
| 42 | ![][#contribution-branching-model] | 42 | ![][#contribution-branching-model] |
| 43 | 43 | ||
| 44 | -[#contribution-branching-model]:<http://nuget.vonalkod.hu/public/devprocdoc/contribution-branching-model.PNG> | ||
| 45 | \ No newline at end of file | 44 | \ No newline at end of file |
| 45 | +[#contribution-branching-model]:<http://web.vonalkod.hu/fejlesztes/devprocdoc/contribution-branching-model.PNG> |