Closed serudda closed 1 year ago
cardotrejos
commented
1 year ago El tema de los labels también ayuda mucho. Ejemplo:
El tema de las mentorías me sonó bastante.
Adicional pongo este video, que también me parece buen recurso para los nuevos. https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github
Zyruks
commented
1 year ago Luego de pasar años en un proyecto de código abierto, significa que aprendiste a conocer un proyecto de código abierto. Si te mueves a un proyecto diferente encontrarás que el vocabulario, las normas, y los estilos de comunicación son completamente diferentes.
Dicho esto, muchos proyectos de código abierto siguen una estructura organizacional similar. Entender los roles de las diferentes comunidades y el proceso en general te ayudará a estar rápidamente orientado para cualquier proyecto nuevo.
Un proyecto de código abierto tiene los siguientes tipos de personas:
- Autor: La/s persona/s u organización que creó/crearon el proyecto.
- Dueño: La/s persona/s que tiene/n la propiedad administrativa sobre la organización o el repositorio (no siempre es la misma que el autor original)
- Encargados: Colaboradores que son responsables de dirigir la visión y de administrar aspectos organizacionales del proyecto. (Pueden también ser autores o dueños del proyecto.)
- Colaboradores: Cualquiera que haya contribuido con algo al proyecto.
- Miembros de la comunidad: Las personas que utilizan al proyecto. Pueden tener un rol activo en las conversaciones o expresar su opinión sobre la dirección que toma el proyecto.Los proyectos más grandes pueden tener también subcomisiones o grupos de trabajo enfocados en tareas diferentes, como herramientas, priorización de urgencias, moderación de la comunidad, y organización de eventos. Busca en el sitio web del proyecto una página del “equipo”, o en su repositorio para encontrar la documentación política de gobierno, para encontrar esta documentación.
Un proyecto también tiene documentación. Estos archivos están normalmente listados en un nivel alto del repositorio.
- LICENSE: Por definición, cada proyecto de código abierto debe tener una [licencia open source](https://choosealicense.com/). Si el proyecto no tiene una licencia, entonces no es de código abierto.
- README: El archivo README es un manual de instrucción que da la bienvenida al proyecto a los nuevos miembros de la comunidad. Explica por qué el proyecto es útil y cómo comenzar.
- CONTRIBUTING: Mientras que el archivo README ayuda a las personas a usar el proyecto, el archivo CONTRIBUTING ayuda a las personas a contribuir con el proyecto. Explica qué tipo de contribuciones son necesarias y cómo llevar adelante el trabajo. Si bien no todos los proyectos tienen un archivo CONTRIBUTING, su presencia señala que se trata de un buen proyecto para contribuir.
- CODE_OF_CONDUCT: Sienta sólidas reglas sobre la conducta de los participantes asociados y ayuda a facilitar un entorno acogedor y amistoso. Si bien no todos los proyectos tienen un archivo CODE_OF_CONDUCT, su presencia señala que se trata de un buen proyecto para contribuir.
- Otra documentación: Puede haber documentación adicional, como tutoriales, recorridos o políticas de gobierno, especialmente en proyectos de mayor envergadura.Finalmente, los proyectos de código abierto utilizan las siguientes herramientas para organizar la discusión. La lectura de estos archivos te darán una buena imagen de cómo piensa y trabaja la comunidad.
- Seguidor de problemas (Issue tracker): Es donde las personas discuten los problemas relacionados con el proyecto.
- Pull requests: Es donde las personas discuten y revisan los cambios que están en progreso.
- Foros de discusión o lista de correos electrónicos: Algunos proyectos pueden utilizar estos canales de conversación para tópicos de conversación (por ejemplo “Cómo hago para… o “Qué piensas sobre…“ en lugar de reportes de errores o pedido de requerimientos). Otros utilizan un rastreador de problemas para todas las conversaciones.
- Canal de chat síncrono: Algunos proyectos utilizan canales de chat (como Slack o IRC) para conversaciones casuales, colaboración e intercambios rápidos.Referencia: https://opensource.guide/how-to-contribute/#anatomy-of-an-open-source-project
Zyruks
commented
1 year ago Usualmente, deberías abrir un pull request en las siguientes situaciones:
Enviar arreglos triviales (por ejemplo, una corrección tipográfica, un enlace caído o un error obvio).
Comenzar a trabajar en una contribución que ya fue solicitada, o que ya discutiste en un problema.Un pull request no representa trabajo terminado. Usualmente, es mejor abrir un pull request de forma temprana, de manera que otros puedan observar o dar retroalimentación a tu progreso. Solo márcalo como “trabajo en proceso” (WIP por sus siglas en inglés, work in progress) en la línea del tema. Siempre puedes agregar más commits después.
Si el proyecto está alojado en GITHUB, acá te explicamos los pasos para enviar un pull request:
Aquí más información sobre el tema de como empezar un open-source, podríamos comenzar por esto y armar el pseudo-open-source de la comunidad
hardstonepaul
commented
1 year ago Aquí les dejo uno de ejemplo. El nuevo tema (default) para la ultima version de Prestashop e-commerce en open source: https://github.com/PrestaShop/hummingbird
O también de la aplicación pero esta si esta en project classic: https://github.com/PrestaShop/PrestaShop
Siempre tienen buena cantidad de PRs y Issues
AndryOre
commented
1 year ago Esto seria util tambien: https://allcontributors.org/
Este articulo tiene buena informacion: https://medium.com/geekculture/how-to-create-an-open-source-project-4d89bba90bef
serudda
commented
1 year ago Anatomy of an open source project
Every open source community is different.
Spending years on one open source project means you’ve gotten to know one open source project. Move to a different project, and you might find the vocabulary, norms, and communication styles are completely different.
That said, many open source projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project.
A typical open source project has the following types of people:
- Author: The person/s or organization that created the project - Owner: The person/s who has administrative ownership over the organization or repository (not always the same as the original author) - Maintainers: Contributors who are responsible for driving the vision and managing the organizational aspects of the project (They may also be authors or owners of the project.) - Contributors: Everyone who has contributed something back to the project - Community Members: People who use the project. They might be active in conversations or express their opinion on the project’s directionBigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project’s website for a “team” page, or in the repository for governance documentation, to find this information.
A project also has documentation. These files are usually listed in the top level of a repository.
- LICENSE: By definition, every open source project must have an [open source license](https://choosealicense.com/). If the project does not have a license, it is not open source. - README: The README is the instruction manual that welcomes new community members to the project. It explains why the project is useful and how to get started. - CONTRIBUTING: Whereas READMEs help people use the project, contributing docs help people contribute to the project. It explains what types of contributions are needed and how the process works. While not every project has a CONTRIBUTING file, its presence signals that this is a welcoming project to contribute to. - CODE_OF_CONDUCT: The code of conduct sets ground rules for participants’ behavior associated and helps to facilitate a friendly, welcoming environment. While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to. Other documentation: There might be additional documentation, such as tutorials, walkthroughs, or governance policies, especially on bigger projects.Finally, open source projects use the following tools to organize discussion. Reading through the archives will give you a good picture of how the community thinks and works.
- Issue tracker: Where people discuss issues related to the project. - Pull requests: Where people discuss and review changes that are in progress. - Discussion forums or mailing lists: Some projects may use these channels for conversational topics (for example, “How do I…“ or “What do you think about…“ instead of bug reports or feature requests). Others use the issue tracker for all conversations. - Synchronous chat channel: Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges.
@Zyruks tendrás las referencia bibliográficas a la mano? gracias
Zyruks
commented
1 year ago Zyruks
commented
1 year ago Después de investigar sobre la gestión de proyectos en GitHub, considero que GitHub Organizations es una herramienta ideal para crear una entidad organizativa para creadores independientes. (Indie Creators)
Al crear una organización en GitHub, se puede tener un mayor control sobre los miembros y sus permisos dentro de la organización. Además, se pueden crear equipos dentro de la organización para trabajar en proyectos específicos y asignar roles a los miembros según su experiencia y habilidades.
https://excalidraw.com/#room=792c34d782ed43434508,61heJlivgES9q0Ypvoe_dg
@sruda
CarlosSandoval-03
commented
1 year ago Encontré este clon de Medium.com open source, cuyo propósito es simular el flujo de trabajo de un proyecto real y emplear buenas prácticas en el proyecto:
ManuelGil
commented
1 year ago En lo personal hice dos videos hablando al respecto, en dado caso propondría un taller donde podemos hablar de esto. Les comparto los dos videos por aquí por si los desean ver:
serudda
commented
1 year ago Gente voy a dar por pausada esta tarea aqui... la ida es que se mueva al nuevo repo "indie-creators-community"... pero no cerrare esta por que siento que aqui hay info valiosa. @Zyruks
serudda
commented
1 year ago Gente voy a cerrar este issue solo para limpiar un poco... pero aqui queda la info investigada.
Para poder tener un flujo de trabajo más ordenado, y coordinado es necesario aprender de las bases: Como es colaborar dentro de un proyecto Open Source.
Revisar ejemplos reales de proyectos reales, y analizar muy bien como es el flujo de contribución dentro de un proyecto Open Source.
Criterios de Aceptación: