Antes de contactares a equipa, reportares um bug, postar nos fórums, etc, Deves ler cuidadosamente esta página. Seguindo estas diretrizes e instruções fará a comunidade e o projeto funcione mais eficientemente e em alegria! Apesar de soar duro, por favor não tenhas medo de postar. A equipa é geralmente muito paciente, a não ser que sejas um infrator. ;)
Conteúdos
Por favor, tem em mente…
Os desenvolvedores não são pagos
Os desenvolvedores fazem isto porque gostam de o fazer, não porque vocês os pagam. Não são pagos para vos dar prazer, mas tentaram notar as vossas sugestões se for possivel.
Os desenvolvedores só trabalham quando estão livres.
Eles poderam não responder de imediato. Sejam pacientes — eles irão responder mais cedo ou mais tarde. E se não o fizerem, educadamente comentem no mesmo post para o trazer ao topo. Isto também significa que não devem fazer pedidos desnecessárias sem importância, ou demasiado exigentes.
Open-source não significa que as vossas contribuições serão sempre aceites
A equipa têm de manter a qualidade do código e da arte. Isto pode significar que o vosso trabalho seja recusado. Por favor não sejam timidos — a equipa estará ao dispor de ajudar ou de 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 podem 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 com a fonte.
- Se o bug não foi reportado:
- Usa um título claro e descritivo.
- Incluiem uma explicação detalhada do problema. Instruções passo-a-passo de como reproduzir o problema são muito úteis.
- Incluiem as informações do vosso sistema como o operador do sistema, a sua versão, o modelo processador de gráficos (GPU) e marca, a versão do driver de gráficos, e o modelo do CPU.
- Incluiem o ficheiro stdout.log. (Vê “Onde é que o STK guarda o ficheiro de configuração do utilizador” na página FAQ para mais informações sobre a localização do ficheiro.)
- Incluiem fotos de ecrã, se necessário.
- Se forem capazes de compilar o STK vós própios e inicia-lo em um depurador (como GDB, Valgrind, ou Visual Studio Debugger), por favor compilem o jogo no mode de depuração e postem a saída do depurador.
- Incluem outras informações que achem que devem ser descritas.
- Respondam às perguntas da equipa o mais completo que conseguirem.
Quando apresentando um recurso ou outra contribuição de arte
- Forneçam os ficheiros fonte (.kra, .xcf, .blend, etc.).
- Claramente ditem a licença. (VêLicenciamento para opções.)
- Aceitem criticismo para ver o que pode ser melhorado.
- Discutem com a equipa durante o processo de criação para receber feedback.
- Sejam claros quando a tua contribuição é final ou um trabalho-em-progresso.
Quando sugerir algo para o STK:
Este é um tópico sensível. Cláro que precisamos de aceitar criticismo e sugestões — e se não o fizermos, seria o contrário ideal de um open-source: que o software é para o beneficio de todos. Mas quando é que um pedido se torna demais? Para isso devemos estar atentos a conflitos com um ideal open-source: todos devem contribuir onde possivel. Portanto, antes de fazerem um sugestão para o STK, por favor façam estas perguntas a vós mesmos:
- Já fiz alguma contribuição para o SuperTuxKart?
- Isto pode ser doações, fazer objetos, pistas, texturas, etc. Até add-ons ajudam o jogo.
- Se podesse fazer o que peço, estaria disposto a o fazer?
- Compreendo o esforço necessário para fazer esta tarefa?
- Eu pelo menos expresso suporte pela equipa e o seu trabalho?
- Fiz muitos pedidos de recursos recentemente?
- Isto poderá soar mundano, mas isto é um sinal de que respeitas o trabalho da equipa. Se respeitares o seu trabalho, irás reclamar menos.