Antes que vás contactar a equipa, reportar um bug, postar nos fórums etc., deves ler cuidadosamente esta página. Seguir estas diretrizes e instruções fará a comunidade e o projeto funcionarem mais eficientemente e em alegria! Apesar de este artigo soar um pouco duro, por favor não tenhas medo de postar. A equipa é geralmente muito paciente, a não ser que sejas um infrator recorrente. ;)
Conteúdos
Por favor, tem em mente que…
Os desenvolvedores não são pagos
Os desenvolvedores fazem isto porque gostam, não porque lhes pagam. Não são pagos para te agradar, mas tentarão ter as tuas sugestões em conta se possível.
Os desenvolvedores só trabalham no tempo livre
Poderão não responder de imediato. Sê paciente — eles responderão mais cedo ou mais tarde. E, se não o fizerem, educadamente comenta no mesmo post para o trazer ao topo. Isto também significa que não deves fazer pedidos triviais sem importância, nem pedidos extremamente exigentes.
Ser “código aberto” não significa que as tuas contribuições serão sempre aceites
A equipa tem de manter a qualidade do código e da arte. Isto poderá implicar que o teu trabalho não seja aceite. E, por favor, não te deixes desanimar — a equipa estará ao dispor para ajudar ou dar conselhos.
Diretrizes
Quando reportas um bug ou crash no jogo
- Se o bug já foi reportado no GitHub:
- Se a discussão do bug estiver aberta, verifica se podes reportar mais informações para a equipa.
- Se a discussão do bug estiver fechada, provavelmente terás de esperar pelo próximo lançamento para que as correções sejam incluídas no jogo, a não ser que queiras construir o jogo a partir da fonte.
- Se o bug não foi reportado:
- Usa um título claro e descritivo.
- Inclui uma explicação detalhada do problema. Instruções passo-a-passo de como reproduzir fielmente o problema são especialmente úteis.
- Inclui informações do teu sistema como o sistema operativo e a sua versão, o modelo e fabricante do processador gráfico (GPU), a versão do driver de gráficos e o modelo do CPU.
- Inclui o ficheiro stdout.log. (Consulta “Onde fica armazenada a configuração do jogo” na página Perguntas Frequentes para informações sobre a localização deste ficheiro.)
- Inclui capturas de ecrã, se necessário.
- Se fores capaz de compilar por ti mesmo o STK e corrê-lo sob um depurador (tipo o GDB, o Valgrind ou o depurador do Visual Studio), por favor compila o STK no modo de depuração, corre-o e posta o resultado de saída do depurador.
- Inclui outras informações que consideres necessárias.
- Responde a todas as perguntas da equipa da forma mais completa possível.
Quando apresentas um recurso ou outra contribuição de arte
- Fornece os ficheiros fonte (.kra, .xcf, .blend, etc.).
- Indica explicitamente a licença. (Consulta Licenciamento para opções.)
- Acolhe as críticas e vê o que podes fazer para melhorar a tua arte.
- Discute com a equipa enquanto o trabalho ainda está em curso para receberes feedback.
- Deixa claro se a tua contribuição é final ou um trabalho em curso.
Quando fazes uma sugestão para o STK
Este é um tópico sensível. É claro que precisamos de acolher críticas e sugestões — o contrário seria o oposto de um ideal de código aberto, “o software é para o beneficio de todos”. Mas quando é que um pedido se torna demais? Neste sentido, devemos tomar atenção ao que possa conflituar com outro ideal de código aberto: “todos devem contribuir quando possível”. Portanto, quando fores fazer um sugestão para o STK, pergunta-te a ti mesmo o seguinte:
- Já fiz alguma contribuição para o SuperTuxKart?
- Isto pode ser doar, fazer objetos, pistas, texturas, etc. Até extensões ajudam o jogo.
- Se eu pudesse fazer o que peço, estaria disposto a fazê-lo?
- Compreendo o esforço necessário para fazer esta tarefa?
- Será que, no mínimo, manifesto o meu apoio à equipa e ao trabalho que fazem?
- Tenho feito muitos pedidos de funcionalidades ultimamente?
- Isto poderá soar banal, mas é sinal de que respeitas o trabalho da equipa. Se respeitares o seu trabalho, possivelmente reclamarás menos.