Comunicazione

    Prima di contattare gli sviluppatori, segnalare un problema, postare nei forum, ecc, sarebbe opportuno leggere questa pagina. Seguendo pedissequamente le linee guida e le istruzioni riportate in questa pagina, sarà possibile rendere la comunità e il progetto ancora più efficiente. Questo articolo potrebbe sembrare un po’ severo, ma non aver paura di postare. Gli sviluppatori sono tendenzialmente pazienti, sempre che tu non trasgredisca ripetutamente le regole. ;)

    Indice

    Tenete presente che…

    Gli sviluppatori non vengono pagati

    Gli sviluppatori lo fanno perché si divertono, non perché li avete pagati. Non sono pagati per compiacervi, anche se cercheranno di tenere conto dei vostri suggerimenti, se possibile.

    Gli sviluppatori lavorano solo nel loro tempo libero

    Potrebbero non avere la possibilità di rispondere immediatamente, perciò sii paziente. Risponderanno prima o dopo, anche se non gentilmente portano in cima il tuo post. Questo significa inoltre che sarebbe opportuno non fare richieste di poca importanza oppure fare richieste troppo esose.

    Open-source non significa sempre che i vostri contributi saranno accettati.

    Il team deve mantenere alta la quantità del codice e della gara. Questo significa che a volte il vostro lavoro non può essere accettato. Non scoraggiatevi: il team sarà lieto di aiutarvi o di darvi consigli.

    Linee guida

    Quando si segnala un bug o un arresto anomalo del gioco

    • Se il bug è già stato segnalato su GitHub:
      • Se il bug è aperto, verificare se è possibile fornire ulteriori informazioni al team.
      • Se il bug è stato chiuso, probabilmente dovrete aspettare la prossima release per includere la correzione nel gioco, a meno che non vogliate compilare il gioco dai sorgenti.
    • Se il bug non viene segnalato:
      • Il titolo deve essere chiaro e descrittivo.
      • Includere una spiegazione dettagliata del problema. Sono particolarmente utili le istruzioni passo-passo su come riprodurre in modo affidabile il problema.
      • Includere le informazioni sistema, come sistema operativo e versione. Processore grafico (GPU), modello, produttore e versione del driver grafico. Infine, processore (CPU).
      • Includere il file stdout.log. (Per informazioni sulla posizione di questo file, vedere “Dove viene memorizzato da STK il file di configurazione utente” nella pagina FAQ.)
      • Includere schermate, se necessario.
      • Se sei in grado di compilare STK in autonomia e farlo girare in un debugger (ad esempio GDB, Valgrind o Visual Studio Debugger), compila STK in modalità debug, lancialo e invia l’output del debugger.
      • Includere qualsiasi altra informazione ritenuta opportuna.
      • Rispondere alle domande del team nel modo più completo possibile.

    Quando si presenta un’asset o un altro artwork

    • Fornire i file sorgenti (.kra, .xcf, .blend, ecc.)
    • Indicare chiaramente la licenza. (Per le opzioni, vedere Licenze)
    • Accettare le critiche e vedere cosa di può fare per migliorare il proprio artwork.
    • Discutere con il team quando è ancora in corso d’opera per avere dei feedback.
    • Chiarire se il vostro contributo è completo o in corso d’opera.

    Quando si dà un suggerimento per STK

    Questo è un argomento spinoso. Ovviamente accettiamo critiche e suggerimenti—se non lo facessimo, allora è contrario all’ideale dell’open-source: che il software è in beneficio per tutti. Ma quando una richiesta è eccessiva? Per questo dobbiamo anche essere consci dei conflitti relativi all’ideale dell’open-source: ognuno dovrebbe contribuire ove possibile. Perciò, quando si sente la necessità di dare dei suggerimenti per STK, bisogna farsi queste domande:

    • Ho dato un contributo a SuperTuxKart?
      • Si può trattare di donazioni, creazione di oggetti, tracciati, texture, ecc. Anche gli addon aiutano il gioco.
    • Se fossi in grado di fare ciò che chiedono, saresti disposto a farlo?
    • Capisco lo sforzo necessario per svolgere questo compito?
    • Esprimo almeno il mio sostegno al team e al lavoro che svolge ?
    • Ho fatto molte richieste di funzionalità ultimamente?
      • Può sembrare banale, ma in realtà è un segno di rispetto per il lavoro del team. Se si rispetta il loro lavoro, è molto meno probabile che ci si lamenti.