Contribuir al código base de Mozilla

Esta pagina debe guiar a dar sus primeros pasos para contribuir con Mozilla. Bienvenidos, estamos encantados de tenerte :)

¿Necesita ayuda?

La Comunidad Mozilla siempre da la bienvenida a los que recién llegan a nuestro medio. Si usted tiene alguna dificultad, puede hacer preguntas de introducción en el #introduction chat room on irc.mozilla.org. Si aún sigue teniendo problemas, por favor contactese con Kyle Huey en [email protected].

¿Qué habilidades necesito?

Mozilla es un gran proyecto y estamos felices de recibir contribuidores con diferente habilidades.

Si tú conoces C++, por ejemplo, puedes contribuir en las capas centrales de Firefox, Firefox OS y otros productos de Mozilla.
Si tú conoces JavaScript o HTML/CSS, puedes contribuir en el front-end (frente-final) de Firefox, o en Gaia, la aplicación de capas de Firefox OS.
Si tú conoces Java, puedes contribuir en Firefox Mobile.
Si tú conoces Python, puedes contribuir en nuestros servicios web, incluyendo Firefox Sync o Persona.
Si tú conoces de Make, shell, Perl o Python, puedes contribuir en nuestros sistema de compilación.
Si tú conoces C, puedes contribuir a un numero de librerias de bajo nivel que nosotros usamos como parte del codigo base de Mozilla.
Y tambien hay muchas maneras de contribuir en la misión de Mozilla sin la necesidad de programar. Si deseas participar en el diseño, soporte, traducción, pruebas, o en otros tipos de contribuciones, ve la pagina de oportunidades de voluntario.

Tal vez no sabes programar todavía, pero deseas comenzar a aprender? Eso está muy bien también, el programa Webmaker es para ti, y hay más recursos disponibles en la red de desarrolladores de Mozilla!

Paso 1 - Construir Firefox, Firefox OS, Thunderbird u otra aplicación

Si deseas contribuir con Firefox, Thunderbird or Firefox OS, sigue nuestra serie de instrucciones simples para construir Firefox, construir Thunderbird, o construir Firefox OS. Esto es sencillo, pero puede llevar algun tiempo, asi que es posibe que quieras pasar al siguente paso mientras contruyes esto. Puedes encontrar aqui mas intrucciones de construcción.

Para otros productos, es posible que no tengas nada que construir.

Paso 2 - Entender cómo contribuir a los trabajos de Mozilla

Ver Mozilla Firefox: Proceso de Desarrollo. Thunderbird opera un proceso similar.

Paso 3 - Encuentra algo para trabajar

Arregla cosas que te molestan

Si hay algo que le gustaría arreglar sobre Firefox, Thunderbird u otra aplicación favorita de Mozilla, éste puede ser un buen lugar para empezar. Hay varias de maneras de hacer esto:

Buscar en Bugzzila palabras clave
Averigüe el componente de bugzilla en el que lo que le molesta es implementado, usando la lista de componentes. Examine ese componente en bugzilla para errores relacionados
Pregunte en #introduction or #developers en el chat irc.mozilla.org.

Encuentra un error que hallamos identificado como bueno para los recién llegados

Los desarrolladores de Mozilla etiquetan ciertos errores como fáciles para que los recién llegados se familiaricen con nuestros procesos:

Los bugs mentorizados (o alternativamente, la interfaz menos usada) tienen un mentor que se compromete a ayudarle en cada paso del camino. En general, debe haber suficiente información en el error para empezar. Siempre que necesite ayuda, póngase en contacto con el mentor por IRC, en el propio fallo, o por correo electrónico. Cuando hayas completado el error, ellos le ayudarán a obtener su código del árbol.
Un "Buen" primer fallo puede estar un poco añejo, pero en al algún punto de sus vidas consideramos que podían ser un buen primer paso para recién llegados a Mozzila. Estamos en procesos de migrar estos fallos a bugs mentorizados, pero quizás más recientes "buenos primeros fallos" pueden ser buenos puntos de partida si no hay bug mentorizados que sean apropiados.
Los proyectos Estudiantiles son proyectos largos, por lo tanto pueden ser adecuados para creditos para estudiantes universitarios. Por supuesto, si usted no es estudiante, debe sentirse libre de arreglar uno de estos fallos. Mantenemos dos listas, una para proyectos basados en el codigo fuente existente, una para la implementación de nuevas aplicaciones.

