search

Pepita73 / webproghu_dev

Webprog.hu apache-php7.2, Drupal 8.5.5
1 stars 1 forks source link

Issue címkék #19

Closed Endyl closed 6 years ago

Endyl commented 6 years ago

Jelenlegi címkék

Munkafolyamat címkék

issue

Ezt az issuet el lehet vállalni és lehet rajta dolgozni, vagy már hozzá van rendelve valakihez.

duplicate

Erre már létezik issue. A további munkát, megbeszélést annál kell folytatni.

wontfix

Ezen az issuen egyelőre nem dolgozunk.

invalid

Téves vagy elavult bejelentés; nem kell foglalkozni vele, le lehet zárni.

A fentiek közül egyik sem

Még nem tudni, hogy mi lesz a sorsa, egylőre ne dolgozzunk rajta. A megfelelő infó címkékkel el kell látni, hogy be lehessen sorolni. Kellene esetleg erre is egy címke, hogy lehessen listázni őket?

Infó címkék

bug

Valami nem, vagy nem megfelőlen működik.

enhancement

Új feature vagy egy meglévő javítása

question

Információra, döntésre van szükség az issue megoldásához/lezárásához. Lehetőleg az vegye le róla, aki rárakta, vagy akihez hozzá lett rendelve.

info

Olyan információt tartalmazhat, amit dokumentálni kellene.

help wanted

Akkor tegyük egy issuera, ha elakadtunk a megoldásával, vagy jelenleg mégsem tudunk foglalkozni vele. Ha elhárult a probléma, vagy van új felelős, vegyük le róla.

good first issue

Egyszerű probléma, kis előismerettel vagy segítséggel megoldható.

Lehet ezt jobban?

Néha látok írásokat githubos címkézési rendszerekről, meg arról, hogy ezek az alap címkék mennyire kezelhetetlenné válnak egy idő után. Szóval akinek van bevált módszere, vagy tud egy jó leírást, ossza meg!

ghost commented 6 years ago

Én ezeket szoktam használni saját projekteknél, de nem mondom, hogy ez a non plus ultra a témában. Valamiért nekem nem jöttek be a github saját címkéi, meg elnevezései.

issue típusa:

mi legyen vele:

a projekt melyik részére vonatkozik:

milyen a prioritása:

egyéb:

A help wanted esetleg még érdekes lehet, de én legtöbbször egyedül dolgozom, aztán azért nem gyakran használom. Ezen kívül még a question is jó, ha nincs egyéb fórum, hogy kérdezzenek, kérdezzünk. Valaki a kérdezőket el szokta hajtani chat-re, fórum-ra, wiki-re, stb., és csak szigorúan a fejlesztéssel kapcsolatos dolgokat engedi issue-ban.

Pepita73 commented 6 years ago

@Endyl listájából indulnék ki, az többeknek ismerős, érthető (szerintem). Pár kérdésem / észrevételem van csak, egyébként szerintem szintén wikibe vele. :)

duplicate

Ezt lehet talán gyorsabban is: aki észre veszi, hogy duplicated, kommentben odaírja (linkelve a másikat) és már zárja is. Így talán kevésbé marad ott sokáig nyitva.

A fentiek közül egyik sem

Szerintem azt is lehet listázni, hogy nincs rajta label, de nekem hirtelen nem sikerült.

wontfix

Ez szerintem felesleges, ez lehet akár "A fentiek közül egyik sem" is.

Többi szerintem így teljesen jó, ha majd gondunk lesz vele, módosítjuk.

Endyl commented 6 years ago

A fentiek nem az én listám, csak gondoltam összefoglalom a jelenlegieket (amik javarészt alap github címkék), hogy addig is tiszta legyen a kép, amíg esetleg ki nem találunk valami jobbat.

Más projekteket követve, amik akár más issuetrackert használnak, meg olvasgatva, hogy mások mit használnak githubon, szerintem ezek az alap címkék elég "homályosak". Én kicsit átalakítanám olyasmi módon, ahogy @inf3rno is írta. Tehát például:

Az egy csoportba tartozó címkék jobbára kölcsönösen kizárják egymást; kivétel a flagek csoport, illetve szerintem adott esetben a "Type: tracking", ha egy másik típus-címke egyidejű jelenléte több információt hordoz.

ghost commented 6 years ago

@Endyl "ez feature, nem pedig bug :) " - Ezen mindig hangosan röhögök. :D Volt már egy párszor. :D

ghost commented 6 years ago

@Endyl Tetszik, de én tovább finomítanám.

A prioritást is jó lenne nevekkel ellátni. Én szívesebben látnék "critical", vagy "priority:critical"-t vörös színnel, mint "P1"-et. A többi is elnevezhető, pl a "P4" lehet "priority:optional" az én változatomból kiindulva. A "P2" lehet "priority:next" vagy "priority:normal" vagy ilyesmi (nem jutott eszembe jobb név most). A "P3" meg "priority:can-wait". Én piros, narancs, sárga és kék színekkel jelölném őket, de ha valaki színvak, akkor használhatjuk egy féle szín sötétedő árnyalatait is.

A status-al kapcsolatban van benne némi redundancia. A "doc needed" / "documented" kiváltható "type:doc" + "status:new"/"status:fixed"-el. A "question" esetében is az állapotváltozást inkább status címkével kellene követni, nem pedig címke eltávolítással. A "status:fixed" ahhoz mondjuk nem illik annyira, de pl egy "status:done" vagy ilyesmi elnevezéssel már mehetne. A "status:ready" helyett meg én inkább "status:review-needed" vagy ilyesmit használnék, mert kifejezőbb. Az active maradhat, mert az assignment nem jelzi magában, hogy éppen dolgoznak rajta, ha valaki túl sokat assign-ol. A "question" érdekes. Mármint lehet olyan issue, ami tisztán csak egy kérdésről szól és ott issue típusnak számít, meg lehet olyan, hogy egy issue-ban felmerül egy kérdés, és ki/be kapcsolgatjuk attól függően, hogy megválaszolta e már valaki. Az utóbbira én jobbnak érzem a "help wanted"/ "discuss" használatát és a "question"-t meghagynám tisztán típusnak. Esetleg mellé lehet tenni plusz egy típusnak, hogy mire vonatkozik a kérdés, pl dokumentációra, tesztekre, stb. de nem kötelező. Erről mi a véleményed?

A status-nál az utolsót egyébként kiválthatja akár az is, hogy lezárjuk az issue-t, de abban igazad van, hogy jobb biztosra menni, főleg ha review kell valamihez.

szerk: Igy utólag belegondolva, különbözik a gondolkodásmódunk. Én pl ha doc needed van, vagy question van, akkor kivinném sub-issue-ba azt a szálat az eredetiből és mondjuk status:blocked-et tennék fel, ha pl question van vagy ilyesmi és emiatt nem mehet tovább. Te meg gondolom egy issue-ban végeznéd ezek ki/be kapcsolgatásával az egészet. Mondjuk a dokumentációval így könnyű elmaradni az én megközelítésemmel. Bár szerintem mindegyik megközelítéssel. ;-) Végülis nincs ellenemre olyan gondolkodásmóddal csinálni, ahogy írod.

Endyl commented 6 years ago

@inf3rno

Prioritások: "P1: critical" > "P2: high" > "P3: normal" > "P4: low"? (és így sorrendben maradnak a label listában :D de lehet priority is a prefix)

A "doc needed" / "documented" kiváltható "type:doc" + "status:new"/"status:fixed"-el.

A "doc needed" és "documented" párost olyan issueknál gondoltam használni, ahol mondjuk valaki lefejleszt egy új feature-t, ami ugye "Type: enhancement" és "Status: fixed" lesz. Ekkor, hogy ne kelljen új issuet nyitni rá és a kettő között folyton navigálni, csak elég rátenni a "doc needed" címkét, és aki ezekre utazik, az meg tudja csinálni. Plusz ha kérdése van az üggyel kapcsolatban, szintén egy issueban marad az info. A "Type: doc" meg olyankor használandó, ha egyéb issuektól független a dokumentációs igény, vagy mondjuk egy korábbi dokumentációt kell javítani.

