Ideas para Student Projects for 2008

Estado: Propuesto

Resumen de la idea: El equipo de control de calidad tiene un puerto medio terminado de Apport de Ubuntu; mejoraría enormemente el manejo de informes de fallos si pudiéramos terminar este trabajo.

Contactos: Añadidos por DavidNielsen. No tengo habilidades, pero espero que WillWoods pueda ser mi mentor. KyleMcMartin está dispuesto a serlo.

Notas: Puede encontrar más información sobre Apport aquí: https://wiki.ubuntu.com/Apport

Estado: Propuesto

Resumen de la idea: Necesitamos una interfaz web diseñada para que los usuarios finales accedan a información sobre los paquetes. Esta será similar a packages.debian.org o packages.gentoo.org en algunos aspectos, pero esperamos mejorarlas en varios aspectos.

Contactos: Toshio Kuratomi (abadger1999) ha aceptado encargarse de esto. Probablemente será necesaria la interacción con otros desarrolladores, ya que esto afecta a muchos sistemas. Luke Macken (lmacken), John Palmieri (J5), Ricky Zhou (ricky), Seth Vidal (skvidal) y Mike Bonnet (mbonnet) participan en proyectos relacionados con el trabajo que se realizará aquí.

Notas: Esto requiere una mejora de Base de Datos de Paquetes. El esquema de la base de datos necesitará tablas adicionales para reflejar la vista de datos del usuario final. Necesitaremos generar páginas web dinámicas para mostrar la información al usuario final y permitirle proporcionar retroalimentación o información mejorada sobre un paquete.

Requisitos de diseño:

Una maqueta de que una página pudo parecer en la Propuesta de MyFedora. Tenga en cuenta que la información del encabezado corresponde a MyFedora UI, no en PackageDB Ui, y que preferimos describir Gimp como una aplicación en vez de gimp como paquete.

Estado: Propuesto

Resumen de la idea: El Kit de Conexión de Audio Jack permite conexiones de audio entre aplicaciones de baja latencia. Muchas aplicaciones actuales en Fedora lo admiten y pueden conectarse entre sí y a la tarjeta de audio. Audacity es una de ellas. Sin embargo, su compatibilidad con Jack depende de PortAudio, y, para ser justos, la compatibilidad con PortAudio Jack es muy deficiente. Audacity es un editor de audio muy popular, pero su principal debilidad es la falta de un controlador Jack nativo adecuado. Contar con uno lo haría mucho más útil en un entorno de creación de contenido de audio.

Contactos: Agregado por Fernando Lopez

Notas: ¿Por qué es la unidad PortAudio no tan buena?

No puede reaccionar dinámicamente a los cambios en el gráfico de Jack, es decir, Audacity puede ver las aplicaciones de Jack que ya se están ejecutando, las aplicaciones iniciadas después de que se inicia Audacity son invisibles hasta que se reinicia Audacity.

Los puertos Jack solo se pueden seleccionar en el menú de Preferencias de Audacity. La forma estándar de gestionar esto en las aplicaciones Jack es seleccionar en el menú de preferencias el controlador Jack o un modo de detección automática. Si se selecciona el controlador Jack, la aplicación se conectará (registrará los puertos) a él al iniciarse (si Jack se está ejecutando) y registrará los puertos de entrada y salida con Jack. Estos se verán en el gráfico Jack y pueden ser fuente o receptor de información de audio hacia/desde otras aplicaciones o la tarjeta de sonido. Normalmente, la conexión con otras aplicaciones o la tarjeta de sonido se realiza externamente. Algunos programas añaden medios internos para conectarse a otras aplicaciones, lo que generalmente no se realiza a través del menú de preferencias (Jack es dinámico), y puede mostrar aplicaciones que se iniciaron después (en este caso) de que se iniciara Audacity. Algunos programas tienen la opción adicional de conectarse automáticamente al iniciarse a los primeros n puertos físicos de salida de audio, lo que facilita su uso.

BastienNocera: Usamos PulseAudio por defecto en Fedora, y no le veo sentido a usar Jack si usamos PulseAudio para usuarios "normales" (la mayoría no cambiará esa configuración predeterminada). Es mejor enviar esta solicitud a un proyecto Audacity SoC.

