Educating to contribute in FLOSS

A follow up conversation on the topics of communities with a friend from the central america free software community enter into an issue that I have talk about latetly. Changing the approach of free software is being presented to the people.

Community should be a great assets to the way free software package, and some of the talks should be developed within the related events.

What kid of community can we talk about?

  • Community tools is key for people to understand what do they do.
  • Is important to be related to the most common processes happening in free software.
  • It also need to be an understanding of the impact they can have in FLOSS.

Culture is really what FLOSS should be about and understanding the culture is as key as acknowledge the existance of Free software. Independent of the project the culture of sharing goes above the lookout for free download. It also matters the milestoes of the project the activity of the community. The speed of bugs closed and the ammount of support and documentation behind the project.

All these factors could be appreciated with the proper background in communities and developments from them.

Some critics about of the romantic conception of Free software by the communities in Latin America. Including the relative shortvision into communities as itself and nurturing the participatory spirit by giving recognition.

I embed the chat log ahead, although is in spanish is important to see how its similar to other communities.

<JZA>    saludos gente
<fdelapena>    saludos JZA
<fdelapena>    sí πŸ˜€
<JZA>    fdelapena: eso veo el cuarto se ve lleno pero nunca habla nadie
<fdelapena>    la mitad ausentes, un tercio bots
<fdelapena>    pero lo normal es listas de correo
<fdelapena>    y si descubres un bug pobre de ti que lo comentes sin estar en bugzilla πŸ˜€
<fdelapena>    las comunidades podrían usar un tracker también para no olvidar tareas de todo tipo
<fdelapena>    pero año tras año el tracker se llama “wiki” y “etherpad” y web nueva cada año de evento
<fdelapena>    critica constructiva
<fdelapena>    para no acabar en la parte contratante de la primera parte, como decia Groucho Marx
<JZA>    fdelapena: si los usuarios les explota sus cabezas ver un bugzilla
<JZA>    asi sea uno sencillo como google code
<fdelapena>    bugzilla es un poco mindfuck
<JZA>    quieren ver botones con fondos gradiales
<JZA>    y autocompletados
<fdelapena>    mantis también es un poco complejo
<JZA>    igual
<fdelapena>    redmine o traq no son la panacea pero son más sencillos
<fdelapena>    o flyspray o su fork
<JZA>    tambien siento que se subutiliza, por que creo que bugzilla soporta plantillas
<JZA>    para que los usuarios no tengan que llenar tanto, pero por el otro lado le metene dos o 3 preguntas mas en el text area para que lo documente bien.
<fdelapena>    Project de drupal también destroza usuarios
<JZA>    pero en vez de hacer tantos eventitos de usa el software libre deberian hablar mas de cosas como como reportar un bug
<JZA>    como participar en las listas de correo
<JZA>    y dejar de tratar a ingenieros como usuarios
<JZA>    es como hacer una campania de vacunacion para la escuela de doctores
<fdelapena>    +1
<fdelapena>    en 2 años en un país de la zona he visto sobre todo 2 extremos
<fdelapena>    1: eventos generalistas
<fdelapena>    2: eventos no generalistas de proyectos “por las nubes”
<fdelapena>    (de cazainversores)
<fdelapena>    pero en cambio de iniciativa de hacklabs no hay mucha cosa encima de la mesa
<fdelapena>    y hay mucha gente que sabe escribir código pero dispersa
<JZA>    aparte el saber escribir codigo no es igual a saber trabajar en proyectos colaborativos.
<JZA>    o que sepa como funciona una comunidad las tareas estandarizadas como QA, l10n, Testing, Commits, etc.
<JZA>    yo en algunas platicas empiezo preguntando, cuantos han usado una lista de correo, cuantos un bugzilla, cuantos un repositorio tipo GIT o SVN
<fdelapena>    otro viejo poco conocido tracker http://issues.thebuggenie.com/thebuggenie/issues/open
<JZA>    pues de hecho el getsupport es la parte ‘bonita’ de un sistema de tickets.
<JZA>    con gradiales y badges
<fdelapena>    y la verdad muy poca gente conoce esos pilares básicos de comunidad de desarrollo de software
<JZA>    los ‘desarrolladores’ estan mas preocupados de que IDE escojer
<JZA>    que realmente la construccion de software
<JZA>    como diria un amigo, ‘Wizard Driven Development’
<fdelapena>    y basado en meritocracia?
<JZA>    eso es otro, es basado en titulos que se inventan
<JZA>    pero bueno, haber que pasa, es parte de la distorcion que se tiene en el software libre.
<JZA>    que he visto en latam
<fdelapena>    http://24.media.tumblr.com/tumblr_m44r0g8UZY1rvfebjo1_400.jpg
<fdelapena>    http://25.media.tumblr.com/tumblr_m44qqy8WxG1rvfebjo1_500.jpg
<fdelapena>    se resume en eso
<JZA>    por ejemplo creo que nunca he visto bughunts o sesiones fisicas para ir aplastando bugs
<JZA>    seee…
<JZA>    me ha pasado
<JZA>    de hecho en vez de crearse tantos sitios de proyectos se debe de trabajar en algoritmos de deciison que puedan ‘medir’ las propuestas en la comunidad.
<JZA>    y lo mas importatne, CONCLUIR
<fdelapena>    para eso hay milestones, si no se desanima cualquiera
<fdelapena>    y no estar en master o trunk eternamente
<fdelapena>    sn metas, dificil
<fdelapena>    sin*
<JZA>    claro
<fdelapena>    no se tiene sensacion de avance y eso es sintoma de quemarse
<fdelapena>    http://25.media.tumblr.com/tumblr_m3tt0sPnD01rvfebjo1_400.jpg
<JZA>    pues en teoria para eso es el QA
<JZA>    no puedes tener todos desarrollando cosas nuevas
<JZA>    por eso hay ciclos y mini-releases enfocadas a estabilizacion
<JZA>    y otras a innovacion
<fdelapena>    eso se ve mucho en la calidad y usabilidad de los programas de voz por IP libres
<fdelapena>    llega skype, feo, pocas características pero tiene 2 cosas: UX mínima y NAT traversal
<fdelapena>    y lo demás puede esperar
<fdelapena>    bueno, tiene calidad de sonidoo y baja latencia, pero eso ya existe hecho
<fdelapena>    al final encuentras 20 programas que hacen lo mismo y ninguno que de la talla
<JZA>    lo que pasa es que cuando estas adentro del una comunidad, ves que hay muchas cosas que se pueden ahcer.
<JZA>    y no es criticamente tan super hax0r
<JZA>    pero vas con la comunidad, y todos te ven como alien
<fdelapena>    eso es típico en los grupos
<JZA>    y te dicen, es que no tengo tiempo, me estoy lavando las unias … o si son muy honestos.
<JZA>    yo solo estoy aqui, por que hacen fiestas despues de los eventos
<fdelapena>    pero forma parte ed la naturaleza de la sociedad
<fdelapena>    y h
<JZA>    es cierto pero creo que no hay mucho empuje por evangelizar realmente
<JZA>    la mayoria de los posts de blogs de SL son anuncios del ultimo android
<JZA>    y como instalarte x o y programa
<fdelapena>    si un grupo es muy especializado hay cierta tendencia al elitismo
<JZA>    en vez de reportar sobre las necesidades de los proyectos libres y como ayudar.
<fdelapena>    pero pasa en cualquier ámbito
<fdelapena>    de todos modos es la falta de tiempo para convertir las intenciones en hechos el principal problema
<JZA>    por ejemplo la mayoria de los desarrolladores de SL no son por que desarrollen para el software sino son usuarios de lenguajes libres para sus proyectos propios.
<fdelapena>    si es un grupo que quiere claborar desinteresadamente debería haber más eventos locales, cercanos y en fines de semana
<fdelapena>    sí, es cierto
<JZA>    fdelapena: de hecho pienso que es lo opuesto.
<fdelapena>    aunque dicho proyecto sea libre
<fdelapena>    JZA, llevo meses intentando cazar un evento y me resulta imposible porque coinciden con horario laboral
<JZA>    si es un grupo que quiere contribuir, spamearian las listas investigando que hace falta en X o Y software.
6:0<fdelapena>    es cierto
<fdelapena>    de hecho lo que podría funcionar sería lo que comentabas
<fdelapena>    elegir un proyecto que sea del interés del grupo
<fdelapena>    estudiar su funcionamiento y carencias
<fdelapena>    y montar una hackaton para un punto específico
<fdelapena>    completar características, bug hunt, etc.
<JZA>    exacto
<JZA>    y es cultural, realmente nunca has estado en uno, es dificil que lo quieras.
<JZA>    en la universidad estan acostumbrados a conferencias y talleres, asi que hacen conferencias y talleres
<JZA>    y cuando les dices, hagan un hackaton, te ven como si fueras un marciano
<JZA>    aunque hay un punto valido, no todos pueden programar (en comunidad) es decir escribir codigo mientras otra gente estan hablando.
<fdelapena>    y en cuanto a infraestructura también tal vez hay carencias
<JZA>    por eso los hackatons se ven como 10 personas pegadas a sus pantallas con sus audifonos y cada uno en los uyo
<JZA>    *suyo
<fdelapena>    entonces para eso mejor estar en casa
<fdelapena>    y hacerlo virtual
<JZA>    asi es
<JZA>    pero en una empresa normal tienes de todo
<JZA>    tienes desde los programadores de cubiculo, como las early meetings para hablar de los bugs y de los issues mas fuertes de la semana.
<JZA>    y el COB (Close of Business) para preparar los stages para la siguiente semana.
<fdelapena>    y cada persona es un mundo, los hay que funcionan mejoro en parejas
<fdelapena>    no hay una metodología que funcione para todos
<JZA>    y dan cupcakes a los que se rifaron cerrando un nasty bug
<JZA>    bueno pero ‘pareja’ igual puede ser presencial o virtual.
<fdelapena>    ta claroo
<fdelapena>    de hecho se llega a perder mucho tiempo en reuniones presenciales
<JZA>    asi es, aunque tambien en la lista de correo πŸ˜€
<fdelapena>    se puede hablar igual de rapido con un headset
<fdelapena>    incluso hay menos distraccion, se presta mas atencion a la conversacion
<JZA>    muchas veces mis proyectos se han ido al carajo por distraerme en la discusion del bug en la lista
<JZA>    en vez de terminar el fucking commit
<fdelapena>    al final los proactivos parches hacen el 90% del ahorro de discusión
<JZA>    de hecho muchos hackatons es precisamente para terminar o pulir los parches mas que crear nuevos parches
<fdelapena>    y por pereza la gente dice “lo que diga la ruvia”
<fdelapena>    rubia*
<fdelapena>    en qué proyectos te has solido meter?
<JZA>    pues he contribuido muchos anios a Openoffice, y el anio pasado entre en OLPC-Sugarlabs
<JZA>    tengo mis propias ideas sobre la universidad, y es mas enseniar a la gente a leer codigo mas que escribirlo
<fdelapena>    +1
<JZA>    es como las materias literarias, te meten a leerte 200 libros antes de escritura ceativa o algo asi.
<fdelapena>    además la mayoría del trabajo del mundo real es eso
<fdelapena>    ya me imagino un “comentario de texto” pero de código
<JZA>    yo siempre cuando voy a una proyecto por lo menos intento ver el websvn parra ver mas o emnos como esta armado
<fdelapena>    y no solo decir “qué hae este código de 10 líneas?” sino algo más profundo
<JZA>    minimo para saber en que fregado lenguaje esta escrito
<JZA>    o que toolkit usan
<JZA>    pues en teoria para eso estan los comentarios del commit
<fdelapena>    y ganar habilidad para seguir los estilos y acostumbrarse rápidamente a ellos
<JZA>    que hace cuando fue pusheado
<JZA>    empujado?
<JZA>    :p
<fdelapena>    jeje
<JZA>    si, en el wiki tenemos varias paginas de convenciones de codigo
<JZA>    para que sea mas facil leerlo
<JZA>    la otra tecnica que he ideado es…
<JZA>    crear bugs
<fdelapena>    que muchas veces no harían falta, solo en caso de duda puntual, o de desastre existente, para ello
<fdelapena>    porque leyendo dicho codigo ya se ve rápidamente el estilo
<JZA>    osea irse en reversa… desde el bug resuelto hasta generar el bug
<fdelapena>    y cómo funciona?
<fdelapena>    hay gente que tiene esa capacidad innata πŸ˜€
<JZA>    vas a bugzilla ves el parche he intentas generar lo que el bug hacia
<JZA>    pues es que muchos errores por ejemplo son de dedo, que hizo que la barra ya no empujara el contenido
<JZA>    ves el parche que lo resolvio y te vas recursivamente hacia como era el error
<JZA>    y ahi puedes ver si fue que llamo mal el componente o le falto algun parametro
<JZA>    al objeto
<JZA>    damn… este juego ya se vacio y aun faltan 5 min
<JZA>    que en basquetbol es una eternidad
<fdelapena>    cada pausa por falta personal
<fdelapena>    como cuando te atascas en un código que no funciona
<fdelapena>    y te revienta las estimaciones de tiempo
<JZA>    asi es, usualmente asi como vez cuanto porblema hay con sintaxis, o los nombres demasiado similares
<JZA>    no recuerdo en donde en gnome o gtk, habian dos objetos nombrados casi igual
<JZA>    y generaban un buen de bugs
<JZA>    de sintaxis
<fdelapena>    Gtk y Gdk
<fdelapena>    πŸ˜€
<JZA>    creo que uno era plural y otro singular
<JZA>    hahahah
<JZA>    pues si para empezar
<fdelapena>    la pesadilla usando pixbuf
<fdelapena>    con gtk3 la cosa mejoró
<fdelapena>    y con Cairo en las últimas de la 2.x
<JZA>    en fin creo que eso deberia estar enfocado las comunidades mas amduras
<JZA>    o que quieran madurar rapidamente
<JZA>    πŸ™‚
<fdelapena>    en las básicas lo que comentabas
<fdelapena>    cαΈΏo usar una lista de correo (citas y respuesta top-down y otros básicos para no reventar el scroll)
<JZA>    realmente no tienes que ser programador para comitear, siempre hay areas como l10n que necesitan commits, pero por el otro lado, los programadores no son hechos a mano, es solo de dedicarse a hcer la tarea.
<fdelapena>    porque a veces pienso que es como una torre de hanoi vertical
<fdelapena>    este tipo de charlas son las que son utiles: https://www.youtube.com/watch?v=fRk97h1FLow&t=2m30s

 

Advertisements