Komunikacija

    Preden stopite v stik z ekipo, prijavite napako, spišete objavo na forumu itd., najprej preberite to stran. Če sledite tukajšnjim smernicam in navodilom, bosta sodelovanje skupnosti in potek projekta učinkovitejša. Čeprav bo vsebina na tej strani zvenela nekoliko strogo, naj vas to nikar ne odvrne od sodelovanja. Ekipa je v splošnem precej potrpežljiva, razen če se večkrat ne boste držali pravil. ;)

    Vsebina

    Prosimo, imejte v mislih naslednje …

    Razvijalci niso plačani

    Razvijalci delajo na projektu, ker v tem uživajo, ne ker bi jih vi plačali. Niso plačani, da vam ugodijo, bodo pa upoštevali vaši predloge, če bo le mogoče.

    Razvijalci delajo le v svojem prostem času

    Morda vam ne bodo mogli odgovoriti še isti hip. Bodite potrpežljivi – enkrat bodo že odpisali nazaj. Če ne, vljudno opozorite (“bump” v angleščini) na vašo objavo. Ne objavljajte malenkostnih, nepomembnih zahtev ali zelo težkih in velikopoteznih zahtev.

    Odprtokodnost ne pomeni, da bodo vaši prispevki vedno sprejeti

    Ekipa mora skrbeti za kakovost kode in grafik. To včasih pomeni, da vaše delo ne bo sprejeto. Naj vam to ne vzame volje – ekipa vam bo z veseljem pomagala ali svetovala.

    Smernice

    Ko prijavite napako ali sesutje igre

    • Če o napaki že poročajo na GitHubu:
      • Če je poročilo še odprto, preverite, ali lahko ekipi posredujete kakršnekoli dodatne informacije.
      • Če je poročilo zaključeno, boste najverjetneje morali počakati do naslednje izdaje, ko bo popravek na voljo v igri, razen če si igro sami zgradite iz izvorne kode.
    • Če napaka še ni prijavljena:
      • Naj bo naslov jasen in opisen.
      • Vključite podroben opis težave. Še posebej pomagajo navodila s koraki za poustvaritev problema.
      • Vključite sistemske informacije, kot so vaš operacijski sistem, različica operacijskega sistem, grafično kartico (GPE) in njenega izdelovalca, različico grafičnih gonilnikov in model CPE-ja.
      • Priložite datoteko stdout.log. (Glejte “Kam STK shranjuje uporabniško konfiguracijsko datoteko” na strani Pogosta vprašanja, kjer piše, kje se datoteka nahaja.)
      • Po potrebi priložite slike zaslona.
      • Če lahko sami prevedete in zaženete STK v orodju za razhroščevanje (npr. GDB, Valgrind ali Visual Studio Debugger), prosimo, da STK prevedete v načinu za razhroščevanje, ga poženete in priložite izpis na izhodu razhroščevalnika.
      • Po potrebi vključite še druge informacije.
      • Na vsa vprašanja ekipe odgovorite čim natančneje.

    Ko predstavljate nov igralni vizualni/zvočni element ali drug prispevek

    • Priložite izvorne datoteke (.kra, .xcf, .blend itd.).
    • Jasno podajte licenco dela. (Glejte stran Izbira licence za možnosti.)
    • Sprejmite kritike in ugotovite, kako lahko izboljšate umetnino.
    • Dokler delate na umetnini, sodelujte z ekipo, da dobite pravočasne povratne informacije.
    • Jasno povejte, ali je vaš prispevek končan ali še v nastajanju.

    Ko podajate predlog za STK

    To je občutljivo področje. Seveda moramo upoštevati kritike in predloge – če jih ne, delujemo proti enemu od načel odprtokodnosti: naj bo programska oprema vsem v dobrobit. A kdaj zahteva postane preobsežna? Tukaj moramo paziti, da ne pride do kršitve še enega načela odprtokodnosti: naj vsi prispevajo, kjer morejo. Ko torej podajate predlog za igro, se vprašajte:

    • Sem že kdaj kaj prispeval/a za SuperTuxKart?
      • Sem sodijo denarni prispevki, izdelava objektov, prog, tekstur … Celo dodatki štejejo kot pomoč igri.
    • Če bi bil/a sposoben/a storiti to, za kar prosim, bi bil/a pripravljen/a to storiti?
    • Ali razumem, koliko truda bo potrebnega za to nalogo?
    • Ali vsaj aktivno in vidno podpiram ekipo in njen trud?
    • Sem v zadnjem času podal/a veliko zahtev za funkcionalnosti?
      • Vsa ta vprašanja se zdijo banalna, pa vendar so dober pokazatelj tega, ali spoštujete delo ekipe. Če ga, je manj verjetno, da se boste pritoževali.