Yksi asia, josta keskusteltiin ydinkommittiimin tapaamisessa, oli julkaisun laajuus. Lopputuloksena on, että jokaisen julkaisujakson aikana valitaan muutama uusi ominaisuus sisällyttäminen, mutta sitten aina ominaisuuksien jumiutumiseen asti, ihmiset lisäävät ominaisuuspyyntöjä, korjauksia parannuksia varten ja jatkuvat virheraportit. Tämä tarkoittaa, että jokainen julkaisu päättyytyönnetään ulos suunniteltua myöhemmin, ja koska julkaisua kohden tulee niin monia asioita, uusien bugien havaitseminen on vaikeampaa.
Niin kauan kuin-emme ole-jäässä-malli ei toimi. Ihmiset joutuvat odottamaan kuukausia pidempään haluamaansa uusia ominaisuuksia, kuten roskakoria ja kuvankäsittelyä, koska lisäämme edelleen muitaasioita ja sitten meidän on testattava ne kaikki.
Jos pitäisimme julkaisut ominaisuuksiltaan pienempinä, voisimme julkaista uudet tavarat nopeammin ja keskittyä beta-testaukseen, jolloin julkaisut itsensä paremmin. Se on vaikeaa, koska jokaisella on lemmikkinsä ominaisuuksia ja korjauksia, ja jos korjaustiedosto on olemassa, miksi et hankkisi sitä tässä julkaisussa odottamisen sijaan?
Joskus ihmiset valittavat, että akorjaustiedosto on odottanut julkaisua viikkoja tai kuukausia, mutta kukaan ei näytä koskaan tuovan esille, että joskus korjaustiedostot tuovat uusia bugeja, ja mitä enemmän lisäämme kerralla, sitä vaikeampaa se on pitää kaikki hyvin testattuina eri alustoilla, eri hosting-ympäristöissä jne. Joten. Mikä on ehdotuksemme?
Otamme sivun projektinhallinnan maailmasta ja teemme projektisuunnitelman ennen kuin hyppäämme kehityssykliin. Annamme kaikkien ehdottaa ominaisuuksia ja parannuksia, ja valitsemme a rajoitettu määrä sisällytettäväksi ja aseta realistinen julkaisupäivä, josta pidämme kiinni.
Luomme alustavan joukon ominaisuuksia kahdelle seuraavalle julkaisulle, jotka arvioidaan uudelleen seuraavan julkaisun alussa. sykli, jotta ihmiset tietävät, että yhteisö on sitoutunut tiettyihin ominaisuuksiin, toisin kuin epämääräinen “tulevaisuuden julkaisu” merkki, jota käytämme nyt kaikkeen, joka ei sisälly nykyiseen versioon.
Me korjaa bugit, jotka ovat toistettavissa ja vaikuttavat suureen määrään käyttäjiä, ennen kuin keskityt reunakotelon virheisiin tai virheisiin, joita ei ole kuvattu tai toistettu hyvin. Lopetamme huomiomme ohjaamisen sovituista tavoitteista, kun “vinkuva pyörä” päättää, että meidän kaikkien pitäisi keskittyä johonkin muuhun. Aina tulee asioita, jotka ilmaantuvat odottamatta, mutta meidän on tehtävä parempi työhillitsemme itseämme yrittäessämme hiipiä asioita nykyiseen julkaisuun.
Avoimen lähdekoodin projektina saamme enemmän aikaan, kun työskentelemme yhdessä kuin seuraamme yksittäisiä tavoitteita, ja meidän on pidettävä projektimme keskittyneenä yhteisesti sovittuihin tavoitteisiin.
sen sijaan, että seuraamme tangentteja aina, kun yhteisön jäsen alkaa ottaa meidät sellaiseen, riippumatta siitä, onko se noudattaa hienoa ideaa, jota kaikki rakastavat vai ehdotusta, joka perustuu henkilökohtaiseen esityslistalla ja riippumatta siitä, onko kyseessä aloittelija, joka ei tiedä paremmin, vai usein kirjoittaja tai sitoutunut, jolla on vahva mielipide ja kova ääni.
Ongelma tässä on, että se on helppoa saada hajamielinen, joten meidän on luotava rakenne, joka auttaa meitä jatkamaan eteenpäin sen sijaan, että joutuisimme sivuraiteille. Meidän on pidettävä Trac puhtaana nykyistä kehitysjaksoa varten, jotta se sisältää vahvistettuja ominaisuuksia ja virheraportteja, ja kaikki uusien ominaisuuksien ehdotukset siirtyvät eri virstanpylväille.
Mielestämme se on ainakin kokeilemisen arvoinen. Kun olemme päässeet yhteisymmärrykseen siitä, mitä sisällytetään, luomme asianmukaiset Trac-liput ja punt-liput ei-ominaisuusa varten.
pyyntöjä/parannuksia tulevaan julkaisuun, jotta voimme keskittyä. Uudet virheraportit tulevat edelleen nykyiseen virstanpylvääseen. Siitä tulee vaikeaa. Uusia ominaisuuksia on ainakin kymmenkuntaettä minusta tuntuu, että olemme hylänneet useita kertoja, minkä haluaisin nähdä ytimessä, mutta tämän kokeilun osalta aion vain muistuttaa itseäni, että voit tehdä sen laajennuksen avulla.
