Antes de contactar co equipo, informar dun erro, publicar nos foros, etc., debes ler esta páxina. Seguir as pautas e instrucións desta páxina fará que a comunidade e o proxecto funcionen de forma máis eficiente e feliz. Aínda que este artigo pode parecer un pouco duro, non teñas medo de publicar. O equipo xeralmente é bastante paciente, a non ser que sexas un reincidente. ;)
Contidos
Ten en conta…
Non se lles paga aos desenroladores
Os desenroladores fan isto porque lles gusta, non porque lles pagues. Non se lles paga, aínda que tentarán ter en conta as túas suxestións se é posible.
Os desenroladores só traballan no seu tempo libre
Quizais non teñan a oportunidade de responder de inmediato. Ten paciencia, responderán eventualmente. E se non o fan, cortésmente bótalle a publicación. Isto tamén significa que non debes facer solicitudes triviais que non teñan importancia, nin solicitudes extremadamente esixentes.
O código aberto non sempre significa que as túas contribucións serán aceptadas
O equipo ten que manter a calidade do código e das obras de arte. Isto significa que ás veces o teu traballo non pode ser aceptado. Non te desanimes: o equipo estará encantado de axudar ou aconsellar.
Directrices
Ao informar dun erro ou fallo no xogo
- Se o erro xa está informado en GitHub
- Se o erro está aberto, mira se podes informar de máis información ao equipo.
- Se o erro está pechado, probablemente teñas que esperar á próxima versión para que a corrección se inclúa no xogo, a non ser que queiras construír desde a fonte.
- Se non se informa do erro:
- Fai o título claro e descritivo.
- Inclúe unha explicación detallada do problema. As instrucións paso a paso sobre como reproducir o problema de forma fiable son especialmente útiles.
- Inclúe información do sistema como o seu sistema operativo, a versión do sistema operativo, o modelo e o fabricante do procesador gráfico (GPU), a versión do controlador de gráficos e o modelo de CPU.
- Inclúa o ficheiro stdout.log. (Consulte “Onde almacena STK o ficheiro de configuración do usuario” na páxina FAQ para obter información sobre onde se atopa este ficheiro.)
- Incluír capturas de pantalla, se é necesario.
- Se es capaz de compilar STK vostede mesmo e executalo nun depurador (como GDB, Valgrind ou Visual Studio Debugger), compile STK no modo de depuración, execútao e publique a saída do depurador.
- Inclúe calquera outra información que considere oportuna.
- Responde as preguntas que o equipo faga o máis completo posible.
Cando se presente un activo ou outra contribución de obra de arte
- Proporcione os ficheiros fonte (.kra, .xcf, .blend, etc.).
- Indique claramente a licenza. (Consulte Licenzas para ver as opcións.)
- Acepta as críticas e mira o que se pode facer para mellorar a túa obra de arte.
- Discuta co equipo mentres aínda está en proceso para obter comentarios.
- Ten claro se a túa contribución está completa ou en proceso.
Ao facer unha suxestión para STK
Este é un tema sensible. Por suposto que debemos aceptar críticas e suxestións; se non o facemos, é contrario ao ideal de código aberto: que o software é para o beneficio de todos. Pero onde se fai demasiado unha solicitude? Para iso tamén hai que estar atentos aos conflitos cun ideal de código aberto: que todos contribúan onde sexa posible. Entón, cando fagas unha suxestión para STK, fai estas preguntas:
- Fixen algunha contribución a SuperTuxKart antes?
- Isto podería ser doar, facer obxectos, circuitos, texturas, etc. Mesmo os complementos axudan ao xogo.
- Se puidese facer o que pido, estaría disposto a facelo?
- Entendo o esforzo necesario para realizar esta tarefa?
- Expreso polo menos apoio ao equipo e ao traballo que realizan?
- Fixen moitas solicitudes de funcións ultimamente?
- Isto pode parecer mundano, pero realmente é un sinal de se respectas o traballo do equipo. Se respectas o seu traballo, é moito menos probable que te queixes.