10 maneiras de contribuír

From Proxecto Trasno

Adoita ser frecuente que unha persoa estea interesada en colaborar cun proxecto de código aberto ou libre pero que diga que carece de perfil de programador. De feito os que contribúen con código de programación son sempre benvidos na maioría dos proxectos de código aberto pero hai varios outros camiños para facer unha valiosa contribución.

Antes de nada hai dúas cousas que convén lembrar no referente aos proxectos de código aberto:

  • - O código aberto, non se refire só a compartir no sentido "botarlle código á cara dos demais"; tamén se refire á forma de devolver esa contribución. Cando empezou a miña carreira nist do código aberto, beneficieime de software como INN. Daquela volveuse natural para min darlles as miñas modificacións e devolverlles o que engadira
  • -. A comunidade do código aberto funciona coma unha meritocracia. Cando comezas a traballar nun proxecto por primeira vez e ninguén te coñece, é importante comunicalo. Empeza co que necesites para principiar ou resolver un problema. Doutra manera serás ignorado. Se tes contribuído antes ao proxecto, confiarán máis en ti para lograr una nova mellora, porque existe unha confianza da comunidade que che dará máis dereitos e permisos á hora de acceder ao código ou documentalo no wiki.

Cando comezas a axudar nun proxecto de código aberto entras na comunidade que a forma, estás nun camiño que vai desde o momento en que "estás fóra" ata o momento en que "estás dentro".

Isto é típico en calquera comunidade e especialmente nunha comunidade de código aberto. Lémbrate disto ao entrar en contacto coa comunidade: se non consegues unha reacción ou resposta no primeiro contacto, non te frustres nin abandones o carro. Sigue colaborando, compartindo e traballando mediante un achegamento respectuoso, e xa verás como triunfas!

Dez formas, 10 de contribuír coa comunidade de software libre

sen contribuír con código

  1. Ofrece informes sobre o que che gusta e o que non. Isto inclúe informes formais tanto de erros (bugs) como a simple comunicación coa persoa correcta. É bo escoitar os usuarios así como a maneira en que o proxecto os axudou a descubrir os detalles da implementación que fixesen.
  2. Crear solicitudes de funcionalidades que expliquen a necesidade de uso. Describe por que cres que é útil e como outros poderían beneficiarse. Sen unha contribución ao código, é difícil chegar a que esas características se desenvolvan. Pero, se explicas que este recurso é útil e como tamén poden beneficiarse outros, moitas veces coincides con outros usuarios que teñen problemas semellantes e por iso, é posible que alguén poida crear esa nova funcionalidade.
  3. Proba o código que está a ser desenvolvido. Non importa cantas probas automatizadas se fagan, a realidade é que o proxecto é unha combinación de hardware e software e tamén doutros aspectos do entorno que non foron comprobados polo equipo do proxecto (porque en realidade non o pode probar todo). Así, "tomar unha mostra" do proxecto diaria ou semanal, instalala e reaccionar ao que se ve, é moi útil e sempre benvida. Para o proxecto onde eu traballo, cambiamos algúns gráficos e tivemos un membro da comunidade dándonos todos os días o seu comentario sobre a súa experiencia coa última versión do código desenvolvido, do que obtivemos unha mellora considerábel e un feixe de arranxos.
  4. Escribir documentación. Moitos dos colaboradores dos proxectos son bos programadores, pero non escritores técnicos (documentación). Unha parte da documentación é case ilexíbel e precisa dunha revisión gramatical, ortográfica e de construción correcta de frases. Isto axudaría a aplicación xeral e evolución do proxecto. Noutros casos, a documentación describe detalles técnicos, pero esquece de axudar aos principiantes. Ademais, os casos raros, as solucións e as mellores opcións, deben cambiar na redacción e ser incluídos. Se atopa a mesma pregunta contestada unha e outra vez, podería ser capaz de escribir ou actualizar a sección de preguntas frecuentes (FAQ) de modo que as respostas estean dispoñíbeis para que se lean ou para futuras consultas.
  5. Traducir a interface de usuario e a documentación. Aínda que moitos usuarios entenden inglés ben, hai moitos usuarios que prefiren a documentación escrita na súa lingua nativa. Despois de escribir o meu primeiro libro en alemán, sobre JBoss contactou comigo xente que me dicía que leran toda a documentación dispoñíbel en inglés, pero que aínda así aproveitaron o libro escrito na súa lingua nativa, porque podían concentrarse máis na parte técnica, sen as distraccións da lectura en lingua estranxeira.Ficheiro:Imaxe de Marc Wathieu
  6. Responde ás preguntas de usuarios en foros ou listas de correo. Tamén pode sorprendelo saber que sabe máis do que pensa. E os usuarios, por outra banda, agradecerán a súa axuda. Tamén cando trate de responder a preguntas, axudaralle a comprender mellor o proxecto. Isto axudaralle a escribir mellores informes de erros, solicitudes de novas funcionalidades desexadas e documentación. Ademais de todo isto , ao axudar a responder preguntas, obterá solucións para os usuarios máis rapidamente, e así o proxecto vai atraer máis usuarios e será moito máis fácil que se queden e así os membros clave do proxecto poden ter máis tempo para a programación. Ambos aspectos reforzan o proxecto global.
  7. Axuda co deseño de interfaces de usuario, logotipos e sitios web. Moitos desenvolvedores tenden a crear interfaces moi técnicas que non non agradábeis esteticamente e que non atraen a novos usuarios. Unha boa interface intuitivas non ofrece ningunha nova funcionalidade adicional por si soa, pero pode mellorar moito a experiencia do usuario. O mesmo se aplica para o sitio de web e logotipos. Mellorar a aparencia e aspecto do proxecto tamén pode axudar a reducir o esforzo de asistencia técnica é invitar a novos usuarios a probala
  8. Promover o proxecto falando sobre el no seu grupo de usuarios local, escribindo artigos nun blog, e difundir as actualizacións mediante redes sociais que utilice. Mesmo se pensa que os outros deberían ter oído falar do proxecto, non o dea por feito. Escoitar a alguén falar sobre as súas propias experiencias co proxecto é moito máis importante, e pode influencia a outros dunha forma diferente (en comparación coa navegación na web do proxecto ou no código fonte)
  9. Fornecendo hardware, se existe a necesidade de servidores de compilación ou servidores dedicados a probas. Pode proporcionar acceso para os desenvolvedores directamente a un "datacenter" ou indirectamente efectuando integración continua ou probas por si mesmo e logo fornecendo resultados ao proxecto.
  10. Agradecerlle á comunidade o seu traballo e contribucións á causa na que están a traballar e os obxectivos que están a ser acadados.

Orixe: Do artigo orixinal - by-sa [http://opensource.com/life/13/10/ten-ways-open-source-projects 10 ways to contribute to an open source project without writing code]

Pero hai máis...

  • Por suposto, tamén está a posibilidade axudar con fondos económicos, pequenas achegas ou doazóns de cantidades modestas por parte do grupo de usuarios poden protexer o proxecto e garantir a continuidade do software do que eles mesmos se benefician.
  • Organizar seminarios, obradoiros ou participar en convencións, congresos, xornadas de ámbito local. Que haxa alguén nun proxecto enfocado en xestionar a actividade social, contactar coa prensa, etc. é realmente algo apreciado por calquera proxecto.
  • Ofrecer o teu perfil profesional de coordinador (líder). Ser coordinador non ten por que ser automaticamente un rol que un programador do núcleo de código do proxecto queira asumir e moitas veces os maiores e máis lonxevos colaboradores non teñen as aptitudes e prefiren que haxa outras persoas que se ocupen e contribúan máis enfocadas no traballo transversal do proxecto. Ser coordinador non é ser máis importante que os demais.
  • 50 maneiras de ser un «FOSSer»

http://xcitegroup.org/softhum/doku.php?id=f:50ways