Estado:

Sumario de ideas: Func es una red de marco de trabajo para aplicaciones que permiten manipulación remota potente y script de números muy largos de las máquinas Fedora.

Esta idea es para expandir Func mediante escritura de lotes de módulos útiles para ordenar todas las cosas remotas potentes, haciéndolo el mejor API del mundo para guiones remotos de Fedora cubriendo un montón de máquinas a la vez, --con un énfasis sobre integración de Func con otras herramientas ya tenidas en Fedora. Esto sería un buen proyecto particular para alguien quien tuvo un interés en redes, clústeres, automatización, o temas de seguridad relacionadas. Las contribuciones a Func no estarían limitadas a tan solo escribir módulos, como cualquier cosa de red/automatización relativa es juego justo. Para más información contacte con MichaelDeHaan.

Contactos: MichaelDeHaan

Notas: consulte https://fedorahosted.org/func

Estado: Propuesto

Resumen de idea: Por varias razones necesitamos ser capaces de utilizar un segundo repositorio, pero aún sabemos que estuvo en la raíz de compilación, o para ser capaz de ocultar compilaciones para pre-liberación, asuntos de seguridad. Koji necesita ser capaz de importar datos del repositorio y saber donde estén los binaries mientras no los haga estar disponibles. Por tanto deseamos ser capaces de marcar una compilación como ser relacionada y oculta completamente. Desde cvs a través de a la compilación suceda para abrirlo cuando el embargo esté hecho.

Contactos: DennisGilmore

Notas: https://fedorahosted.org/koji

Estado: Propuesto

Resumen de idea: Actualmente, hay un complemento de Eclipse para editor de specfile inmensamente funcional en Fedora. Sería bueno expandir la utilidad del plugin con la capacidad de pulsar compilaciones para koji. Utilizando simulado desde dentro de Eclipse y haciendo pkgdb y funcione bodhi también sería bueno.

Contactos: AndrewOverholt

Notas:

Estado: Propuesto

Resumen de idea: El Marco de Comunicaciones del Eclipse ha compartido editando apoyo. Sería bueno de tener un gobby en segundo plano para este de modo que usuarios de Eclipse podrían aprovechar Fedora está existiendo servidor de gobby.

Contactos: AndrewOverholt

Notas: http://blog.mricon.com/2008/02/why-is-there-no-gobby-support-in.html , https://bugs.eclipse.org/bugs/show_bug.cgi?id=219829

Estado: Propuesto

Resumen de idea: Anaconda ahora admite redimensionado de partición (incluyendo NTFS) en Rawhide. Sería genial combinar esto con una herramienta de migración del datos para Ventanas o usuarios de arranque dual.

Contactos: RahulSundaram

Notas: sólo tengo la idea general. Otros más cualificados, sienten libre para voluntario

Estado: Propuesto

Resumen de idea: La idea es para actualizar el sistema que utiliza ancho de banda ocioso en una manera asíncrona, priorizada y acelerada, p.e. para actualizar paquetes asíncronamente desde el servidor. De esta manera el usuario puede continuar funcionando mientras los paquetes actualizados están siendo descargados sin ninguno de los cambios notificables dentro del ancho de banda.

Las actualizaciones pueden ser realizadas automáticamente por una tarea de cron o con yum-updatesd, pero esto hará que se utilice yum/pup em todo el ancho de banda. yum tiene una opción aceleradora pero esto decide el límite superior de empleo del ancho de banda. Mientras que con modo asíncrono, el límite puede ser decidido dinámicamente dependiendo del empleo actual. En muchos países en desarrollo la mayoría de la gente están en redes de ancho de banda bajo o ha acceso limitado a Internet. Esto les ayudará para mantener su sistema actualizado con utilización máxima de su ancho de banda.

Contactos: SunilKumarGhai

Notas: [1] También podemos tener alguna familia de marco general, los cuales pueden ser utilizados por otras aplicaciones para acelerar en servicios que proporcionan. [2] Podemos implementar esto con repositorios solo encima de http. Los repositorios ftp no funcionan. [3] ¿Tal vez funcionen con PackageKit? — RichardHughes

