Commit de4882a9a6b63f4cc7f3c074893c06a702f6fe6e
1 parent
4fa6125d
Remove contribution rules content
Showing
1 changed file
with
1 additions
and
43 deletions
Show diff stats
README.md
| ... | ... | @@ -19,50 +19,8 @@ |
| 19 | 19 | * Jó offline MD szerkesztő: [Markdown Monster][#markdownmonster] |
| 20 | 20 | * Vagy egyszerűen használd a gitlab beépített markdown editorát... |
| 21 | 21 | |
| 22 | -### Dokumentum változtatási szabályok: | |
| 23 | -1. A *develop* branchet **nem** használjuk szerkesztésre! | |
| 24 | -2. Bármilyen változtatáshoz a __develop__ brenchből egy feauture branch-et kell származtatni. | |
| 25 | - * Ezen branchek elnevezése kötött! Jelenleg az alábbi három prefix közül kell **kötelezően** az egyiket alkalmazni: | |
| 26 | - 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! | |
| 27 | - * editorial_ branchen végezhető módosítások: | |
| 28 | - - Helyesírási hibák, elírások javítása | |
| 29 | - - Rossz nyelvi konstrukciók egyélrtelműsítése, javítása | |
| 30 | - - Szerencsétlen, nem sikerült megfogalamazások kiigazítása | |
| 31 | - * editorial_ branch lezárása: | |
| 32 | - - 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). | |
| 33 | - - 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ő | |
| 34 | - - editorial_ brancról való olvasztást kizárólag az MR célszemélye, vagy a fejlesztési vezető végezheti el! | |
| 35 | - 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.*) | |
| 36 | - * Szabályok az rfc_ branchen: | |
| 37 | - - 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 | |
| 38 | - - Egy rfc_-nek egyértelműen egy tulajdonosa van (editor) nem indítunk konkurens commitot egy rfc-re. | |
| 39 | - - 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! | |
| 40 | - - Az rfc_ branchekből létrehozott MR-ek célzása: | |
| 41 | - | |
| 42 | - - Csakis a develop branch-re irányulhat | |
| 43 | - - Az MR célszemélye ("assign to") minden esetben a fejlesztési vezető, a Merge kizárólag általa végezhető el! | |
| 44 | - - 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!) | |
| 45 | - 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: | |
| 46 | - * rfc_ brancből egy contribution_ prefixxel elátott branchet kell származtatni | |
| 47 | - * 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: | |
| 48 | - * A szerkesztési szándékot egyeztetni kell! | |
| 49 | - * Az MR célszemélye az rfc eredeti tulajdonosa. A merge-et ő vagy a fejhlesztési vezető végezheti el! | |
| 50 | - * **Branchek elnevezése:** | |
| 51 | - * 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. | |
| 52 | - * Javasolt helyette a kötöjelek alklamazása. Camel Case írásmód is megengedett. | |
| 53 | - * Tagolás nélküli elnevezések használata kerülendő! | |
| 54 | - * 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! | |
| 55 | -3. A **develeop** branchen lévő dokumentációk is csak "strawman"-nak tekintendőek! | |
| 56 | -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. | |
| 57 | -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. | |
| 58 | -6. A fueture brancheket az elvégzett merge-eket követően töröljük. | |
| 59 | -7. Dokumentáció hivatkozások mindig a master brancre irányulnak | |
| 60 | - | |
| 61 | -A branch modell vizuálisan szemléltetve: | |
| 62 | -![][#contribution-branching-model] | |
| 63 | 22 | > # **Follow the rules!** |
| 64 | 23 | |
| 65 | 24 | [#headerpic]: <http://gitlab.vonalkod.hu:443/uploads/project/avatar/193/rules.png> |
| 66 | 25 | [#gitlabmddoc]: <https://gitlab.com/help/user/markdown> |
| 67 | -[#markdownmonster]: <https://markdownmonster.west-wind.com/download.aspx> | |
| 68 | -[#contribution-branching-model]: <http://nuget.vonalkod.hu/public/devprocdoc/contribution-branching-model.PNG> | |
| 69 | 26 | \ No newline at end of file |
| 27 | +[#markdownmonster]: <https://markdownmonster.west-wind.com/download.aspx> | |
| 70 | 28 | \ No newline at end of file | ... | ... |