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ő.