A "question" esetében is az állapotváltozást inkább status címkével kellene követni, nem pedig címke eltávolítással. A "status:fixed" ahhoz mondjuk nem illik annyira, de pl egy "status:done" vagy ilyesmi elnevezéssel már mehetne.

Ezt nem egészen értem, de a "question"-ről írok lentebb.

A "status:ready" helyett meg én inkább "status:review-needed" vagy ilyesmit használnék, mert kifejezőbb.

Jogos. Szerintem a "needs review" mondjuk jobban hangzik, de a "review-needed" se rossz.

A "question" érdekes. Mármint lehet olyan issue, ami tisztán csak egy kérdésről szól és ott issue típusnak számít, meg lehet olyan, hogy egy issue-ban felmerül egy kérdés, és ki/be kapcsolgatjuk attól függően, hogy megválaszolta e már valaki. Az utóbbira én jobbnak érzem a "help wanted"/ "discuss" használatát és a "question"-t meghagynám tisztán típusnak. Esetleg mellé lehet tenni plusz egy típusnak, hogy mire vonatkozik a kérdés, pl dokumentációra, tesztekre, stb. de nem kötelező.

Én a "Type: discuss"-t tenném minden olyan issuera, ami egyrészt jelenleg kódfüggetlen és vagy döntést igényel, vagy bármilyen egyéb kérdés a projekttel kapcsolatban. A "Flag: question"-t kapcsolgatnám egyéb issuekon, ahol olyan implementációs kérdés merül fel, ami döntést vagy infót igényel, de egyébként tudna vele haladni a felelős. A "Flag: help wanted" meg inkább idő- vagy technikai ismerethiányt jelent, esetleg azt, hogy már túl sokáig foglalkozott vele az illető és nem látja a fától az erdőt (pl: valakit ágyba dönt az influenza, utazik, stb., és kell valaki, aki befejezi az issuet; vagy az ég szerelmére sem jön rá, hogy miért nem működik valami UI komponens, pedig már számtalanszor végiglépkedte debuggerrel, és szeretné, ha valaki más is ránézne friss elmével).

ghost commented 6 years ago

@Endyl

Prioritások: "P1: critical" > "P2: high" > "P3: normal" > "P4: low"? (és így sorrendben maradnak a label listában :D de lehet priority is a prefix)

Oké, én benne vagyok. :-)

A "doc needed" és "documented" párost olyan issueknál gondoltam használni, ahol mondjuk valaki lefejleszt egy új feature-t, ami ugye "Type: enhancement" és "Status: fixed" lesz. Ekkor, hogy ne kelljen új issuet nyitni rá és a kettő között folyton navigálni, csak elég rátenni a "doc needed" címkét, és aki ezekre utazik, az meg tudja csinálni. Plusz ha kérdése van az üggyel kapcsolatban, szintén egy issueban marad az info. A "Type: doc" meg olyankor használandó, ha egyéb issuektól független a dokumentációs igény, vagy mondjuk egy korábbi dokumentációt kell javítani.

Persze vágom, hogy úgy gondoltad. Viszont, ha nem ugyanaz csinálja a doc-ot, mint a fejlesztést, akkor az issue lezártával eltűnik a dolog a süllyesztőben a doc-needed címkével együtt, vagy a b.) változat, hogy a doc-needed blokkolja az issue lezárását, holott a kód megvan, és minden flottul megy. Ezért szoktam úgy, hogy az ilyeneket kiteszem külön issue-ba type:doc címkével, belinkelem hozzá az eredeti issue-t, esetleg hozzászólást, aztán foglalkozik velük a dokumentáló, amikor ideje van. A másik lehetőség, hogy megkötjük, hogy egy issue csak akkor van kész, ha a dokumentáció is megvan hozzá. Igy garantált, hogy lesz doksi mindenhez, és nem halogatjuk megírását, viszont sokkal lassabban fog haladni miatta a fejlesztés.

A "Flag: question"-t kapcsolgatnám egyéb issuekon, ahol olyan implementációs kérdés merül fel, ami döntést vagy infót igényel, de egyébként tudna vele haladni a felelős. A "Flag: help wanted" meg inkább idő- vagy technikai ismerethiányt jelent, esetleg azt, hogy már túl sokáig foglalkozott vele az illető és nem látja a fától az erdőt (pl: valakit ágyba dönt az influenza, utazik, stb.,

Igen, erre írtam, hogy másképp gondolkodunk. Én minden ilyen question-t kitennék külön sub-issue-ba type:question-el vagy type:discuss-al, aztán status:blocked-re raknám a szülő issue-t, amíg a kérdés nem került megválaszolásra. Nyilván az én változatommal sok kicsi issue lenne, a tiédnél meg kevesebb nagy. Mindegyiknek megvan a maga előnye és hátránya. A sok kicsi segít fókuszálni az adott részfeladatra, a kevesebb nagy meg átfogóbb képet ad egy-egy témáról, de hajlamos kezelhetetlen méretűre hízni, ha túl nagyot hasítunk egy-egy issue-val.

Endyl commented 6 years ago

Az jónak tűnik, hogy "doc needed" címkével nem lehet lezárni az issuet (a "Status: fixed"-et viszont megkaphatja; ez jelzi is, hogy mikor végleges a dolog, és van értelme dokumentálni). Így egy helyen marad az infó, plusz az eredeti felelős is alapból kap értesítést, ha érkezik valami kérdés.

De egyébként én tervezek egy "élő" todo listát készíteni, amiben linkek vannak a megfelelő szűrőkkel ellátott issue listákra, így bezártságtól függetlenül nem kell, hogy elkallódjanak dolgok. Csak kell neki találni egy jó helyet, meg megállapodni egy rendszerben, amire normálisan lehet szűrni és érthető, hogy mivel van még tennivaló.

ghost commented 6 years ago

@Endyl Ha úgy gondolod, hogy legyen így nagyobb issue-kkal, akkor nálam nincs akadálya. Csak akkor véglegesítsük és dokumentáljuk le wiki-ben, hogy ez így van, és hogy melyik címke pontosan mit jelent és mikor lehet lezárni egy issue-t, mi az elvárt lifecycle rá, stb... Jó lenne tudni, hogy @Pepita73 mit gondol erről. :-)

Én egyébként félig meddig átvettem most, amit írtál a e2e teszt lib fejlesztéséhez. Eddig működőképes, de nem mindig tudok csak 1 type-ot hozzárendelni egy issue-hoz. Pl amikor mocha-t, vagy hasonló teszt keretrendszert telepítek, bekonfigolom a karma-t, hogy tudjak futtatni teszteket, akkor arra rákerült a test és a feature címke is. Ezeket jó lenne tisztázni, hogy vagy így szórjuk a type flageket és több is mehet egy issue-ra, ha valamennyire kapcsolódik hozzá, vagy szigorúan meghúzzuk a határokat, és pl egy teszt keretrendszer telepítése csak type:test címkét kaphat.

Endyl commented 6 years ago

Igazából én is @Pepita73 (vagy esetleg mások) véleményére várok.

De a felhasználásod leírásával most adtál egy ötletet. A típus szerinti csoportból párat "kiszakítva" és akár igény szerint kibővítve létre lehet hozni egy "Scope" csoportot.

A scope-okban nem vagyok egészen biztos, hogy mi lenne a jó felosztás, a fentiek csak hirtelen felindulásból születtek.

ghost commented 6 years ago

@Endyl Nekem jónak tűnik, én is úgy éreztem, hogy túl sok minden van a type prefix alatt, ami nem feltétlen oda való, mert pl a bug vagy enhancement az issue típusára vonatkozik a documentation, test, stb. meg az issue témájára. A típusból elég csak egy, a témából meg lehet akár többet is választani, bár igazad van, hogy minél több, annál valószínűbb, hogy tracking. Aztán eldönthetjük, hogy tracking-nél felsoroljuk e az összes témát, vagy nem adunk neki egyet sem.

Ha megnézed, azért nem teljes a scope lista, legalábbis ennek az issue-nak nem igazán találok megfelelő scope-ot. Érdemes lenne végignézni az eddigi issue-kat, aztán az alapján bővíteni. Egyébként viszont szerintem jó lesz ezzel a megközelítéssel.

Pepita73 commented 6 years ago

Sziasztok! Pontokba szedem, hogy könnyebb legyen rá hivatkozni.

  1. Szerintem is fontos a megfelelő címkézés, de van egy kis olyan érzésem, mintha túllihegnénk egy kicsit.

  2. Alapvetően minél kevesebb címke, annál kisebb hibázási lehetőség és annál gyorsabb issue felvétel - cserébe viszont annál jobban elolvasandó maga az issue ahhoz, hogy tudjuk is mi a célja. Szerintem optimális "label szám" nincs, vagy széles skálán mozog.

  3. Ahogy eddig látom, a 10 "majdnem gyári" label-ből lett kb 17...20. Ezt soknak tartom.

  4. Prioritás szerintem elég 3: low, high, urgent. Low: minden, amit jó lenne megcsinálni, hiánya nem akadályozza jelentősen a működést. High: sürgős megcsinálni, mert a usereknek / nekünk nagy kényelmetlenséget okoz a hiánya, és / vagy nagy haszonnal jár, ha mielőbb elkészül. Urgent: meghalt a rendszer, fontos oldal vagy feature egyáltalán nem létezik, meghalt a Nagyi, stb.

  5. Típus szerintem bug, feature, egyéb. Utóbbi az, amihez fejleszteni (már) nem kell, de van vele feladat (pl tájékoztatás), de pl simán szűrhető és megtalálható úgy is, hogy nincs rajta bug és nincs rajta feature címke.

  6. "egy issue csak akkor van kész, ha a dokumentáció is megvan hozzá" - alapvetően én ezt pártolom, részben azért is, mert én magam elég lusta dokumentáló vagyok. Ne kezdjek addig új issue-ba, míg nem csináltam meg az előző "nem szeretem" részét is. Egyébként check boxokkal gyönyörűen meg lehet határozni, hogy egy bizonyos issue mikor van kész, emiatt (is) jóval kevesebb label is elég. (Korábban én csináltam viszonylag nagy csapatban, hogy az 1-3 mondatos issue-t úgy kezdtem megoldani, hogy magamnak írtam bele a checklistet. Így nem hagytam ki semmit az általam tervezett megoldásból, valamint ha valaki rá nézett, tudott is szólni, ha szerinte nem jó, nem elég a checklistem. Persze jobb rendesen felvenni az issue-t, hogy elég konkrét legyen, és már akkor legyen checklistje, ha kell.)

  7. Scope: én nem is igazán értem, hogy erre miért van szükség labelként. Szűrni akar rá valaki? Ha igen, akkor is kb a FE / BE elég, potenciális fejlesztőink között ez lehet hasznos, ha valaki csak egyiket szeretné vállalni. Amin meg nincs FE / BE címke, az nem fejlesztési feladat. Esetleg a build vagy devops még mehet mellé.

  8. Gondoljunk arra is, hogy OK, most hárman vagyunk, és értjük, de elképzelhető, hogy többen leszünk és nem mindenki git mágus, nem dolgozott még agilis módszertannal csapatban, stb stb. Ebből a szempontból a minél egyszerűbb szabályrendszer a legjobb.

  9. Ugyanakkor most hárman vagyunk. A jelenlegi címkézés lehet olyan, ami hármunknak megfelel, ha a jövőben alakítani kell, akkor megtesszük. Nekem megfelel és elfogadom, amiben Ti megállapodtok, logikus címkézést szerintem bármilyet hamar megszokok, és nekem nem árt, ha tanulok / megszokok újat. :) Csak jóféle wiki legyen róla.

Endyl commented 6 years ago

Ezeken felül már csak abban nem jutok dűlőre magamban, hogy mi legyen a "doc needed"-szerű címkékkel. Egyrészt jó lenne, ha egy helyen maradna az infó, másrészt, ha át akarjuk nézetni mással a dokumentáció minőségét, akkor kellene egy "doc review needed" is. Vagy ezt a dokumentálóra bízzuk, írja le normálisan a dolgokat; ha meg nem sikerült, akkor később nyílik egy "Type: bug/enhancement", "Scope: docs" issue. Vagy halmozzuk az issuekat és minden dokumentációs igény alapból kap egyet, és ott lehet követni a folyamatot az állapot címkékkel. (Mondjuk ettől függetlenül még az alap issuera ráraknám a doc needed-et, és a csatolt dokumentációs issue megoldásakor állítanám át documented-re.)

Én a részletes címkékre szavazok; gondolom @inf3rno is (ha nem, akkor szólj!). @Pepita73, hajlandó vagy ezekkel dolgozni, vagy próbáljunk valamit egyszerűsíteni?

Pepita73 commented 6 years ago

@Endyl , idézem magam (9):

Nekem megfelel és elfogadom, amiben Ti megállapodtok, logikus címkézést szerintem bármilyet hamar megszokok, és nekem nem árt, ha tanulok / megszokok újat. :)

Tehát a válasz: még jó, hogy hajlandó vagyok.

ghost commented 6 years ago

@Endyl Ha úgy csináljuk, ahogy írtam, hogy kitesszük külön scope:doc issue-ba a dokumentációt, akkor status:blocked lehet a dokumentálandó type:feature issue, és az elején checkbox-ba betehetjük a doc issue-jára a linket. Utána le lehet követni magát a dokumentációt a szokásos status címkékkel, status:review-needed-et is lehet rátenni, stb. Az egyedüli hátránya a dolognak, hogy több issue lesz, mint nélküle. Ugyanígy a question-t is kitenném külön szálba, mondjuk type:discussion-el, vagy ilyesmi. Persze ez az én gondolkodásmódom.

A másik, ami előfordult még tegnap, hogy volt párszor olyan issue-m, ami dependency egy másik issue-nál, de elég csak részben implementálni ahhoz, hogy a másik issue továbbmehessen. Ezeket én úgy döntöttem, hogy nem darabolom fel újabb részekre, hanem csak benyomom a checkbox-ot, ha megvan az a rész, ami a másikhoz kell, és nyitva hagyom alacsonyabb prioritással, hogy lehessen tovább fejleszteni később. Erről mi a véleményed? Szerinted szükséges lenne ezeket is feldarabolni legalább 2 részre eltérő prioritással és csinálni nekik külön tracking-et?

@Pepita73 A scope azért kell, mert ha valaki egy bizonyos témakörrel akar foglalkozni, akkor leszűri scope-al az arra vonatkozó issue-kat, aztán tényleg csinálhatja azt, amit szeret. Én pl most nem nagyon akarok PHP kódot írni vagy CMS-ben kattintgatni, de a teszteket és a bash scripteket szívesen megcsinálom, szóval nekem jó, ha scope:test-re szűrök, és mondjuk azt várom tőletek, hogy hozzatok létre ilyen issue-kat, amikben nagyjából le van írva, hogy mire kell még tesztet írni. Persze csinálhatjuk úgy is, hogy először megírom a tesztet, aztán utána implementáltok, vagy ti írjátok meg a tesztet, ami éppen kell, nekem édes mindegy.

A 20 szerintem jobban átlátható így felosztva 4 kategóriára (status, type, scope, priority), mintha ömlesztve lenne 10, de gondolom ez is egyén függő. Használni nem bonyolult, mindegyik kategóriából kell 1 címke az adott issue-hoz, aztán annyi. A status-t nyomon kell követni, ahogy haladsz az issue-val, a többi címke valószínűleg nem változik.

Endyl commented 6 years ago

@inf3rno

A dokumentálásról meggyőztél, vezessük egyelőre külön issuekba; viszont ahogy írtam, az eredeti issuen megtartanám a doc needed-et, hogy aki mondjuk dokumentálni szeret, végig tudjon menni ezeken is, és szükség esetén létrehozza a doksis issuet. Blockedra nem feltétlenül állítanám az alap issuet, mert működik, és kész van. Esetleg addig ne zárjunk be issuet, amíg doc needed van rajta, aztán felgyűlnének ezek, akkor esetleg változtatunk rajta.

A questiont csak nagyobb horderejű kérdéseknél vinném külön szálba, hogy azért ne legyenek issuek számolatlanul. De a nagy kérdéseknél külön jó ötlet a blocked beállítás és hivatkozás az issuera, ha nem tud tőle haladni a fejlesztés.

Darabolás: Ha egy issue van, akkor az addig nem merge-ölődik developba, amíg nincs teljesen kész. Ha más erre akarja alapozni a munkáját, akkor:

Ezek nem tűnnek túl jó opcióknak; én inkább szétbontanám. Vagy rosszul látom?

Endyl commented 6 years ago

Prefixekre van olyan ötletetek, hogy a flagek a többi után kerüljenek?

Jelenleg Flag > Priority > Scope > Status > Type a sorrend; jó lenne, ha a listában a priority lenne elől, a flagek leghátul, a többiek sorrendje meg szerintem kevésbé fontos.

Endyl commented 6 years ago

Illetve a színekkel még nem barátkoztam meg :D Akinek esetleg van hozzá jobb érzéke, nyugodtan állítsa át, meg ha van jobb ötletetek a tooltipes leírásokra, akkor azt is írjátok át.

Pepita73 commented 6 years ago

_Priority ? Nem szép, de roppant csúnya. :-D

Nekem egyelőre nagyon tetszik, főleg a pár szavas description hozzájuk. Kicsit mondjuk elég színes lett az issue list, dehát nem szemmel kell szűrni. :)

Endyl commented 6 years ago

Nem a Priorityvel van bajom, inkább azzal, hogy a flagek vannak legelöl. Valahogy hátra kéne szorítani őket. De arra az 'X-Flag' jellegű szörnyeknél nincs nagyon jobb ötletem :D

Illetve megnéztem, az underscore nem befolyásolja a sorrendet :(

Endyl commented 6 years ago

Flag helyett jó lesz a Tag szerintem; így jobban fest az issue lista. Már csak az kéne, hogy a Type eggyel előrébb kerüljön valahogy.

Pepita73 commented 6 years ago

Taype :-D

Pepita73 commented 6 years ago

Tájp ...

Endyl commented 6 years ago

Lehetne Set, de az annyira nem tetszik. Esetleg Group, ha nem baj, hogy megelőzné a prioritást.

Bár ahogy nézegetem, szerintem a mostani felállás sem vészes.

Pepita73 commented 6 years ago

Akkor inkább maradjon a Type, az szerintem közérthetőbb.

ghost commented 6 years ago

@Endyl

Ezek nem tűnnek túl jó opcióknak; én inkább szétbontanám. Vagy rosszul látom?

Teljesen igazad van. Ugye én a másikat egyedül csinálom, és nem szórakozok vele branch-ekkel, azért nem esett le. Itt a branch-ek és a dev-be merge-elés miatt muszáj szétbontani.

A tracking-el kapcsolatban van még kérdésem. Most ha van egy feature, aminek kitalálok egy dependency-t, amit külön issue-ban akarok megcsinálni, akkor a feature-höz tartozó issue alapból tracking típusú lesz, vagy maradhat enhancement, és betehetem úgy is a checkbox-ot a dependency issue-val? Nekem az a benyomásom az eddigiek alapján, hogy a tracking csak kimondottan nagy dolgokra vonatkozik, és ilyen apróbb bontásoknál nem lenne jó használni...

Prefixekre van olyan ötletetek, hogy a flagek a többi után kerüljenek?

Ahogy látom ez megoldódott. Én először a type-ot keresem mindig, de majd megszokom, elfogadom, hogy a github ennyit tud sorrend terén. A színek lényegtelen, talán annyi számít, hogy a fontosak, pl bug, critical legyenek pirosak.

Tetszik a Scope:meta, tegnap agyaltam pár percet rajta, hogy mi lenne a megfelelő címke ide, de nem jutott eszembe semmi.

Amúgy én a fontos mappáknak adni szoktam egy # vagy _ vagy hasonló prefix-et Windows-ban, ha előre akarom venni őket. Esetleg megpróbálhatnánk így, ha még nem vagytok elégedettek a sorrenddel. Bár szép tutira nem lesz tőle. :D

Ha a Tag nem jó, akkor szerintem simán lehetne csak X az X-Flag helyett. pl: X:question. De akár zZz:question is. :D

Pepita73 commented 6 years ago

A színek lényegtelen, talán annyi számít, hogy a fontosak, pl bug, critical legyenek pirosak.

Szerintem fontosak a színek is, és nekem tetszik a jelenlegi, szóval ha lehet, maradjon.

Most ha van egy feature, aminek kitalálok egy dependency-t, amit külön issue-ban akarok megcsinálni, akkor a feature-höz tartozó issue alapból tracking típusú lesz, vagy maradhat enhancement, és betehetem úgy is a checkbox-ot a dependency issue-val?

Szerintem beteheted úgy is, csak legyen keresztlink. Én el tudok fogadni 2-3 issue-t epic (tracking) nélkül is.

Apropó, nekem az Epic név jobban tükrözi, mert oda lehet(ne) tenni azokat az infókat is, amelyik egynél több Enhancement-et érint, user story (vagy linkje), stb.

lehetne csak X az X-Flag helyett

Az nem x-flag, hanem x-faktor. És máris hátrébb került egy picit. :-D

Endyl commented 6 years ago

@inf3rno

Most ha van egy feature, aminek kitalálok egy dependency-t, amit külön issue-ban akarok megcsinálni, akkor a feature-höz tartozó issue alapból tracking típusú lesz, vagy maradhat enhancement, és betehetem úgy is a checkbox-ot a dependency issue-val? Nekem az a benyomásom az eddigiek alapján, hogy a tracking csak kimondottan nagy dolgokra vonatkozik, és ilyen apróbb bontásoknál nem lenne jó használni...

A Tracking egy nagy feladat, ami a részfeladatok megoldása által lesz megoldva (ez mondjuk felvet egy branching "problémát", lásd lentebb). Amit itt írsz, arra szerintem a "Status: blocked" a megoldás, és beírod az issueba, hogy melyik másik issuektól függ (opcionálisan a blokkoló issueban is fel lehet venni, hogy melyik issuek függnek tőle).

Tracking és branching: közben lestem git flowtól, és rájöttem, hogy nem probléma; annyi, hogy a Tracking issuenak kell egy branch (amit akár szintén be lehet állítani pull request only módra), és az alfeladatokat erről kell leágaztatni, és ide kell visszamerge-ölni, amíg az egész kész nincsen, amikor vissza lehet vezetni developba is.

@Pepita73 Szerintem a Tracking jobban tükrözi az ilyen issuek mivoltát (nyomon követik egy nagyobb feature/bug/stb. állapotát).

ghost commented 6 years ago

@Endyl Érdekes, hogy a branching-et és a címkéket össze kell egyeztetni, különben ilyen problémákba futunk. Nem számítottam ilyesmire. Szerintem azért most már nagyjából a végére értünk a témának, és lassan le lehet zárni.