Commit de4882a9a6b63f4cc7f3c074893c06a702f6fe6e

Authored by Görcsös Zoltán
1 parent 4fa6125d

Remove contribution rules content

Showing 1 changed file with 1 additions and 43 deletions   Show diff stats
@@ -19,50 +19,8 @@ @@ -19,50 +19,8 @@
19 * Jó offline MD szerkesztő: [Markdown Monster][#markdownmonster] 19 * Jó offline MD szerkesztő: [Markdown Monster][#markdownmonster]
20 * Vagy egyszerűen használd a gitlab beépített markdown editorát... 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 > # **Follow the rules!** 22 > # **Follow the rules!**
64 23
65 [#headerpic]: <http://gitlab.vonalkod.hu:443/uploads/project/avatar/193/rules.png> 24 [#headerpic]: <http://gitlab.vonalkod.hu:443/uploads/project/avatar/193/rules.png>
66 [#gitlabmddoc]: <https://gitlab.com/help/user/markdown> 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 \ No newline at end of file 26 \ No newline at end of file
  27 +[#markdownmonster]: <https://markdownmonster.west-wind.com/download.aspx>
70 \ No newline at end of file 28 \ No newline at end of file