Antes que nada, gracias por considerar contribuir con Active Admin. Son las personas como tu las que hacen que Active Admin sea una herramienta tan genial.
[fuente: Active Admin] Necesitas más inspiración? [1] Read The Docs [2] Mustache.js
Seguir estas guías ayuda a comunicar que tu respetas el tiempo de las y los desarrolladores que están manejando y desarrollando este proyecto de codigo abierto. A cambio, ellas y ellos deberían de forma reciproca dirigirse a tu issue, revisar los cambios y ayudarte a finalizar tus pull requests.
[fuente: Hoodie]
Manten la mente abierta! Mejorar la documentación, anotación de nuevos bugs, o escribir tutoriales son ejemplos de contribuciones que te ayudan a disminuir la carga de trabajo.
Elasticsearch es un proyecto de código abierto y a nosotros nos encanta recibir contribuciones de nuestra comunidad - de tí! Hay muchas formas de contribuir, desde escribir tutoriales o publicaciones en blogs, mejorar la documentación, generar reportes de nuevos bugs y solicitudes de mejoras o escribir codigo que pueda ser incorporado en Elasticsearch como tal.
[fuente: Elasticsearch] Necesitas más inspiración? [1] Devise [2] Geocoder (“conociendo los issues”)
Nuevamente, definir esto de frente significa menor trabajo para ti. Si alguien ignora tu guía y presenta algo que no quieres, puedes simplemete cerrarlo y dirigirles hacia la política que lo indica.
Por favor, No uses el panel de issues para [preguntas de soporte]. Revisar el canal de IRC #pocoo IRC en Freenode puede ayudarte con tu issue. Si tu problema no es estrictamente específico de Werkzeug o de Flask, #python es generalmente más activo. También vale la pena intentar describiendo o buscando el error en Stack Overflow.
[fuente: Flask] Necesitas más inspiración? [1] cucumber-ruby [2] Read the Docs
Esto incluye no solamente como se comunican con las/los demás (siendo respetoso, considerado, etc) sino también en las responsabilidades técnicas (la importancia de hacer testing, dependencias de proyecto, etc). Menciona y enlaza tu código de conducta, si tienes uno.
Responsabilidades
- Asegurate de la compatibilidad entre plataformas para cada cambio aceptado. Windows, Mac, Debian y Ubuntu Linux.
- Asegurate de que el código que va al core cumple con los requerimientos de la siguiente checklist: https://gist.github.com/audreyr/4feef90445b9680475f2
- Crea issues para cualquier cambio mayor y mejora que desearias hacer. Discute las cosas de manera transparende y obten los comentarios de la comunidad.
- No agregues ninguna clase al código base a menos de que sea completemante necesario. Don't add any classes to the codebase unless absolutely needed. Preferiblemente hacer uso de funciones.
- Manten el versionamiento de nuevas caracteristicas tan cortas como sea posible.
- Se amable con las y los recién llegados y apoya la diversidad de nuevas y nuevos contribuidores de todo tipo de antecedente. Revisa el Código de Conducta de la Comunidad Python.
[fuente: cookiecutter] Necesitas más inspiración? [1] Celery [2] geocoder
Ayuda a la gente que es nueva en el proyecto a que entiendan donde pueden ser de apoyo. Este es un buen momento también para dejarle saber a las personas si sigues alguna convención para etiquetar issues para principiantes.
Aun no sabes como empezar a contribuir con Atom? Puedes empezar revisando los issues con etiquetas principiante (beginner) y se-necesita-ayuda (help-wanted): Beginner (principiante) - los issues con esta etiqueta deberían de requerir unicamente unas pocas lineas de código y uno o dos tests.
Help wanted (se necesita ayuda) - Estos son issues que pueden ser un poco más complicados que los issues de principiantes.
Ambas listas de issues están ordenadas por la cantidad de comentarios que tienen. Aunque no es perfecto, la cantidad de comentarios es un proxy rasonable para saber el impacto que tendrá el cambio.
[source: Atom] Necesitas más inspiración? [1] Read the Docs [2] Django (baja en el scroll hasta "Guidelines" también)
Aquí hay algunos tutoriales que puedes incluir: http://makeapullrequest.com/ y http://www.firsttimersonly.com/
Trabajando en tu primer Pull Request? Puedes aprender como en esta free series, Cómo contribuir a un proyecto de Código abierto en GitHub.
[fuente: React]
Cómo nota, es bastante util usar lenguaje amigable con las personas recien llegadas en todo el documento. Aquí algunos ejemplos de Active Admin:
En este punto, ya estas preparada o preparado para hacer cambios! Sientete libre de pedir ayuda; todos fuimos principiantes una vez 😸
Si un maintainer te pide que hagas un "rebase" al PR, ellos se refieren a que muchisimo código a cambiado y que deberías actualizar la rama para que sea más facil unirla al resto del código.
Cómo escribes esto, depende de tí, pero algunas cosas que debería incluir son:
- Dejales saber si necesitan firmar un CLA, estar de acuerdo con un DCO, o cualquier otra documentación legal que se necesite
- Si los tests son necesarios para las contribuciones, hazles saber y explicales como ejecutar estos tests.
- Si estas usando algo distinto de GitHub para manejar tus issues (ej. JIRA or Trac), hazles saber que herramientas necesitan para contribuir
Para cualquier cosa que sea mayor a una o dos lineas para corregir:
- Crea tu propio fork del código
- Haz los cambios en tu fork
- Si te gusta el cambio y crees que el proyecto podría utilizarlo:
* Asegurate de haber seguido el estilo de código del proyecto.
* Firma el Contributor License Agreement, CLA, con la Fundación jQuery. * Revisa el Código de conducta de la Fundación jQuery. * Envia un pull request indicando que tienes un archivo con el CLA.
[fuente: Requirejs] Necesitas más inspiración? [1] Active Admin [2] Node.js [3] Ember.js
Pequeñas contribuciones como errores de ortografía, donde el contenido es lo suficientemente pequeño como para no considerado propiedad intelectual, puede ser agregado como un patch de contribuidor, sin el CLA.
Como regla de oro, los cambios pueden ser considerados "correcciones obvias" si estos no introducen una nueva funcionalidad o pensamiento creativo. Media vez el cambio no afecte la funcionalidad, algunos ejemplos incluyen los siguientes:
- Correcciones de Ortografía / Gramática
- Corrección de un error en la escritura de una palabra, espacios en blanco y cambios de formato
- Limpieza de comentarios
- Corrección de Bugs que cambian los valores que se retornan o códigos de error guardados en constantes
- Agregar mensajes de logueo o salidas de debugging
- Cambios a los archivos de ‘metadata’ como Gemfile, .gitignore, scripts de construcción, etc.
- Mover archivos con código de un directorio o paquete a otro
[fuente: Chef] Necesitas más inspiración? [1] Puppet
Como mínimo, incluye la siguiente oración:
Si encuentras una vulnerabilidad de seguridad, NO abras un issue con la explicación. En vez de eso, envía un email a XXXX.
Si no quieres usar tu información personal, establece una dirección como "seguridad@xxxxx". Proyectos más grandes suelen tener procesos más formales para comunicar cuestiones de seguridad, incluyendo comunicación encriptada. (Disclosure: No soy un experto en seguridad.)
Cualquier issue de seguridad debe ser enviado directamente a security@travis-ci.org Para poder determinar si estas tratando con un error de seguridad, hazte las siguientes preguntas:
- Puedo accesar a algo que no es mío, o algo que no debería de tener acceso?
- Puedo deshabilitar algo para otras personas?
Si la respuesta a cualquiera de esas dos preguntas es "Si", entonces probablemente estas lideando con un problema de seguridad. Nota que aún cuando la respuesta es "no" a ambas preguntas, aún podrías estar lideando con un issue de seguridad, si no estas seguro, envianos un email a security@travis-ci.org.
[fuente: Travis CI] Necesitas más inspiración? [1] Celery [2] Express.js
También puedes incluir una plantilla para que las personas puedan hacer un copy-paste (de nuevo, menos trabajo para tí).
Cuando llenas un issue, asegurate de responder estas cinco preguntas:
- Qué version de Go estas usando(go version)?
- Qué sistema operativo y que procesador estas usando?
- Qué hiciste?
- Qué esperabas ver?
- Qué viste en lugar de ello? Preguntas generales deberían de ir la lista de correos de golang-nuts en vez del issue tracker. Las y los gophers que estén allí te indicarán si es necesario abrir un issue cuando encontraste un bug.
[fuente: Go] Necesitas más inspiración? [1] Celery [2] Atom (incluye plantilla)
Esta información le dara a los contribuidores contexto antes de hacer sugerencias que puede no estén alineadas con lo que el proyecto necesita.
La filosofía Express se trata de proveer un pequeño pero robusto set de herramientas para servidores HTTP, haciendolo una gran solución para aplicaciones de una sola página, web sites, híbridos, APIs HTTP publicas.
Express no te forza a utilizar ningún ORM específico. Con soporte para al rededor de 14 motores de plantillas vía Consolidate.js, puedes facilmente crear un framework perfecto.
[fuente: Express] Necesitas más inspiración? Active Admin
Si hay una ida y vuelta o cierre de sesion requerido, dilo. Pideles que escriban el alcance de la nueva caracteristica, con la idea de porque es necesaria y como podría funcionar.
Si te encuentras desdeando una característica que no existe en Elasticsearch, probablemente no estas solo. Puede ser que otras personas tengan necesidades similares. Muchas de las características que Elasticsearch tiene el día de hoy han sido agregadas gracias a que nuestros usuarios vieron la necesidad. Abre un issue en la lista de issues de GitHub que describa la característica que te gustaría ver, porqué la necesitas y como debería funcionar.
[fuente: Elasticsearch] Necesitas más inspiración? [1] Hoodie [2] Ember.js
Quién la revisa? Quien necesita firmar antes de que sea aceptada? Cuando debería esperar el contribuidor que le respondas? Cómo puede tener un contribuidor acceso a hacer commits, si fuese necesario?
El core team revisa los Pull Requests semanalmente en una junta tripartita que se lleva a cabo en un Google Hangout público. El hangout se anuncia en las actualizaciones semanales y son enviados a la lista puppet-dev. Las notas son posteadas en el repo de Puppet Community community-triage e incluye un enlace a la grabacíon del hangout en YouTube. Luego de que se da la retroalimentación se esperan respuestas en las siguientes dos semanas. Luego de ello puede que se cierre el pull request debido a la inactividad.
[fuente: Puppet] Necesitas más inspiración? [1] Meteor [2] Express.js
Si existen otros canales a demás de Github para discutir las contribuciones, mencionalos aquí. También puedes listar las y los autores, mantenedores y/o contribuidores aquí, o establecer las expectativas de tiempo de respuesta.
Puedes chatear con el core team en https://gitter.im/cucumber/cucumber. Tratamos de tener horas disponibles los viernes.
[fuente: cucumber-ruby] Necesitas más inspiración? [1] Chef [2] Cookiecutter
Estas secciones no son necesarias, pero pueden ayudar a orientar las contribuciones que recibes.
Necesitas más inspiración? [1] Requirejs [2] Elasticsearch
Necesitas más inspiración? [1] Angular [2] Node.js
Necesitas más inspiración? [1] StandardIssueLabels [2] Atom