Før du kontakter teamet, indrapporterer en fejl, skriver på forumer osv., bør du læse denne side. Projektet kører mere effektivt og lykkeligt, når regningslinjer og instruktioner på siden følges. Selvom denne side kan lyde lidt barsk, må du ikke være bange for at indrapportere. Teamet er generelt særdeles tålmodigt, medmindre du er en serieforbryder. ;)
Indhold
Husk venligst…
Udviklerne får ingen betaling
Udviklerne gør det, fordi de kan lide det. Ikke fordi du betaler dem. De får ingen penge for at tilfredsstille dig, selvom de vil forsøge at tage dine forslag i betragtning, hvis det er muligt.
Udviklerne arbejder kun i deres fritid
De har måske ingen mulighed for at svare med det samme. Vær tålmodig. De vil svare på et tidspunkt. Hvis de ikke gør, så udfør en venlig ‘bump’ af dit indlæg. Det betyder også, at du hverken bør skrive betydningsløse indlæg eller ekstremt krævende ønsker.
Open-source betyder ikke altid, at dine tilføjelser eller forslag vil blive accepteret.
Teamet er nødt til at bevare kvaliteten af kode og kunstværk. Det vil medføre, at dit arbejde undertiden ikke kan accepteres. Lad dig ikke afskrække. Teamet vil gladeligt give hjælp eller råd.
Retningslinjer
Ved indrapportering af en fejl eller et crash
- Hvis fejlen allerede er indrapporteret til GitHub:
- Hvis fejltilstanden er ‘åben’, prøv om du kan indrapportere yderligere information til teamet.
- Hvis fejlen er ‘lukket’, skal du formentlig afvente næste frigivne version, før rettelsen er med i spillet. Med mindre du selv bygger spillet fra kildekode.
- Hvis fejlen ikke er indrapporteret:
- Gør titlen tydelig og beskrivende - på ENGELSK.
- Inkludér en detaljeret beskrivelse af problemet. Trin for trin instruktioner til pålidelig genskabelse af problemet er særligt hjælpsomme. Igen på ENGELSK.
- Inkludér systeminformation som dit operativsystem, operativsystemsversionsnummer, CPU-model, grafikprocessor (GPU) model og mærke og grafikdriverversion.
- Inkludér stdout.log filen. (Se “Hvor gemmer STK brugerkonfigurationsfilen” på FAQ websiden for information om filplacering.)
- Inkludér skærmbilleder om nødvendigt.
- Hvis du selv kan kompilere STK og køre det i en debugger (som GDB, Valgrind eller Visual Studio Debugger), så kan det hjælpe, hvis du kompilerer STK i debug-tilstand, kører det, og sender output med fra debuggeren.
- Inkludér al anden relevant information.
- Svar på alle spørgsmål teamet stiller, så grundigt du kan.
Når du præsenterer et aktiv eller andet kunstbidrag
- Giv også kildefilerne (.kra, .xcf, .blend, osv.).
- Vær tydelig mht. licensbetingelserne. (Se Licensering for muligheder.)
- Acceptér kritik og se, hvad der kan gøres for at forbedre kunstværket.
- Diskutér med teamet mens det stadig er under udvikling for at få feedback.
- Vær tydelig mht. om dit bidrag er færdigt eller stadig under udvikling.
Når du kommer med forslag til STK
Det er et følsomt område. Selvfølgelig er vi nødt til at acceptere kritik og forslag. Hvis vi ikke gør det, vil det stå i modsætning til open-source idealet: At software er til gavn for alle. Men hvornår bliver et forslag for meget? Her må vi også være på udkig efter konflikter med et andet open-source ideal: At alle bør bidrage, når det er muligt. Så når du kommer med forslag til STK, så spørg venligst dig selv om:
- Har jeg bidraget til SuperTuxKart før?
- Det kan være ved at donere, fremstille objekter, baner, strukturer osv. Tilføjelser fremmer også spillet.
- Hvis jeg selv var i stand til at gøre, hvad jeg beder om, ville jeg være villig til at gøre det?
- Forstår jeg omfanget af den indsats, der er nødvendig for at udføre opgaven?
- Udtrykker jeg i det mindste støtte til teamet og det arbejde de gør?
- Er jeg kommet med mange funktionsanmodninger på det seneste?
- Det lyder måske mundant, men det er et reelt tegn på, om du respekterer teamets arbejde. Hvis du respekterer deres arbejde, er det meget mindre sandsynligt, du vil beklage dig.