@RichardHughes: como la idea está moviendo en desarrollo de marco de trabajo como mencionado en el punto [1], seríamos capaces de utilizarlo. Pero aún como PackageKit tiene el segundo plano de YUM tal que los repositorios http funionarán. — sunil

Estado: Propuesto

Resumen de idea: diseño final e implementar de aplicación web que proporciona SRPMS descargables para cualquier paquete+etiqueta dentro del sistema de Control de Código Fuente del Paquete Fedora. Mientras proporcionamos SRPMS para todos los paquetes del lanzamiento, las actualizaciones y árboles sin formato varían sus paquetes más rápidamente, y retirarán los SRPMS de koji-build cuando los paquetes binarios son retirados. Esto concederían a la gente solicitar las fuentes correspondientes para los paquetes que tiene en el medio de ISO o por otro medio.

Contactos: MattDomsch

Notas: http://git.fedorahosted.org/git/?p=correspondingsource.git;a=blob;f=DESIGN;hb=HEAD tiene pensamientos de mdomsch sobre como funcionarían.

Estado: Propuesto

Resumen de idea: Bootchart es una herramienta para análisis de rendimiento, y visualización del proceso de arranque de Linux. Actualmente, bootchart utiliza un guion de bitácora para recoger información de arranque desde el interfaz de /proc. Esto además utiliza un intérprete para extraer información dentro de un formato no estandarizado. Sería bueno para:

Destrezas necesarias: Segundo plano fuerte en Sistemas Operativos. Familiaridad con programación en Python, Java/JAXP, XML y C. Alguna experiencia en las partes internas del kernel sería provechoso, pero no necesario.

Contacto: EugeneTeo, eteo_en_fedoraproject_punto_org

Notas: Consulte http://bootchart.org/, http://sourceware.org/systemtap/wiki/, http://people.redhat.com/berrange/systemtap/bootprobe/

Estado: Propuesto

Resumen de idea: SystemTap proporciona una infraestructura que simplifica la recogida de información sobre el kernel Linux en ejecución, de modo que puede ser analizado más tarde para temas de rendimiento o funcionalidad. Este proyecto implica escribir una herramienta gráfica para visualizar esta información en tiempo real, de modo que las anomalías puedan ser identificadas fácilmente. La herramienta utilizaría archivos de configuración en formato XML para describir como interpretaría la salida de los guiones. Los usuarios serían capaces de expandir la herramienta añadiendo nuevos guiones de SystemTap. Como la información sería visualizada significativamente requiere más a través de la fase de diseño. Uno de los objetivos principales es que SystemTap sea amigable para el usuario y fácil de utilizar.

Actualización: He escrito recientemente lo siguiente a un estudiante. Aquí hay más descripción del proyecto: el objetivo del proyecto es para crear una herramienta de visualización que podamos exhibir gráficas y estadísticas de una manera significativa. Otro objetivo es investigar como podemos obtener estadísticas importantes desde SystemTap, y tenerlo con formato de una manera que sea fácil para que la herramienta exhiba los resultados. De todas formas, no estoy mirando otro gnome-system-monitor. Un usuario tendría que ser capaz de especificar un guion de systemtap, lo tenga conforme a un formato de salida específica, escribir un archivo de configuración en XML para describir el formato de entrada, y formato de salida, y hacer que la herramienta de visualización lo exhiba.

Por ejemplo, queremos monitorizar el bloqueo del contenido en Linux. Escribimos un guion para obtener mantenimiento de bloqueos futex. Escribimos un archivo de configuración en XML, que especifica el formato de salida del guion, y entonces exhibe los gŕaficos/estadísticas.

Otro ejemplo, queremos monitorizar actividades de E/S dentro del sistema, tomamos un guion existente, lo modificamos para exhibir la salida para la herramienta de visualización. Escribimos un archivo de configuración en XML, especificamos cómo es la salida, y entonces exhibe las estadísticas:

Las destrezas necesarias: Segundo plano fuerte en Sistemas Operativos. Familiaridad con programación en Python/GTK, y en C. Sería útil tener algo de experiencia en los aspectos internos del kernel, pero no es necesario.

Contacto: EugeneTeo, eteo_en_fedoraproject_punto_org

Notas: Consulte http://sourceware.org/systemtap/wiki/, http://stapgui.sourceforge.net/screenshots.shtml, http://www.kernel.sg/roller/eugene/entry/mortadelo_a_graphical_systemwide_strace, http://lwn.net/Articles/271796/

Estado: Propuesto

Resumen de idea: Muchos equipos no están conectados a Internet y no pueden ser actualizados fácilmente. Una solución sería encontrar libpackagekit para utilizar y ser distribución neutral tal que todas las distros puedan beneficiarse. Para esta tarea, primero generaríamos casos de uso en nivel cima para emplear sin conexión, y expandir sobre casos de usos existentes. Esta tarea involucraría revisar Opyum o APTonCD para ideas y maneras para hacer las cosas mejores.

Esto posiblemente implicaría utilizar avahi para transferencias cliente→cliente, y tendría que tratar con el tema de confianza que surge desde esto. También implicaría generar paquetes fuera de línea para instalación automática o actualización automática. Los CD de ServicePack pudo ser trasladado sobre las cubiertas de revistas o magazzine con actualizaciones para todas las aplicaciones típicas de fedora cubran para las personas que no tengan acceso de red sin gasto. Esto podría ser investigado más tarde.

Contactos: RichardHughes, richard_en_hughsie_punto_com

Notas: El solicitante necesitaría ser familiar con C y un poco de python, pero sería una gran manera de lograr estar dentro del desarrollo de un proyecto joven de software de desarrollo rápido.

Estado: Propuesto

Resumen de idea: PackageKit es complejo, y confía en muchas partes diferentes de la pila, p. ej. yum, rpm, dbus, etc. Actualmente hay comprobaciones por sí misma solo limitadas en tiempo de compilación dentro del paquete del código fuente de PackageKit. Necesitaríamos para diseñar un arnés de pruebas de extremo a extremo para el conjunto de paquetes que probaría .rpm y yum en repositorios locales temporales para una autocomprobación completa de las rutas de código y los paquetes utilizados. Esto pudo ser utilizado para comprobar trivialmente cada versión de estos componentes antes de ser subidos para una actualización de repositorio.

Contactos: RichardHughes, richard_en_hughsie_punto_com

Notas: El solicitante necesitaría ser familiar con C y un poco de python, pero sería una gran manera de lograr estar dentro del desarrollo de un proyecto joven de software de desarrollo rápido.

Estado: Propuesto

Resumen de idea: Aún nos falta un editor no lineal bueno para vídeos ogg. Esto puede ser una aplicación con IGU sencillo basada para hacer edición no lineal de ogg. Como recortar, mezclar los vídeos. Añadiendo aún marcos para el vídeo etc. Aunque esto no es un proyecto a ser finalizado en 2-3 meses, pero seríamos capaces de tener una aplicación básica que se ejecute para hacer ediciones simples. Puede ser tener característica para subir vídeos a fedoratv o integrarlos con recordmydesktop para obtener directamente screencasts. Estoy buscando más ideas en esto.

Contactos: KushalDas kushaldas EN fedoraproject {NOSPAM} PUNTO org

Notas: La elección recomendable de lenguaje es Python o C

ValentTurkovic: Tengo 2 sugerencias; la primera es para intentar y resucitar Diva Project quién empezó como el proyecto GSC en 2006. La segunda es para trabajar con el Pitivi Project porque está en un buen camino y tiene la funcionalidad de edición de ogg e interfaz bastante fácil. Para obtener una vista general del ascenso y caída de Diva Project, por favor lea estos dos anuncios. ACTUALIZACIÓN: hay dos proyectos que parecen prometedores: saya-videoeditor 2 y myvideoeditor 3

MDK: Estado de Diva 4

Comentario sobre Diva en 5

además mire en las demos en vídeo de Diva Project: 6 7 8 9

Estado: Propuesto

Resumen de idea: Uno de los elementos que otras distribuciones han sido capaces de cumplir eso que todavía carece en Fedora es la capacidad de tener un enlace de web, lo cual permitirá una actualización y/o instalar utilizando un yum repositorio aprobado. Similar a la instalación One-Click mal nombrado de OpenSUSE, o la característica AptURL de Ubuntu, compilando un paquete de referencia del repositorio la cual utiliza entonces PackageKit o algo similar.

Contactos: ClintSavage herlo EN fedoraproject Punto org

Notas: la prueba de conceptos está disponible en lis sitios web de Ubuntu y OpenSUSE respectivamente.

http://packages.ubuntu.com/gutsy/admin/apturl

http://en.opensuse.org/Standards/One_Click_Install

Estado: Propuesto

Resumen de idea: ILA es palabra de "sánscrito" que significa "Terrestre"…​ La Idea es integrar para todos los equipos alcanzables (por medio de cualquier familia de red, internet para ser más obvio) a una web paralela la cual es alcanzable por una sola pulsación o atajo…​

déjeme poner la última línea como primero…​ "Una web paralela la cuál no depende en un proveedor de servicio central para cualquiera de sus funciones…​ la parte de núcleo del nodo está cargada funcionalmente con el escritorio" así que cada equipo conectado/en lan es capaz de ser un nodo dependiendo de los módulos activados

Es tan modular como puedan estar disponibles características nuevas…​

La arquitectura, lengua, implementación están abiertas para discusión…​ Tengo unas pocas ideas pero la cosa más relevante para escribir aquí sería casos de uso las cuales realizarán los objetivos del proyecto claros.

\1. Un Usuario está enganchado ante algún problema, tan solo pulse en un atajo para hacer visible el escritorio de la aplicación para solicitar tabulador de consulta y rellena la cuestión entonces ahora pulse 'Pedir'…​ y todos los otros equipos (alcanzables) los cuales han seleccionados quiero-respuesta-de-este-tipo-de-preguntas (la cuál es opcional) será mostrado un emergente encima del escritorio…​ todas las respuestas que están enviadas en el sistema donde fue originada. [mucho mejor entonces un algoritmo de búsqueda estás tomando respuesta desde personas reales]

\1. Puede ser utilizado para compartir archivo [no necesita explicar tan solo cosa buena de P2P]

\1. Un diseño modular permitirá a los usuarios escojer desde un número grande de módulos adjuntados como el de arriba dos como aplicaciones de Utilización-CPU-Distribuída (como SETI), mensajero Instantánea, colector de alimentaciones, novedades (los usuarios pueden añadir noticias y cada uno puede verlas en categorías diferenciadas)…​[utilice su imaginación]

\1. El requisito solo se utiliza en una característica o servicio tan solo para alcance de red. Ninguna dependencia en cualquier proveedor de servicio central

El primer tema que veo es…​ Esto «Sería» utilizable…​ (todavía es una declaración abstracta :-) ) A pesar que me gustaría que funcione en Fedora y otras Distros, portando a cualquier plataforma sería posible la idea siga en la forma abstracta es "Retirar dependencia en sistemas controlados centralmente…​ integra esta funcionalidad en el SO" por tanto esa clase nueva de apps/herramientas/características puedan ser creadas.

Contactos: Añadido por SiddharthUpmanyu, si quiere tomar este proyecto, contácteme en siddharth EN techbugs PUNTO org.

Lo siguiente son algunas ideas que vinieron en Transifex. Siéntase libre de contactar con DimitrisGlezos para más info y/o extenderles con puntos nuevos en su aplicación.

Si desea hablar sobre cualquier idea que pudiera tener, contactar con DimitrisGlezos es la mejor manera.

Además podría querer echar un vistazo en L10N/Tools/Plans .

Estado: Propuesto

Sumario de idea:

Transifex funciona bien como servidor y como sitio de flujo de trabajo del sitio web con contenido nuevo que proporciona (p.e. traductores), sin embargo no todos los usuarios encuentras la suficiente eficiencia del sitio web. Implementar un API invocable sobre http habilitará un interfaz de Línea de Orden, invocaciones AJAX, e integración con otras herramientas.

Contactos:

DimitrisGlezos

Notas:

Estado: Propuesto

Sumario de idea:

Refactorizar el código de Transifex con ganchos (commit pre, post), supera funciones, y clases con el fin de añadir un mecanismo de plugin/extensión. La metáfora de archivo abstracto, y realizar mantenimiento para los archivos PO e implementar uno nuevo para envío de imagen.

Contactos:

DimitrisGlezos

Notas:

Estado: Propuesto

Sumario de idea:

Añada la capa de usuario/autorización/permiso en la cima de Transifex, para mejorar el flujo de trabajo de Transifex que crea identificando grupos de usuario clave e implementar funcionalidad por cada uno.

Estado: Propuesto

Sumario de idea:

Actualmente Tx requiere una sincronía constante con el repositorio remoto. Un envío provoca un empujón, y las atracciones suceden continuamente. Necesitamos añadir una característica para ampliar este paradigma con los envíos que viven en Tx, hasta el siguiente empujón es ejecutado (probablemente por el desarrollador o un editor).

De este modo podemos habilitar un conjunto de material bueno como, en vez de pulsar Tx, añade mantenimiento para el desarrollador para provocar siempre que necesita. Además, teniendo un lugar de subida temporal el cual necesita aprobar antes de ser realizado actualmente con la ayuda de QA y obtener traducciones nuevas más fácilmente (dirigentes de idioma pueden revisar). Estos tampoco podrían ser utilizados como un espacio de subida temporal o como una manera de permitir envíos no autorizados (un usuario autorizado puede mover un Borrador a un envío actual).

Idea: ¿desglosar los archivos en múltiples fragmentos y enviarlos todos a la vez?

Contactos:

DimitrisGlezos

Estado: Propuesto

Sumario de idea:

Actualmente Tx sólo admite un conjunto pequeño de métodos de envío, todo ligado con un control de versión aproximado de cometer. Queremos crear un sistema de sumisión abstracto desacoplado desde vcs. En la cima de eso que deseamos es recompilar todos los métodos de envío actual y para implementar un conjunto de otros métodos solicitados tales como entrega de correo-e, rellenar un ticket en trac o bugzilla etc.

Además un objetivo primario es construir un Cliente de CLI tal que los traductores puedan enviar sus traducciones directamente desde su terminal.

Info: Propuesto por Christos Trochalakis (aplicación: Envíos Tx revisitados )

Estado: Propuesto

Sumario de idea:

Actualmente Transifex se ejecuta como servidor de web, ejecutando las subidas actuales dentro del mismo proceso. Esto podría ser un poco de riesgo de seguridad, y nos gustaría tener se ejecute el servicio commit como usuario diferente. Una ventaja de esto es que cualquier repositorio puede ejecutar este ‘committer’ y controlar los envíos en vez de dar acceso de SSH a un proyecto en flujo interior.

Contactos:

DimitrisGlezos

Estado: Propuesto

Sumario de idea:

Una de las ventajas más importantes de Tx es su arquitectura de puente comunitario. Cuando existan múltiples instancias de Transifex, desearían compartir material, como usuarios, estadística de traducción y quizás envíos. P.ej. un usuario de Fedora pudo enviar algo al servidor de Debian, el cual esperará la aprobación de un dirigente de idioma de Debian.

El aspecto más importante de esta idea es diseñar la arquitectura. El estudiante necesitará tener una imagen muy buena del contenido y el flujo de traducción, el proceso adopta Transifex, y estudia como funciona la apertura de proyectos de código abierto funcionan juntos.

Además, el estudiante más probablemente deseará hablar un montón con los desarrolladores de Transifex. El inglés fluido probablemente es una importante ventaja para alguien solicitando esta idea.

Estado: Propuesto

Sumario de idea:

Actualmente nuestra aplicación para enviar traducciones (Transifex) no tiene mantenimiento i18n para que los traductores sean capaces de traducirlo. Definitivamente es una cosa que tenemos que hacer. El cara de admin de transifex necesita algunas mejoras. Actualmente sólo tenemos la opción de añadir módulos y repos, pero no podemos manejarlos con las opciones para editar o quitar. Todas las interacciones con el usuario sobre la aplicación pudo ser más rápidas y más eficientes utilizando invocaciones Ajax principalmente con JSON. Pudo mejorar la experiencia de usuario y hacer una gran mejora de aplicación para todos los traductores.

Contactos:

DiegoZacarao, DimitrisGlezos

Notas:

PD: La idea está basada en que soy capaz de trabajar.

Estado: Propuesto

Sumario de idea:

Actualmente, los traductores tienen que descargar manualmente los archivos PO desde fuera de Transifex, entonces les cambia, emplee entonces Transifex para enviar estos archivos cambiados a un repositorio de un proyecto. Esto bajaría la barra de acceso un poco si pudieron editar las traducciones, uno cada vez (p.e.: no el archivo PO completo, pero mensajes individuales), directamente en Transifex. Con Pootle, hay un editor de archivo PO basado en web el cuál pudo ser integrado con Transifex.

El trabajo propuesto aquí relaciona obtener junto el trabajo con Pootle y Transifex, de una manera que Pootle utilice Transifex para manipular y enviar archivos. La idea es que tenemos un comunitarios que ya utiliza un flujo de trabajo alrededor de traducciones tradicionales, céntricas en VCS, las cuales les gustaría utilizar traducción basada en web para algunos módulos. Aquí hay algunos detalles acerca de qué pudieron ser realizadas:

Contactos:

NilsPhilippsen, DimitrisGlezos

Notas:

Estado: Propuesto

Sumario de idea:

smolts.org ya almacena mucha información. Tomando la información fuera de lo público en la manera que es útil para la gente es complicado. Hay un número de maneras que esto puede ser realizado, y hemos discutido mucho. Estamos buscando a alguien quien esté interesado en encontrar las maneras de decir a la gente más sobre su propio equipo.

El programa Smolt recoge estadística sobre el hardware que se ejecuta en Linux y otros datos que van con ello. Recoge listados de dispositivos hardware, tipo de CPU, información del disco duro y otras estadísticas para cada máquina. Mientras podamos entregar estadística que sean útiles como factoids divertidos, no ayudan a las personas que buscan información detallada. También esto no informa a la gente acerca de asuntos conocidos sobre su máquina. Dos ejemplos clásicos de qué estamos buscando son éstos:

Estos son solo directrices de las cosas que buscamos. Este proyecto es muy abierto y puedes hacer lo que quieras. Las ideas nuevas son muy bienvenidas. Trabajará concurrentemente con uno o dos otros desarrolladores quienes trabajarán en ideas en paralelo, así que no estarás completamente por tu cuenta.

Necesitarás sólo algunas destrezas básicas de web y un entendiendo básico de las estructuras de datos. Este proyecto está basado sobre implementación ideas de estrépito, y no en utilizar tecnología X. Smolt se basa en Turbogears, SQLAlchemy y MySQL. La experiencia básica en cualquiera de estas tecnologías, o tan solo Python es un plus.

Contactos:

Notas:

Estado: Propuesto

Resumen de idea: Actualmente, nuestra elección de software sólo puede manipular grupos (FESCo, FAB, etc.) de una elección a la vez. Nos gustaría verlo modificado para manejar grupos múltiples a la vez.

Contactos: ToshioKuratomi, BrianPepple

Notas: El software actual que estamos utilizando reside en http://cvs.fedoraproject.org/viewcvs/fedora-vote/?root=fedora

Si hay suficiente tiempo durante el GSoC, defenderíamos reescribir este software como una app TurboGears. Esto lo hará 1) caber en nuestra infraestructura existente (auth será muy fácil, para caso). 2) Lo hace más extensible. Por tanto pudimos añadir vista de historial de elecciones pasadas, actualizaciones al vuelo sobre cómo está yendo el voto, etc.

Estado: Propuesto

"Sumerio de idea: en estas ideas de spin pueden ser elegidos mientras instala fedora. Si alguien ha descargado un dvd o un cd puede escoger un grupo predefinido de paquetes definidos en el selector de paquetes tales como elegir gamer instalará todos los juegos y utilidades disponibles en el dvd y el resto desde Internet. Esto ahorraría tiempo como no tendría que seleccionar las apps una a una dentro del selector de paquete"

Contactos: arnavkalra007@gmail.com

Notas:

Estado: Propuesto o A punto para Uso

Sumario de idea:

Contactos:

Notas: