¿Cuáles son las mayores barreras para recorrer el camino MOTU / desarrollador? [cerrado]

Para aquellos que no son MOTU (personas que mantienen los repositorios de software Universe y Multiverse ) y que no tienen planes de la variedad "Solicitaré MOTU por $ date":

¿Qué te impide a ti y a otros como tú intentar convertirte en MOTU? ¿Qué te hace pensar que no podrías convertirte en uno?

Me refiero a las barreras sociales y tecnológicas.

EDITAR: solo digo MOTU porque es un grupo bastante genérico, pero "¿por qué no estás empacando / parcheando y tienes la intención de intentar finalmente obtener derechos de carga?" Es una versión aún más general.

Proporcionar mejor documentación.

Participé en las sesiones de IRC de las semanas de desarrollo relacionadas con el empaquetado y las cosas de MOTU (ya dos veces) y descubrí que durante esas sesiones generalmente tienes una comprensión vaga del proceso. Pero si miras las páginas wiki de Ubuntu dos semanas después, ya no puedes juntar todas las piezas. Esas páginas a menudo son una especie de listas de viñetas de personas que ya entienden el proceso en detalle. Pero eso no es suficiente para que el contenido sea comprensible para los novatos.

Entonces, tal vez debería intentar que la documentación de las páginas wiki explique el proceso, las herramientas y las personas involucradas con más detalle. O incluso con ejemplos completos. Durante las sesiones de IRC siempre hay ejemplos repetibles, tal vez esos marcan la diferencia en las páginas wiki.

Creo que la mayor barrera técnica es saber cómo crear paquetes Debian. Si bien es relativamente sencillo crear un paquete de trabajo, es mucho más difícil crear paquetes que cumplan con los estándares de Debian y Ubuntu. Además, las guías sobre cómo crear paquetes normalmente abordan una situación en la que tiene el código fuente que requiere compilación. Esto puede ser confuso para aplicaciones escritas en idiomas interpretados.

La mayor barrera social probablemente sea saber cómo cargar paquetes en los repositorios de universo / multiverso. Es mucho más simple crear su propio ppa y cargar paquetes allí.

Hoy en día a la gente le gustan las contribuciones automáticas

Hace 20 años, por lo general, concentrarías una gran cantidad de tu energía en un proyecto favorito, si tuvieras uno. Hoy visita docenas de páginas de Internet al día, y hay muchas redes sociales u otras comunidades, donde puede contribuir a wikis, foros y otras cosas. Si bien esto ha llevado a que más personas contribuyan, también ha provocado que las personas esperen entradas de baja barrera (a la "simplemente haga clic en el sitio web para editarlo. De lo contrario, pueden recurrir a otras comunidades.

Por lo tanto, debe buscar barreras en el proceso MOTU. Recuerdo el proyecto GroundControl para reducir la barrera para las contribuciones de parches en proyectos alojados en launchpad. Tal vez necesite herramientas nuevas similares, por lo que los nuevos candidatos MOTU no tienen que jugar con muchas herramientas de línea de comandos. Si bien esas herramientas actuales pueden ser poderosas, probablemente se necesita mucha energía para aprender a usarlas correctamente.

La barrera más grande que he encontrado es la página del desarrollador de Ubuntu: http://www.ubuntu.com/community/get-involved/developers

Muchas veces, he decidido con entusiasmo contribuir con al menos 1 parche a Ubuntu ... así que voy al lugar natural en el sitio web ... y termino perdido en un mar de documentación. Horas después, todavía no tengo idea de para qué debería escribir un parche. Cuando miro a través de los errores de Ubuntu, a menudo encuentro parches ... muchos que simplemente se quedan allí sin usar.

En cuanto a los paquetes, he tratado de descubrir cómo hacerlos, es realmente confuso. También intenté involucrarme en Launch Pad, pero la interfaz es mucho más compleja que Source Forge, no pude obtener mi propio código en LP. Es muy difícil para un nuevo usuario.

Ser una MOTU es una responsabilidad .

Bueno, obviamente, la razón # 1 no es lo suficientemente técnicamente eficiente, y la razón # 2 es tener un montón de cosas que preferirías hacer. Pero entre su público objetivo, creo que la razón principal es que es una responsabilidad.

Si compilo un paquete para mí, a nadie más le importa si he seguido las políticas técnicas y legales. Nadie vendrá a mí esperando que empaque una versión más nueva. Nadie me pedirá que arregle errores.

Si subo mi paquete a un ppa, a algunas personas puede importarles. Pero las expectativas no son tan altas. Puedo desaparecer y dejar que la gente se queje en su blog de lo triste que es que el paquete no esté disponible para narval natty.

Si me convierto en una MOTU, de repente tengo una gran responsabilidad. Los usuarios vendrán a mí con informes de errores y se quejarán si no los resuelvo ayer. Los usuarios esperarán que cargue la nueva versión del paquete tan pronto como esté disponible en sentido ascendente. Tendré que explicar a los usuarios no técnicos cómo averiguar qué hicieron mal. A diferencia de publicar en un foro, se supone que no debo ignorar las preguntas que no tengo ganas de responder. Y otros desarrolladores podrían ir detrás de mí porque arruiné algo; esto puede ser intimidante.

¿Y qué gano yo?

• Una sensación borrosa de que he ayudado a la gente. Eso puede importar. Pero si esa es mi principal motivación, ¿cómo se puede comparar el software de empaquetado con ayudar en un comedor de beneficencia o dar tutoría a los hijos de sus vecinos inmigrantes sin trabajo?

• ¿Una viñeta en mi currículum? Meh, será mucho más apreciado participar en un programa FOSS como programador. (Le brinda experiencia con cosas como la gestión de proyectos y el mantenimiento a largo plazo que son difíciles de enseñar en los cursos universitarios). De hecho, ser un DD / MOTU parece sospechoso para los muchos empleadores que desaprueban a los empleados políticamente involucrados (usted es dando abiertamente apoyo político a FOSS).

• ¿Un sentimiento de satisfacción? Mucho menos que escribir mi propio programa desde cero. La programación es mucho más creativa que el empaquetado. Hay una gran sensación de logro en ello. Hay derechos de fanfarronear. Pero en el embalaje? Es una tarea No es glamoroso.

(Ese es un "yo" en tercera persona arriba. Creo que las razones que doy se aplican a la mayoría de las personas, pero en diferentes grados. Personalmente, es principalmente tener un grupo de cosas que preferiría hacer, y un paquete que carece de una sensación de logro creativo).

(Por curiosidad, ¿Ubuntu carece de mano de obra?)

Idioma , mi principal problema es que todavía no confío lo suficiente en el inglés, por lo que no puedo entender fácilmente lo que otros desarrolladores intentan decirme

¿Qué me detiene para convertirme en una MOTU?

A pesar de que Ubuntu es una comunidad muy agradable (todavía no me han llamado la atención las preguntas de n00bie) Creo que hay poca / documentación incompleta sobre el proceso de empaquetado (incluso la nueva Guía del mantenedor de Debian está llena de "este tema está fuera del alcance de este documento "líneas). Si tomas ese hecho y piensas en personas cuyo primer idioma no es el inglés (como yo), el proceso es aún más difícil y caótico.

Con un simple, directo al punto, la documentación de todo sería más fácil para todos nosotros, pero las personas que tienen los conocimientos técnicos para escribir esa documentación están demasiado ocupados para hacerlo.

Creo que hay varias razones para esto. También creo que las razones son a menudo individuales.

Uno de los problemas en este momento, es el cambio en todo el sistema MOTU. Creo que los cambios pueden ser confusos, y se han implementado más en líneas tecnológicas y, desafortunadamente, no incorporaron completamente a la comunidad (tal vez solo porque es confuso).

También creo que, en algunos casos, la motivación para ser un MOTU no es tan clara como podría ser. En mi humilde opinión, ser un MOTU es una responsabilidad, no un privilegio. No se trata del título, sino de la capacidad de ayudar a la comunidad Ubuntu con los derechos de acceso que vienen con él. Debido a esto, podría ser que todo el proceso de aprobación podría modificarse (o ampliarse). Las MOTU generalmente se nominan a sí mismas, y luego la junta busca si están listas para ser MOTU. Tal vez debería ser posible, que los compañeros que creen que alguien está listo para ser un MOTU puedan nominar a esa persona. Esto en mi humilde opinión representaría más el hecho de que la nominación se realiza para ayudar al proceso, no para obtener un título. Entiendo que hacer esto de la única manera también tiene sus problemas, por lo tanto, prefiero verlo como una alternativa, entonces la única forma.

También sé que ha habido algunos problemas en el pasado con personas que se centran más en KDE. Es de esperar que se hayan abordado estos problemas, pero tal vez sería bueno que eso también fuera más conocido.

Obviamente, estos son solo un par de problemas que he notado. Las personas son diferentes y verán cosas diferentes, o se verán afectadas de manera diferente por la misma cosa. Por lo tanto, estos problemas pueden no detener a todos, ni son las únicas razones para este problema.

Publiqué algunas ideas aquí: http://blog.mitechie.com/2010/08/24/ubuntu-help-wanted/

Una cosa que realmente quiero destacar es que me pregunto cuántos desarrolladores no usan sistemas de compilación que se conectan fácilmente a las herramientas de empaque. Estoy haciendo desarrollo de python. Mi mundo se centra en las herramientas de configuración y distribución, y sí, puedo tomar algo que construyo con ellas y exportarlo, pero ¿para qué? Ya tengo algo que es distribuible. Me pregunto si el aumento de los lenguajes de scripting con sus propias herramientas de compilación / métodos de distribución causa una falta de experiencia y deseo de lograr que las cosas se combinen con las herramientas de empaquetado de Debian y, por lo tanto, los niveles de MOTU.

Para mí, probablemente esté relacionado con el tiempo. Actualmente no tengo mucho tiempo para invertir. Y comencé con la detección de errores, pero pronto descubrí que las cosas eran un poco más complicadas. Y realmente necesitas hundir tus dientes en él.

Luego está la corrección de errores, que sé que disfrutaría. Lo que me impide ayudar es que necesitas ejecutar una rama de desarrollo o algo así. Una vez comencé a trabajar en un corte de papel mío en el Monitor del sistema (https://bugzilla.gnome.org/show_bug.cgi?id=611738) Así que comencé a usar Ground Control para buscar la fuente requerida y entrar allí Una solución al error. Sin embargo, resultó no ser tan fácil debido a las dependencias. Sé que solo debería trabajar en la versión de desarrollo y probar si está arreglado allí. Sin embargo, solo para intentar eso necesitaba descargar la fuente de muchos otros paquetes de gnome. Lo que no es tan fácil con el control de tierra. Y probablemente deberías hacerlo en una máquina de trabajo. Entonces me detuve allí. (Nuevamente, me llevaría demasiado tiempo, solo para comenzar)

Con respecto al embalaje, simplemente no estoy al tanto de nada que necesite embalaje. Una vez hice un tutorial sobre empaquetado y no me resultó demasiado difícil para aplicaciones pequeñas. Sin embargo, nunca salí a buscar una lista de cosas que necesitan empaquetamiento, porque sé que probablemente haya una ... :)

Básicamente, para mí es solo tiempo, quiero ayudar, pero solo tengo un par de horas (2 o algo) cada semana más o menos. Y en ese pequeño período de tiempo, parece que no puedo comenzar con esto.

Cuando creo un paquete, generalmente es para rascarme una picazón, no porque alguien más quiera el paquete. Checkinstall es lo suficientemente bueno como para hacer un paquete para mí, y luego me pica el picor, y no tengo ningún incentivo personal para hacer un esfuerzo adicional para empaquetarlo manualmente, y descubrir todas las dependencias y demás.

Así que supongo que incluso si el empaquetado para la distribución es fácil, todavía es mucho más trabajo que el empaquetado para usted.