To make it easy for you to get started with GitLab, here's a list of recommended next steps.
Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
## Add your files
-[ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
-[ ] [Add files using the command line](https://docs.gitlab.com/ee/gitlab-basics/add-file.html#add-a-file-using-the-command-line) or push an existing Git repository with the following command:
-[ ] [Set up project integrations](https://gitmilab.redclara.net/el-bongo/minutas-reuniones-de-consorcio/-/settings/integrations)
## Collaborate with your team
-[ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
-[ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
-[ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
Use the built-in continuous integration in GitLab.
-[ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/index.html)
-[ ] [Analyze your code for known vulnerabilities with Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
-[ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
-[ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
-[ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
***
# Editing this README
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thanks to [makeareadme.com](https://www.makeareadme.com/) for this template.
## Suggestions for a good README
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information.
## Name
Choose a self-explaining name for your project.
## Description
Let people know what your project can do specifically. Provide context and add a link to any reference visitors might be unfamiliar with. A list of Features or a Background subsection can also be added here. If there are alternatives to your project, this is a good place to list differentiating factors.
## Badges
On some READMEs, you may see small images that convey metadata, such as whether or not all the tests are passing for the project. You can use Shields to add some to your README. Many services also have instructions for adding a badge.
## Visuals
Depending on what you are making, it can be a good idea to include screenshots or even a video (you'll frequently see GIFs rather than actual videos). Tools like ttygif can help, but check out Asciinema for a more sophisticated method.
## Installation
Within a particular ecosystem, there may be a common way of installing things, such as using Yarn, NuGet, or Homebrew. However, consider the possibility that whoever is reading your README is a novice and would like more guidance. Listing specific steps helps remove ambiguity and gets people to using your project as quickly as possible. If it only runs in a specific context like a particular programming language version or operating system or has dependencies that have to be installed manually, also add a Requirements subsection.
## Usage
Use examples liberally, and show the expected output if you can. It's helpful to have inline the smallest example of usage that you can demonstrate, while providing links to more sophisticated examples if they are too long to reasonably include in the README.
## Support
Tell people where they can go to for help. It can be any combination of an issue tracker, a chat room, an email address, etc.
## Roadmap
If you have ideas for releases in the future, it is a good idea to list them in the README.
## Contributing
State if you are open to contributions and what your requirements are for accepting them.
For people who want to make changes to your project, it's helpful to have some documentation on how to get started. Perhaps there is a script that they should run or some environment variables that they need to set. Make these steps explicit. These instructions could also be useful to your future self.
You can also document commands to lint the code or run tests. These steps help to ensure high code quality and reduce the likelihood that the changes inadvertently break something. Having instructions for running tests is especially helpful if it requires external setup, such as starting a Selenium server for testing in a browser.
## Authors and acknowledgment
Show your appreciation to those who have contributed to the project.
## License
For open source projects, say how it is licensed.
## Project status
If you have run out of energy or time for your project, put a note at the top of the README saying that development has slowed down or stopped completely. Someone may choose to fork your project or volunteer to step in as a maintainer or owner, allowing your project to keep going. You can also make an explicit request for maintainers.
La reunión abordó diversos aspectos del proyecto, incluyendo la colaboración en experimentos de física de partículas, la finalización de tareas administrativas y la presentación de un manual de identidad visual. Se discutieron temas relacionados con la implementación de logos, la creación de plantillas para presentaciones y la planificación de diferentes paquetes de trabajo. Además, se trataron asuntos sobre la estructura de un informe, la entrega de Fablabs y la organización de futuras reuniones con las comunidades científicas participantes.
### Next steps
- Luis y José: Preparar el borrador de la introducción y la sección sobre el proyecto para el reporte.
- Gabriela: Colaborar en la redacción de la introducción y la sección sobre el proyecto para el reporte.
- Líderes de las comunidades: Escribir la sección de ciencia, estado del arte y oportunidades de colaboración para cada comunidad en el reporte.
- Camilo y Justo: Coordinar y escribir la sección de gobernanza y resumen de reuniones para el reporte.
- Luis, Justo y Camilo: Redactar la sección de currículum, diseño e implementación para el reporte.
- Equipo WP-2: Escribir la sección sobre los Fablabs para el reporte.
- Camilo y Justo: Redactar la sección de perspectivas futuras y el apéndice con información de contactos para el reporte.
- Gabriela: Organizar una reunión para la comunidad de física de altas energías, considerando la disponibilidad de la mayoría de los participantes.
- Teofilo: Contactar a Óscar para obtener su colaboración en la sección de Fablabs del reporte y en la compra de equipos.
- Equipo WP-2: Preparar la sección de Fablabs para el reporte antes del 15 de mayo.
- Gabriela: Coordinar la reunión del viernes para revisar las cotizaciones de equipos y tomar decisiones sobre las compras.
## Summary
### Colaboraciones en Experimentos De Física.
Los participantes discuten sobre la colaboración en experimentos de física de partículas, mencionando grupos de investigación en diferentes países y universidades. Gabriela informa que México participa en el experimento ALICE y tiene colaboraciones en CMS, mientras que José Ocariz proporciona detalles sobre el grupo de Valencia en ATLAS. CAMILO y los demás intercambian información sobre investigadores y grupos en España, México y otros países latinoamericanos, destacando la concentración de científicos en las principales ciudades.
### Borrador Del Manual De Identidad Visual
Gabriela informa sobre la finalización de dos Milestones: la capacitación MiLab y la solicitud de extensión para las órdenes de compra de equipos. Ysabel presenta un borrador del manual de identidad visual del proyecto, que incluye recursos gráficos y pautas para su uso. Se guardará en el repositorio Git para futuras referencias y se utilizará como base para el desarrollo de la página web del proyecto.
### Identidad Visual Del Proyecto
Ysabel presenta el manual de identidad visual del proyecto, que incluye detalles sobre el logotipo, tipografía, colores y aplicaciones. Se discute la importancia de seguir las pautas de comunicación de la Unión Europea, especialmente en cuanto al uso del logo y la mención del programa Erasmus. Además, se explora la idea de crear elementos gráficos distintivos para cada comunidad participante y se menciona que los recursos visuales se compartirán en una carpeta para su uso futuro.
### Habilitación De Logos Y Tipografía.
El equipo discute la implementación de logos y tipografía en los materiales del proyecto, destacando la importancia de seguir las pautas de la Unión Europea para evitar penalizaciones. Ysa presenta una nueva identidad visual y se debate sobre la inclusión del logo de Erasmus+. Se acuerda colocar todos los logos al final de las presentaciones y piezas gráficas, respetando la identidad de cada institución participante.
### Creación De Plantilla Oficial.
El grupo discute la creación de plantillas para presentaciones, considerando diferentes formatos y plataformas. Se decide utilizar Google Docs como la opción principal para crear una plantilla oficial, con la posibilidad de adaptar el diseño para usuarios de LaTeX. Ysa se encargará de crear la plantilla en Google Docs y proporcionará una carpeta con los recursos necesarios, incluyendo tres diapositivas clave: la portada, la diapositiva final con los logos, y una diapositiva base para que los usuarios construyan sus presentaciones.
### Planeación WP2 Y WP1.
En la reunión se discute la planificación del WP-2, incluyendo la espera de cotizaciones y la programación de una reunión de urgencia para el viernes. Se menciona la necesidad de contratar ingenieros y se solicita a Teofilo que presione a Oscar para obtener respuestas. Además, se aborda el WP1, enfocándose en la preparación de un reporte con fecha límite el 31 de mayo y un plazo interno del 15 de mayo. Camilo propone a Luis y José para trabajar en las secciones de introducción del reporte, y José sugiere incluir a Gabriela en el equipo.
### Blueprint for Building Communities
Camilo presenta la estructura de un informe que incluye objetivos, descripción de cuatro comunidades científicas, oportunidades de colaboración en Latinoamérica y una sección sobre Fablabs. Luis y Camilo proponen incluir un capítulo llamado "Blueprint to build communities" que servirá como guía para construir y organizar comunidades científicas. José Ocariz sugiere incluir una sección sobre relaciones internacionales. El grupo acuerda que este informe no solo cumplirá con requisitos burocráticos, sino que también será una herramienta útil para otros proyectos similares.
### Entrega De Paquetes Fablab.
El equipo discute la entrega del Fablab WP-2, programada para el 15 de mayo, acordando que la extensión no es tan importante como el contenido sustantivo. Gabriela informa sobre las dificultades para programar una reunión con la comunidad de física de altas energías debido a conflictos de horarios. Luis enfatiza la importancia de iniciar la compra de equipos para el proyecto. Se acuerda que el grupo intentará organizar una reunión con la mayor representación posible de los países participantes.
> AI-generated content may be inaccurate or misleading. Always check for accuracy.
