Mit sorolunk be az 1.0 milestoneba?

[ghost]

Szándékosan nincsenek benne az alapvető kérdésekkel foglalkozó issue-k az 1.0 milestone-ban?

[Endyl]

Nem szándékos. Csak megcsináltam a milestone-t és ráraktam néhány issue-ra.

Ha bárki úgy gondolja, valami kell az 1.0.0-hoz, nyogudtan rakja rá szerintem. Ha valakinek nem tetszik, majd szól az adott issue-ban.

[ghost]

@Endyl Csak azért kérdeztem meg, mert az 1.0-hoz gyakorlatilag mindegyik issue kell, ami fent van. Beszórom őket abban a milestone-ba. Csinálok egy másikat is later néven. Abba mehet egyelőre minden, ami nem kell 1.0-hoz. Ellenvetés?

[Endyl]

Ha nagyon explicitek akarunk lenni a milestone-oknál is, akkor lehet egy later is, ha arra gondoltál, hogy onnan majd átpakoljuk a következő megfelelő milestone-ba, amikor szükségét látjuk.

Akkor mondjuk lehet olyanokat is csinálni, hogy amire nincs konkrét célunk, beletesszük a laterbe, amíg nem lesz új release. Release után minden later milestone-osról le lehet venni a milestone-t, és akkor egy no:milestone kereséssel felül lehet vizsgálni, hogy mi az, ami már kell a következő verzióba, és mi az, ami ismét a laterbe kerül. És akkor így biztos, hogy mindent átnézünk verziónként, de mindent csak egyszer.

Mondjuk a later jelentése zavar egy kicsit, mert olyan érzést kelt bennem, mintha ezek nem kerülhetnének bele mondjuk a v1.0.0-ba, pedig szerintem ez nem feltétlenül igaz. Lehetne valami kifejezőbb neve; mondjuk unspecified vagy whenever :D Mit gondoltok?

[ghost]

Igazából a külön milestonet minden másnak azért látom szükségesnek, mert biztosított vele, hogy ilyen szempontból minden issuet megvizsgáltunk. A kivétel és újra hozzáadás release után is jó ötlet szerintem, mert annál is ugyanúgy biztosított, hogy mindent újra átnéztünk. Egyébként előre is eldönthető, hogy mit tartunk fontosnak az 1.0 után, ami az 1.1-be fog kerülni, de egyelőre nincs annyi issue.

Egy másik repoban nálam kicsit más a priority labelek jelentése, ott a milestone-on belüli fontosságot jelzik, pl p4 low helyett p4 delayed van, ami azt jelenti, hogy nem sürgős, de a milestone lezárása előtt biztosan meg kell oldani. A p2 imortant meg azt jelenti, hogy a milestone-ban amikor elérjük, akkor azzal az issue-val kell először foglalkozni. Ott a later kb. azt jelenti, hogy later than 1.0, és ha esetleg valamiről eldől, hogy mégsem a release után lesz, akkor berántom az 1.0 milestone-ba. Van még egy másik repoban a todo-brainstorming páros, amit valahol olvastam, hogy jó. A todo biztosan bekerül majd valamelyik milestone-ba, de nincs még eldöntve, hogy melyikbe, a brainstorming meg csak ötletelés, és nem biztos, hogy valaha meg lesz valósítva. Hát végülis nem rosszak azok sem, de nálunk van erre külön status:new / status:confirmed label, amivel jelezhetjük ugyanezt. Ahogy nézem te más logikát követsz, és a pakolászás helyett hagyod abban a milestone-ban az issue-t, ahova eredetileg hozzárendeltük függetlenül attól, hogy későbbi milestone-hoz tartozik, mint amit következőnek release-elni fogunk. Ilyen szemlélettel nem tudom, hogy mi lenne a jó név neki. Talán other, everything else? Az unspecified-et én kerülném, mert github az olyanokra írja, amik nincsenek milestone-ban, szóval ha lehet legyen más neve.

[Endyl]

@inf3rno

Ahogy nézem te más logikát követsz, és a pakolászás helyett hagyod abban a milestone-ban az issue-t, ahova eredetileg hozzárendeltük függetlenül attól, hogy későbbi milestone-hoz tartozik, mint amit következőnek release-elni fogunk.

Ezt nem egészen értem, és azt sem tudom, hogy hol írtam volna ilyet.

Ha valami úgy alakul, hogy másik milestone-ba tartozik, mint ahova eleve tettük, akkor kerüljön át oda, különben nem sok értelme van az ilyenfajta rendszerezésnek.

Érdekes az a megközelítés, hogy a prioritás milestone-on belül értendő. És ha milestone-ra szűrve nézzük az issue-kat, akkor az sem zavaró, ha van P1-es v1.0.0-ra meg v2.0.0-ra is. Ha gondoljátok használhatjuk így is őket.

A minden más milestone-ra közben eszembe jutott egy név, ami szerintem a legjobban leírja: backlog.

Erről eszembe jutott annak a kérdése, hogy hova kerülnek az invalid és wontfix issue-k, hogy ne kelljen folyton újra átnézni őket? Beletesszük mindig a legközlebbi milestone-ba, vagy kell egy never milestone is?

[Pepita73]

Backlog szerintem tök jó. De kell neki milestone? Nem csak egyszerűen az a backlog, ami no - milestone?

Invalid és wontfix szerintem egyszerűen zárható milestone nélkül, nem kell többé foglalkozni vele. Amit nem muszáj, azt ne kategorizáljunk, persze az is gáz, ha valamit kellett volna, de nem tettük... Szóval ez csak a véleményem, a döntést inkább rátok bíznám. 

Üdvözlettel: Horváth Péter

(Mobilról)

[Endyl]

Ha bizonyos rendszerességgel újra akarjuk majd kategorizálni a backlogot, akkor azt úgy célszerű megtenni, hogy minden backlogosról levesszük ezt a milestone-t, és utána minden, a no:milestone keresésben szereplő issue-t beletesszük a megfelelőbe milestone-ba. Így biztosak lehetünk benne, hogy mindent átnéztünk újra. Ha milestone nélkül léteznek egyéb issue-k, akkor azokat "kerülgetni" kell ilyenkor. Mondjuk ha jobban belegondolok, akkor olyan keresést biztos lehet csinálni, hogy no:milestone és nem invalid és nem wontfix, és akkor ha ezen a kettőn nincs milestone, akkor annyira nem kavarhatnak be.

[Pepita73]

A wontfix, invalid csak addig akadály, amíg le nem zárult... :)  A wontfix nekem nem annyira tiszta, hogy mennyire végleges flag, de az invalid azonnal zárható, amikor ezt a label t kapja. Hiszen azért kapja, mert nem jó issue.  Vagy tévedek? 

Üdvözlettel: Horváth Péter

(Mobilról)

[Endyl]

Jah, igaz, azok hamar lezárulnak :D

A wontfix szerintem max akkor változik, ha valaki előtúr valami régi ilyen issue-t, amiről azóta megváltozott a véleményünk. De szerintem gyakoribb, hogy mindig új issue nyílik valamiről, semmint hogy előkeressen az átlag felhasználó bármit is.

[ghost]

Ezt nem egészen értem, és azt sem tudom, hogy hol írtam volna ilyet.

Szerintem a "mintha nem kerülhetnének bele" részt értelmeztem máshogy, mint ahogy te gondoltad.

Erről eszembe jutott annak a kérdése, hogy hova kerülnek az invalid és wontfix issuek, hogy ne kelljen folyton újra átnézni őket? Beletesszük mindig a legközlebbi milestone-ba, vagy kell egy never milestone is?

Nekem jó a backlog. Szerintem is felesleges külön milestoneba tenni az invalidet meg a wontfixet, maradhatnak milestone nélkül. Szerintem a wontfixet is le lehet zárni. Elvileg csak annyi a különbség az invalid és aközött, hogy a wontfix valid, viszont úgy döntöttünk, hogy nem éri meg foglalkozni vele. Pl a felhasználók 1%-a igényelné csak a featuret, stb. Alapból csak az open issuekat nézzük release utáni újrarendezésnél, úgyhogy nem gond, ha nincsenek ezek backlogban, mert úgyis closedek. A wontfixnél végülis lehet kétféle módszert alkalmazni. Az egyik, hogy lezárjuk, aztán majd újranyitjuk ha mégis meggondoljuk magunkat. A másik, hogy nyitva hagyjuk, és bekerül az is a backlogba, aztán újrarendszerezésnél eldöntjük, hogy megcsináljuk, vagy várjunk e még vele. Igazából csak attól függ, hogy mennyire tekintjük véglegesnek a vele kapcsolatos döntést.

Amit talán érdemesebb lenne megbeszélni, hogy az új issuek milyen folyamattal kerülnek bele egy-egy milestoneba. Lehet úgy, hogy amíg status: new, addig maradhat milestone nélkül, aztán amikor status: confirmedre vált, akkor választunk neki. Lehet úgy is, hogy eleve a backlogba kerül, és amikor status: confirmedre vált, akkor választunk neki milestonet is egyúttal, ha előre akarjuk hozni. Esetleg egyéb ötlet?

