Ideas

Fedora está participando en el Outreachy ejecutando desde mayo a agosto del 2021 y estamos aún para los participantes en esta temporada.

Si eres estudiante y quieres participar en Outreachy, no dudes en consultar esta lista de ideas. Es posible que se añadan más ideas durante el periodo de solicitud.

No dude en contactar con los mentores o colaboradores listados en esta página para cualquier pregunta o aclaración. Puede encontrar personas útiles en el canal IRC o usar la lista de correo. Puede ser usada para obtener ayuda con problemas de programación.

Lista de ideas

Las ideas están sujetas a cambios a medido que se incorporan mentores adicionales.

Diseño de Desarrollo para el Outreach Revamp de la Comunidad Fedora

Volver a [Listado de idea]

El equipo de diseño de Fedora es la agencia de diseño interna de Fedora. Brindamos servicios de arte, experiencia de usuario, usabilidad y diseño general al proyecto Fedora. Esta pasantía se centrará en el desarrollo y diseño de activos para Revamp, incluidos logotipos de equipos, materiales promocionales, insignias y regalos.

Plan de trabajo de muestra para la pasantía de 12 semanas.

  1. Semana 1*:

    • Diseñe y obtenga aprobación sobre logos de sub-equipo. Aprenda sobre la Renovación del Alcance Comunitario. Reúnase con los codirectores de Revamp.

  2. Semana 2:

    • Inicio encima de distribución para páginas de Manual de Rol. Postee de blog a blog comunitario.

  3. Semana 3*:

    • Trabajar en el diseño de los manuales de roles y comenzar con las insignias.

  4. Semana 4:

    • Completar el diseño de los manuales de roles y empezar a crear versiones para cada rol. Seguir trabajando en las insignias.

  5. Semana 5:

    • Revisiones en las páginas del manual de roles. Continuar trabajando en las insignias. Reunirse con los codirectores de Revamp.

  6. Semana 6:

    • Finaliza las insignias y las páginas del manual de roles. Publicar en el blog de la comunidad.

  7. Semana 7:

    • Comenzar a diseñar artículos promocionales y a redactar un plan de marketing.

  8. Semana 8:

    • Revisa los diseños de los artículos promocionales. Incorpora los comentarios al plan de marketing y empieza a esbozar ideas.

  9. Semana 9:

    • Finalizar los diseños de los artículos promocionales. Comenzar a crear recursos para el plan de marketing, como publicaciones en redes sociales, entradas de blog y vídeos HDYF?. Reunirse con los co-líderes de Revamp.

  10. Semana 10:

    • Trabaja en los recursos para el plan mercantil y empieza a publicarlos según se vayan produciendo. Crea algunos diseños para la página de documentación de CommOps.

  11. Semana 11:

    • Trabajar en los activos del plan de marketing y revisar los diseños para la página de CommOps.

  12. Semana 12:

    • Finalizar y subir todo el trabajo. Continuar publicando materiales de marketing. Publicar en el blog de la comunidad.

Mejorar Panel de Control de Calidad de Fedora

Volver a [Listado de idea]

El panel de control de calidad de Fedora es una idea de aplicación web que serviría como plataforma para las actividades relacionadas con el control de calidad. Actualmente, contamos con una gran cantidad de documentos, herramientas y procesos útiles, pero están dispersos o, a veces, son difíciles de acceder o comprender sin conocimientos previos. Identificamos este problema como el principal obstáculo para la incorporación de nuevos miembros a la comunidad. El objetivo de este proyecto es simplificar la curva de aprendizaje. Contamos con una prueba de concepto (PoC) básica que podría servir como base para el desarrollo o como inspiración para una revisión.

Plan de trabajo de muestra para la pasantía de 12 semanas.

  1. Semana 1

    • Crear un diseño final a partir de las ideas de maqueta proporcionadas

    • Recibir comentarios del equipo de control de calidad de Fedora

    • Cambios de diseño basados en comentarios

  2. Semana 2

    • Estructura y componentes del proyecto según el diseño final

    • Codificación (creación de un componente uno a la vez, por ejemplo)

    • Cronograma de Fedora, resumen de bloqueadores, guía de contribución, …​)

  3. Semana 3

    • Codificación

  4. Semana 4

    • Codificación (los componentes están "listos", funcionan individualmente, pero no necesariamente forman una aplicación)

  5. Semana 5

    • Codificación (juntar componentes para formar una aplicación)

    • Entrada del blog de la comunidad de Fedora

    • Obtener retroalimentación del "público en general"

  6. Semana 6

    • Cambios basados en la retroalimentación

    • Codificación

  7. Semana 7

    • Codificación (de ahora en adelante, la aplicación generalmente representa el diseño final de la semana 1)

    • Recibir comentarios del equipo de control de calidad de Fedora

  8. Semana 8

    • Cambios basados en la retroalimentación

    • Codificación

  9. Semana 9

    • Codificación y finalización

  10. Semana 10

    • Toques finales y despliegue

    • Entrada del blog de la comunidad de Fedora

Mejorar las métricas automatizadas de la comunidad de Fedora

Volver a [Listado de idea]

Muchas actividades en Fedora generan actividad en el bus de mensajes de Fedora. (Más información aquí: https://communityblog.fedoraproject.org/moving-from-fedmsg-to-fedora-messaging/). Estos mensajes se pueden usar para medir y graficar la participación de la comunidad.

El código Python rudimentario para hacer esto está en: https://pagure.io/fedora-contributor-trends

He utilizado estos datos en charlas (https://mattdm.org/fedora/2016devconf/) y para fundamentar la toma de decisiones del proyecto. También tengo una versión actualizada semanalmente aquí: https://mattdm.org/fedora/fedora-contributor-trends/.

Este proyecto consistiría en mejorar y actualizar este código de hasta seis maneras diferentes:

  1. Como se describe en la entrada del blog anterior, el bus de mensajes de Fedora se encuentra en plena transición a una nueva tecnología, lo que podría dejar obsoleta la forma en que el script actual obtiene datos. Consulte https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/6NRUH7EP6ERTBUEVTTXYLA25QUSHTKBE/ para ver posibles planes. La ventaja es que algunas de las nuevas opciones podrían ser mucho mejores; el código actual afecta gravemente al servidor.

  2. El código es realmente cutre y feo. Pudo utilizar refactorización y mejorarse.

  3. Hay algunas fuentes de datos que no estamos usando y que podríamos usar: hay mensajes de Pagure y habrá algunos de Discourse que serían excelentes candidatos.

  4. Las visualizaciones que creé para mi presentación de 2016 son buenas, pero hay muchas otras maneras de analizar los datos. Piensa en nuevas maneras de analizarlos que puedan aportar más información.

  5. Encuentra un lugar oficial donde esto se ejecute en lugar del servidor personal de mattdm.

  6. En pocas palabras, los gráficos y los informes podrían ser más atractivos.

No es necesario completar los seis para el éxito del proyecto. El solicitante podría centrarse en dos o tres de ellos, lo cual sería enormemente beneficioso.

Plan de trabajo de muestra para la pasantía de 12 semanas.

  1. Semana 1*:

    • Familiaridad con los conceptos

  2. Semana 2:

    • Instancia local de código existente

  3. Semana 3*:

    • Agregar nuevas fuentes de datos

  4. Semana 4:

    • Limpieza y refactorización de código

  5. Semana 5-6:

    • Migración a un nuevo reemplazo teórico de Datagrepper

  6. Semana 7:

    • Más limpieza y refactorización de código

  7. Semana 8:

    • Implementar en algún lugar de la infraestructura de Fedora para realizar pruebas manuales

  8. Semana 9:

    • Automatizar actualizaciones diarias o semanales

  9. Semana 10-11:

    • Explora nuevas cosas para graficar y presentar

  10. Semana 12:

    • Haz que los gráficos y los informes sean bonitos

Admite anulaciones de repositorio en rpm-ostree

Volver a [Listado de idea]

Actualmente, la compatibilidad con rpm-ostree anula la de los archivos RPM descargados localmente. Por ejemplo:

Esto funciona muy bien, pero es limitante. Hay muchas situaciones en las que se preferiría anular RPM desde los repositorios de yum, de la misma forma que se instalaría yum en un sistema tradicional.

Queremos enseñarle esta capacidad a rpm-ostree. La experiencia de usuario en la línea de comandos sería similar, por ejemplo:

``` rpm-ostree override replace kernel ```

Excepto que rpm-ostree buscaría los paquetes especificados en los repositorios yum habilitados.

==== Plan de trabajo de muestra para la pasantía de 12 semanas.

. **Semana 1-2**:
  * Poner en marcha y configurar el entorno del desarrollador.
. **Semana 3-4**:
  * Finalizar el enfoque de implementación.
. **Semana 5-9**:
  * Trabajar en la implementación, iterar en función de los comentarios de los mentores.
. **Semana 10-12**:
  * Objetivos ambiciosos según el interés. Algunas ideas incluyen una mejor integración de las anulaciones con COPR, Bodhi o Koji, y escribir una entrada en el blog de fedmag sobre la nueva función. Semanas 1 y 2: Puesta en marcha y configuración del entorno de desarrollo.

Want to help? Learn how to contribute to Fedora Docs ›