Paso 4 - Arregla el fallo

Dejamos esta en tus manos. Tenemos algunos recursos para ayudarte a aquí también:

Echa un vistazo https://developer.mozilla.org/En/Developer_Guide,
Pida ayuda en un comentario sobre el error, o en #introduction o #developers.

Si el fallo que está arreglando probablemente requiera una actualización de documentación de desarrollo una vez que esté arregado, asegúrese de añadir la palabra clave doc-dev necesaria para el error (o pida a alguien que lo haga, si usted no tiene los privilegios editbugs en Bugzilla). Esto pone el bug en el radar de nuestro equipo de documentación para asegurar que una vez que se resolvió el error, la documentación será actualizada adecuadamente. Si no marca el error, su trabajo podría pasar desapercibido por el equipo de documentación! Puede marcar el error con esta palabra clave en cualquier momento; usted no tiene que esperar hasta que realmente esté arreglado.

Por supuesto, nuestra documentación es una wiki; usted realmente puede ayudar mediante la actualización de la documentación po sí mismo. Incluso si usted no se siente cómodo con sus habilidades de escritura, tenga en cuenta que nuestros útiles gnomos de documentación estarán felices de seguirlo y limpiar por usted.

Paso 5 - Obten la revisión de tu Código

Una vez que corrijas el bug, adjunta un parche al bug , y solicita una revisión. Realiza esto dando click en el link Details de tu adjunto, después establece el indicador de revisión a ? e introduce el ID del validador de bugzilla en el campo que se muestra (o bien su dirección de correo electrónico del: UniqueName que proporciona). Es muy importante agregar el ID de bugzilla, o la solicitud será ignorada. Entonces, ¿Cómo puedes saber quien es la persona indicada para que pueda revisar tu corrección?

Si tu tienes un "mentored bug", pregunta a tu mentor, el sabrá o podrá encontrarlo fácilmente.
Ejecuta hg blame y mira a las personas que han trabajado en la función en la que tu estás trabajando - Ellos pueden ser un buen candidato.
El bug por si mismo, puede contener clara información de quién es la mejor persona para solicitar la revisión.
¿Hay errores relacionados sobre temas similares? En ese caso, el validador de esos bugs podría ser una buena opción.
Tenemos una desactualizada lista de modulos que enumera los compañeros y dueños de los módulos, algunos de los cuales serán un buenos validadores. En el peor de los casos, establece al dueño del módulo como validador, y pregunta por alguien mejor para la revisión, en caso que el no tenga tiempo

Paso 5b - Da seguimiento a tu corrección

Si has solicitado una revisión, pero el validador no ha comentado nada en unos días, No temas en darle ping. Solo agrega un comentario en el bug, diciendo 'review ping?', y vuelve a darle ping un par de días después si sigue sin responder. Si no responde después de eso, pide ayuda en #introduction o #developers.

Paso 6 - Atiende la revisión

A menudo, un validador pedirá cambios, tal vez menores, tal vez mayores. En cualquiera de los casos, corrige lo que sea que el validador pide; Si no estás seguro como, asegurate de preguntar! Adjunta el nuevo parche al bug, y vuelve a solicitar la revisión al mismo validador.Si te dan una r+ significa que tu corrección fue aceptada en el árbol!

Paso 7 - Consigue enviar el código al repositorio

Ya que aún no tienes la posibilidad de enviar el código al repositorio, debes pedir ayuda a alguien. Si tienes un mentor, pregúntale. Si no, pregúntale al validador. Si el validador se encuentra muy ocupado, marca ese commit como necesario agregando la palabra clave checkin-needed. Una buena persona enviará el código al repositorio en unos pocos días, entonces marcarán el bug como corregido.

Paso 8 - Repite

Felicidades, has arreglado tu primer bug. Ahora vuleve al paso 3 y repite. Ahora tienes tu primer bug, deberás solicitar acceso al nivel 1 del repositorio para que pueda hacer push al servidor de pruebas RHW y obtener retroalimentación automatizada sobre los cambios en múltiples plataformas. Después de que hayas arreglado un número no trivial de bugs, deberás solicitar acceso al nivel 3 para que puedas hacer push a tu propio código despueés de haber sido validado.

Más información

Estamos en el proceso de mejora de la información en esta página para los recién llegados al proyecto. Vamos a estar integrando alguna información en estas páginas pronto, pero hasta entonces es posible que encuentres más información interesante en su forma actual: