Ideas

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

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

No dudes en contactar con los mentores o colaboradores listados en esta página para cualquier pregunta o aclaración. Puedes 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 medida que se incorporan mentores adicionales.

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

Volver a [Listado de ideas]

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 Roles. Publicación 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*:

    • Funciona 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*:

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

  12. Semana 12:

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

Mejorar Panel de Control de Calidad (QA) de Fedora

Volver a [Listado de ideas]

El panel de control de calidad (QA) 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 (QA) 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, p.e.

    • Planificación 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)

    • Publicación del blog de la comunidad Fedora

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

  6. Semana 6

    • Cambios basados en los comentarios

    • 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 (QA) de Fedora

  8. Semana 8

    • Cambios basados en los comentarios

    • Codificación

  9. Semana 9

    • Codificación y finalización

  10. Semana 10*

    • Toques finales y despliegue

    • Publicación del blog de la comunidad Fedora

Mejora de métricas de automatizado de la comunidad Fedora

Volver a [Listado de ideas]

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 crear arte gráfico en 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. Semanas 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. Semanas 10-11*:

    • Explora nuevas cosas para arte gráfico y presentaciones

  10. Semana 12:

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

Admite anulaciones de repositorio en rpm-ostree

Volver a [Listado de ideas]

Hoy, 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 anula remplazo del 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 ›