gyorsított folt eljárás

Nem is olyan régen, két olyan eset állt fenn amikor egy nyílt forrású programban találtunk hibát. Ezek javítása lényegében egy soros folttal javítható lenne, és ráadásul ezt az egysoros foltot akár a hiba beküldője is el tudna készíteni annyira triviális. Ilyen esetben mi a menet:
– nyiss egy bejegyzést a program hibakövető rendszerében
– töltsed fel a foltot amit készítettél
– várj
– várj
….
– majd egyszer észreveszi valaki és beküldi a foltot

Ez a fent említett esetekben számomra túl bürokratikusnak tűnik, hiszen egy tényleg egyszerű hiba javítása akár hónapokig is állhat a hibakövetőben anélkül, hogy azt a felelős fejlesztő észrevegye, a javítást beküldje. Ezt a folyamatot leegyszerűsítendő találtam ki egy ilyen célra írt rendszert, melynek a lényege annyi lenne, hogy az adott bejelentő direkt az “egysoros” foltot tudja csak beküldeni némi kísérőszöveggel karöltve, hogy a folt mit javít. A 2-3 fejlesztő napi rendszerességgel megnézi a listát majd egy kattintásra el tudja vetni vagy a repo-ba küldeni.
Nagyjából ezeket kéne tudnia a programnak (funkcionális terv vázlat :)):
– folt beküldése
– adott jogok kíséretében fejlesztő el tudja vetni vagy fogadni a beküldött foltot
– minimum szavazatmennyiség kell ahhoz, hogy egy folt bekerüljön. (elkerülve ezzel azt, hogy egy fejlesztő megnézi, valamit elnéz és a program borul)
– összeköttetés a verziókövető rendszerrel: a folt elfogadás után rögtön a repo-ban landol.
– várakozó foltok tesztelésre való letöltése: az összes várakozó foltot egy folttá lehet összegyúrni, hogy a fejlesztő azt letöltve ki tudja próbálni, ha ennyire nem bízik a beküldőben.
– maximum változás a foltban: megszabható legyen, hogy hány sor és hány fájl módosulhat egyszerre egy foltban.

Így elkerülhető lenne az, hogy egy levlistán, vagy bugzillában elsikkadjon egy javítás és így a honosítással kapcsolatos hibákat gyorsan be lehetne küldeni, a fejlesztő meg olyan felületet kapna a kezébe, ami átlátható, és könnyen kezelhető.

One thought on “gyorsított folt eljárás

  1. Hasznos ötletnek tűnik, és nem is lenne túl bonyolult a megvalósítása! Annak idején azt hiszem a BitComet-nek volt egy ehhez hasonló “üzenő fala”, ahol adott feature utáni igény esetén plusz egyel nőtt az érték, ellenszavazat esetén pedig csökkent.

    Még azt esetleg érdemes átgondolnod, hogy egy időlimitet is teljesíteni kell a postnak azután, hogy eléri a kritikus szavazatszámot. Például, ha 20 támogató szavazat szükséges ahhoz, hogy az egysoros hiba villogjon az adminisztrátornál, akkor 20 szavazat elérése után azt is figyelje, hogy letelt-e mondjuk a 24 óra. Ha pedig az említett 24 óra letelte előtt valaki ellenjavaslatot tesz, akkor újra visszaesik 19-re az adott post pontja. Ha újra eléri a 20 pontot, akkor újból elindul a 24 óra.

    Természetesen ez csak egy ötlet. Minden esetre jól át kell gondolni a rendszer automatikus felügyeletét, mert könnyen befolyásolhatják a hozzá nem értő felhasználók is, és a legrosszabb esetben csak plusz munkát jelentene a fejlesztőknek a fórum moderálása.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.