Re: [Tuxletics-devel] Post-0.1.0

[Mauno <ma...@us...>]

Moro... Tuo Petterin tekemä roadman sivu (ircissä topicissa) on oikein 
hyvä tapa lähteä nyt etenemään.

Ois varmasti hyvä jos sovittais nyt yhteinen irc-tapaaminen, jossa 
kävisimme läpi noita ominaisuuksia mitä kukin haluaa ja mitä ei. Tai 
sitten vaan kirjoitetaan suoraan tonne roadmap sivuille vapaammin ensin 
ja muodostetaan sen pohjalta varsinainen roadmap.

Toi kuullostaa ihan hyvältä tavalta, että mietitään ne 1.0:n 
ominaisuudet ensin. Ja "when it's ready" malli on paras aikatauluille.

Mun mielestä aikaisempi johtamismalli on toiminut oikein hyvin meidän 
kohdalla (eli kiistakyssärit ratkaistu keskenään/äänestämällä) eli oon 
core-teamin kannalla.

Ja kuten aikaisemmin sovittiinkin niin usean pelin tuki ensin... Eli 
roadmappiin versioon 1.1 game/event luokat. Kun ollaan tuo game/event 
hierarkia päätetty niin sitten vois sen vanhan koodin 
uudelleenkirjoittaa sen mukaiseksi.

Toi Petterin jo kirjoittama alku tohon roadmappiin on mun mielestä 
oikein hyvä. Että 0.2 versiossa ois valmiina 2 lajia sekä moninpeli 
yhdellä koneella. O.3:nen vois sitten tuoda mukanaan sen 
verkkopelimahdollisuuden ja 0.4:sesta eteenpäin olisikin lajien lisäilyä 
ja hiomista kohti 1.0:aa.





Tero Kuusela wrote:
> Moi!
> 
> 
> Sitten toteutetaan aina seuraavan version tavoitteet ja julkaisun 
> jälkeen tarkistetaan roadmap, sillä tavoitteet voivat muuttua ajan myötä.
> 
> Tuo projektin etenemisestä. Kommentteja tähän?
> 
> Harkinnan arvoinen aihe on myös kehitysmallin tarkentaminen. Tällä 
> hetkellä voisi sanoa, ettei meillä kehittäjissä ole esim. varsinaista 
> core-tiimiä, vaan kaikilla on tasavertaiset oikeudet koodiin. Minulla on 
> periaatteessa projektin "johtajan" status kurssin roolijaon perusteella 
> ja SourceForgen admin-oikeuksien vuoksi.
> 
> Haluammeko että projektilla on "johtaja", jolla on viimeinen sana 
> mahdollisissa kiistakysymyksissä vai onko meillä "core team", joka 
> ratkaisee kiistakysymykset riitelemällä keskenään ja/tai äänestämällä?
> 
> Itse olen nähnyt yhden johtajan mallin toimivan useammin kuin monen 
> johtajan mallin, joten kallistuisin sille kannalle. Yhden johtajan malli 
> onnistuu mielestäni parhaiten kuin kyseinen johtaja sanelee 
> mahdollisimman vähän ja pyrkii kunnioittamaan muita ajatellen projektin 
> etua eikä omaansa, eli mitään rautahanskaista johtajaa emme kaipaa. Jos 
> päädymme yhden johtajan mallin, tällainen pitäisi myös valita.
> 
> Jos ja kun lisää kehittäjiä tulee mukaan, missä vaiheessa heille 
> annetaan oikeudet laittaa koodia suoraan CVS:ään?
> 
> Omasta mielestäni kannattaa odottaa ainakin jonkin aikaa, jotta näkee 
> uuden henkilön olevan kiinnostunut jatkamaan kehitystä pitkäjänteisesti, 
> mutta toisaalta pyrkiä antamaan oikeus pian työn helpottamiseksi.
> 
> Tuo kehittäjien roolista. Sitten hieman konkreettisempaa.
> 
> Kuten kokouksessa sanoin, näen pari mahdollista kehityssuuntaa nyt 
> seuraaviin versioihin. Toinen on se, että hiomme tuon koodin siistiksi 
> yhden lajin kanssa. Toinen puolestaan se, että teemme pikaisesti tuen 
> useille lajeille ja toteutamme toisen lajin tuon testaamiseksi.
> 
> Itse pohdin tätä ja ehdotan seuraavaa. Versioon 0.2.0 meillä ei ole 
> kiire, eli hiotaan siihen mennessä lumipallonheiton koodi sellaiseen 
> kuntoon, että sen pohjalta voi laatia siististi muita lajeja. Tämä 
> tarkoittaa mm. sen erillisen Game/Event-luokan toteuttamista. Tähän 
> päädyin mm. siksi, että jos jätämme koodin kaoottiseksi ja alamme 
> lisäillä lajeja, ne pitää kaikki siistiä myöhemmin.
> 
> Toisaalta tuo alkuvalikko on varsin riippumaton lajeista. Siitä voisimme 
> jakaa nyt asiakas- ja palvelinsovelluksen, joihin rakennamme 0.2.0:aan 
> mennessä tuen useille lajeille. Tällä tavalla 0.3.0 voisi keskittyä 
> uusien lajien luomiseen ja niiden vaatimien ominaisuuksien tukemiseen.
> 
> Tämä ei ole mikään joka kantilta pureskeltu ja aivonystyröitä 
> nyrjäytellen läpi pohdittu ehdotus, eli kommentoikaa rohkeasti ja 
> antakaa parannus- ja vastaehdotuksia.
> 
> Vielä yksi asia näihin yleisiin linjoihin liittyen. Meillä on 
> käytännössä kaksi perustapaa siistiä nykyinen koodi: evoluutio tai 
> uudelleenkirjoitus. Todellinen tapa on jossain tuolla välillä, mutta 
> kumpaa lähempänä? Itse kallistuisin ainakin lumipallonheiton kohdalla 
> lähemmäs harkittua uudelleenkirjoitusta, jossa nyt kun tiedämme mitä 
> tarvitaan pohdimme vähän paremmin miten se kannattaa toteuttaa luokka- 
> ja metoditasolla. Samalla pitäisi pohtia mikä kuuluu siihen 
> Game/Event-luokkaan ja mikä yhden lajin toteuttavaan 
> SnowBallThrow-luokkaamme.
> 
> Että tällaista. Pitkä viesti, mutta koettakaa kommentoida kunnolla. Ja 
> hei, nyt ei ole enää mikään tulipalokiire, miettikää rauhassa :)
> 
> Olen itse ensi viikon lomalla ja lukenen sähköpostia hyvin 
> harvakseltaan, eli minulta ei kannata odottaa vastauksia ajatuksiinne 
> ainakaan ennen 27. päivää.
> 
>