Érdekes az a megközelítés, hogy a prioritás milestone-on belül értendő. És ha milestone-ra szűrve nézzük az issue-kat, akkor az sem zavaró, ha van P1-es v1.0.0-ra meg v2.0.0-ra is. Ha gondoljátok használhatjuk így is őket.

Meg lehet próbálni, de én nem ragaszkodom hozzá. Szerintem akkor van értelme, ha a mostaninál jóval kevesebb dolog van 1-1 milestone-ban, és többet is lehet vinni párhuzamosan legalább megbeszélés szintjén (0.1, 0.2, stb). Én sokszor elunom azt a milestonet, amit éppen csinálok, aztán amíg megjön az ihlet, addig előkészítem a többit, átgondolom, hogy azok hogy lesznek, esetleg megoldok discuss jellegű issuekat. Gondolkozok rajta, hogy valami párhuzamos fejlesztési módszert is kitalálok, hogy implementálni meg mergelni is lehessen így, de az még egy elég kezdetleges ötlet...

[Endyl]

Szerintem nincs szükség a wontfixekre a backlogban. Ha azokat akarjuk újraértékelni, akkor simán tudunk rájuk keresni, de gondolom ez nem fog sűrűn megtörténni.

Az issue besorolásnál az nekem jobban tetszik, hogy new esetén nincs milestone, és amikor confirmed lesz, bekerül valahova. Utána meg még mindig lehet rakosgatni milestone-ok között, amíg nincs valami release ágon, és jobbnak látjuk előbb vagy később implementálni.

Annyiból jobb a milestone-onkénti prioritás, hogy nem feltétlenül kell újrarangsorolni őket e szerint, amikor aktuálissá válik egy új milestone. De nekem mindegy.

Egyelőre azzal nem bonyolítanám az életünket, hogy több milestone-t fejlesztünk egyszerre. Max ha valaki nagyon előre akar dolgozni egy issue-n, tegye bele egy branchbe, amire nem csinál PR-t, amíg aktuális nem lesz a milestone-ja. Persze ilyenkor meg előjönnek olyanok, hogy conflict keletkezik, merge-ölni, rebase-elni kell, stb.

[ghost]

Az issue besorolásnál az nekem jobban tetszik, hogy new esetén nincs milestone, és amikor confirmed lesz, bekerül valahova. Utána meg még mindig lehet rakosgatni milestone-ok között, amíg nincs valami release ágon, és jobbnak látjuk előbb vagy később implementálni.

Oké, akkor legyen így. Szóval ha van confirmed milestone nélkül, akkor tudjuk, hogy azzal foglalkozni kell, hogy bekerüljön valahova. Akkor ezt esetleg valami workflowos wikibe dokumentáljuk le, ha úgy gondolod, aztán végeztünk.

Annyiból jobb a milestone-onkénti prioritás, hogy nem feltétlenül kell újrarangsorolni őket e szerint, amikor aktuálissá válik egy új milestone. De nekem mindegy.

Tőlem használhatjuk úgy is, egyelőre nem kell semmin változtatni hozzá, mert csak 1 milestone van. Talán a wikibe bekerülhet ez is, ha úgy gondolod.

[Endyl]

A hotfix issue-k hova kerülnek?

[Pepita73]

A hotfix issue-k hova kerülnek?

Szerintem szimplán no:milestone. Ha egyszer hotfix, akkor ne pöcsöljünk az adminisztrációval, hanem fix, PR, CR, relase gyorsan. Milestone szerintem 'állomáshely', oda akkor jutunk el, ha a benne lévő feladatokat sikerrel elvégeztük. A hotfix-el nem akarunk valami nagyobb célt elérni, ellenben qq.. gyorsan meg akarjuk menteni a menthetőt. Nem kell besorolni sehova szerintem.

[ghost]

@Endyl Szerintem sem kell besorolni, nem tartozik egyik release-hez sem. Esetleg csinálhatunk neki külön hotfix milestonet, ha muszáj besorolni.

[Endyl]

Nekem sem jutott eszembe elsőre normális hely nekik a milestone-ok között. Azt meg pláne nem gondoltam, hogy a megoldása előtt vesződni kéne a besorolásával :) De ha utólag lett volna valami frappáns hely nekik, az nem lett volna baj.

De egyelőre szerintem is mehetnek milestone nélkül.