Organizing a Mozilla community can be easy when you are a small group or can be a headache if you have more contributors than you can handle.

In the past year, Mozilla Hispano community has grown both contributors and ongoing projects, so we have been to learn how to handle from a small group to nearly 40 people.

Everything is more less easy to handle when your community is 4 or 5 people, each one usually does a different task, you normally focus on localization/user support and you just use email or a mailing list to communicate each other. The problem starts when you grow and new people wants to do different things like engagement, marketing, PR, QA…

I’m going to explain how we’ve solved it in Mozilla Hispano and I hope that could be an example to other communities in the future.

Our infrastructure is based on:

• Meritocracy: Core and casual contributors.
• Open mailing list to announce new projects.
• A page where we explain where you can contribute and how.
• A mentorship program.
• A wiki to organize areas, projects, tasks, events, meetings and contributors.
• A mumble audio server to do audio conferencing.
• An irc channel at irc.mozilla.org.

Meritocracy

The community rules (es) are clear and accepted by everybody from the beginning. We are a meritocracy like the rest of Mozilla and we are divided on:

• Users: Anyone who visits the site.
• Casual contributors: Users that contribute to the community from time to time in different projects.
• Core contributors: A casual contributor that has been participating actively for at least 6 months could be proposed as a core contributor or member. He will have rights to vote in the internal decisions that could be made in the community. If you are going to be inactive or you stop contributing you will be again a casual contributor.
• Mentors: Special category for well know contributors that want to help newcomers to get into the community.

Mailing list

It’s hosted on google groups but in the future should be migrated to Mozilla’s mailman. Subscriptions are open, it’s the first way to introduce yourself to the community and keep updated about what’s going on. It’s also the place for discussion about new ideas or problems.

People are encouraged to send emails to the list using a tag for better organization:

• [News] Firefox 9
• [Engagement] DeMo project
• [Support] Check unsolved posts

Contribute page

The contribute page it’s the main page for newcomers. It’s designed to first point people to the mentorship program (es), ongoing-future projects listing page (es) and resources for contributors (es) and then list all areas we are working on.

Mentorship program

In the mentorship program page we briefly explain what Mozilla Hispano is and our Mozilla values (we don’t want people to misunderstand that we are a meritocracy and have problems in the future). Then we list by area, the names and emails of mentors and we encourage to mail them directly.

We’ve found that one to one contact with people is better to explain how we work and what they can do. We want mentors to be very active, assigning or creating projects to keep new people active from the beginning.

Projects page

From it you can get and overview about what’s going on now and in the future. More about this later.

Resources for contributors

This page lists every tool we use, how to sign up for the mailing list, how to create an account on our wordpress to post articles, our planet, social networks, irc, events, audio server or how to create content on the wiki.

A wiki to organize them all

Since the beginning of the project, we’ve been using the wiki as a tool to list how we work and list contributors, but the “static” approach we’ve been using was not enough once we get dozens of new contributors. Following Mozilla Reps wiki organization we improved our mediawiki installation using semantic data: Semantic Mediawiki and Semantic Mediawiki Forms. Using these tools we can have information shared between wiki pages.

Profile page

Once a new contributor creates an account on the wiki, he can fill his profile information such as name, photo, country, areas where he wants to contribute, email, website, twitter… Mozilla is about people and we want everyone to know this when they visit our page.

This is a very important page to track everyone working on the community because this page will automagically fetch all projects, events, meetings, and pending task this users has.

My profile page on the wiki

Areas

We try to mimic Mozilla’s division: News, User support, Labs, Engagement, QA and IT. This is what we like to call “A small Mozilla inside Mozilla”.

Each area has a core contributor in charge to organize it and guide people interested in contributing to the area.

Projects

Every initiative is a new project, from “Localizing AMO” to “Improve site design” or “Tips and tricks for beginners”. Anyone can create a new project from the listing page using a easy form.

Each project has a coordinator, an area where it belongs, status (inactive, active, finished), a list of people helping on it (anyone can add himself to the list), aim, subprojects (if needed), meetings (more about this later), pending tasks and free text to describe the status or any other links and information about it. Projects are listed on their area page to give them visibility.

Tasks

Any area or project can have tasks (es), a small work that has to be done assigned to a contributor. We don’t need a big infrastructure like bugzilla for these assignments.

Each task has a description, person in charge, due date and status. They are listed on their corresponding area/project page and also in the profile of the person in change of it. This last thing it’s very important because it’s a way to friendly remind people they have something to do

You can subscribe to all task, area tasks, project tasks and/or your personal tasks via RSS to keep updated.

Meetings

For organizing a project we have the possibility of creating a meeting (es). The workflow is usually this:

• The project coordinator post a message on the mailing list announcing the meeting and asking people interested and preferred dates (most times using tools like doodle.com)
• Once the date is set, a meeting page is created with all the information and attendees. It will be automatically listed on meetings page, project page and attendees profiles.
• We use a mumble server for conferencing. We’ve found that using audio instead of just text on IRC is quicker and improves the personal relationships between contributors. Every meeting is recorded, uploaded and linked on its page.
• Notes about the conference are added to the meeting page and the link is announced on the mailing list.
• We use irc as back channel for sharing links and text during the conference. Chat log is also attached to meeting page.

Events

Event tracking (es) is also done on the wiki. Every event a community contributor attends should be listed here, even if it’s not organized by a mozillian. Dates, address, organizer, number of attendees, website and mozillian attendees are filled here so it will be auto-listed in every contributor profile page.

This is a great way to know where the community contributors are going to be and have information about Mozilla presence in these events.

Final notes

This is the way that works for us, and we think it could work for other communities. Following these procedure we have:

• Improved personal relationships between contributors.
• Everyone knows what’s going on and who is doing what.
• The ideas are no longer lost in a limbo of emails.
• Newcomers know where to go and who to ask to start contributing.
• New contributors have things to do since day one and their work is visible and public for the rest of the community.

And remember, the key for community growing is to get contributors with different profiles and encourage them, let them see they and their work are part of the community! Don’t focus your community just in localization, most people want to help with engagement, creation (music, video, images) or other creative topics, most future contributors will find you in social networks, be there and keep them updated!

Our presentation at Mozcamp 2011 Europe was a 10 minutes summary of this

Question? Leave a comment, ping me on irc (Nukeador), Twitter or via email (nukeador at mozilla-hispano dot org).

As a bonus track, here you have the Mozilla Hispano talk about community organization at MozCamp Europe 2011:

Durante el último año, la comunidad de Mozilla Hispano ha crecido tanto en número de colaboradores como en número de proyectos en curso, por lo que hemos tenido que aprender a manejar desde un grupo pequeño a un grupo de más de 40 personas.

Todo suele ser más o menos fácil de manejar cuando tu comunidad tiene 4 o 5 personas, normalmente cada uno hacer una tarea distinta, enfocándose normalmente en la localización o asistencia a usuarios y para comunicarte usas el correo electrónico o una lista de correo. El problema empieza cuando la comunidad crece y la gente nueva quiere hacer cosas diferentes, tales como difusión, marketing, relaciones con la prensa, control de calidad…

English version.

Trataré de explicar como lo hemos solventado en Mozilla Hispano y espero que pueda ayudar como ejemplo a otras comunidades en el futuro.

Nuestra infraestructura se basa en:

• Meritocrácia: Colaboradores y miembros activos.
• Lista de correo abierta para anunciar los nuevos proyectos.
• Una página donde se explica dónde y cómo puedes colaborar.
• Un programa de mentores.
• Un wiki para organizar las áreas, proyectos, tareas, eventos, reuniones y colaboradores.
• Un servidor de audio mumble para hacer conferencias de audio.
• Un canal de irc en irc.mozilla.org.

Meritocrácia

Las normas de la comunidad son claras y están acordadas por todo el mundo desde un inicio. Somos una meritocrácia como el resto de Mozilla y nos subdividimos en:

• Usuarios: Cualquier que visita la web.
• Colaboradores: Usuarios que colaboran con la comunidad de vez en cuando en diferentes proyectos
• Miembros activos: Un colaborador que ha estado participando en la comunidad de forma activa desde hace al menos 6 meses puede ser propuesto como miembro activo. Tendrá derecho a votar en las decisiones internas que puedan afectar a la comunidad. Si va a estar inactivo o va a dejar de colaborar, siempre se puede volver a ser un colaborador normal.
• Mentores: categoría especial para los colaboradores veteranos que quieren ayudar a los nuevos a conocer y colaborar en la comunidad

Lista de correo

Está alojada en google groups pero en el futuro se debería migrar al mailman de Mozilla. Cualquiera puede suscribirse, en la forma principal de presentarse y estar al día de lo que está sucediendo. Es también el lugar de discusión sobre nuevas ideas o problemas.

Se recomienda enviar los correos a la lista usando una “etiqueta” para una mejora organización:

• [Noticias] Firefox 9
• [Difusión] Proyecto encantamiento
• [Asistencia] Revisar los temas sin solucionar

Página colabora

La página de colabora es la página principal de llegada para los nuevos. Está diseñada para dirigir primero al programa de mentores, lista de proyectos en curso , los recursos para colaboradores y posteriormente listar todas las áreas en las que estamos trabajando.

Programa de mentores

En la página del programa de mentores describimos de forma breve qué es Mozilla Hipano y nuestros valores Mozilla (queremos que la gente entienda que somos una meritocrácia y que no tengamos malentendidos en un futuro). Posteriormente listamos por área, los nombres y correos de los mentores a los que animamos a escribir directamente.

Nos hemos dado cuenta que el contacto directo 1 a 1 es mucho mejor para explicar cómo trabajamos y qué se puede hacer. Queremos que los mentores estén muy activos, asignando o creando proyectos para mantener a la gente nueva activa desde un inicio.

Página de proyectos

Desde ella tienes una vista general de qué se está moviendo ahora y en un futuro. Amplio esto más abajo.

Recursos para colaboradores

Esta página lista todas las herramientas que usamos, cómo darse de alta en la lista de correo, cómo crear una cuenta en nuestro wordpress para publicar artículos, nuestro planet, redes sociales, irc, eventos, servidor de audio o cómo crear contenido en el wiki.

Un wiki para organizarlos a todos

Desde el inicio del proyecto, hemos estado usando el wiki como herramienta para detallar cómo trabajamos y listar a los colaboradores, pero la manera “estática” que usábamos no era suficiente para organizar docenas de nuevos colaboradores. Siguiendo el ejemplo de organización wiki de Mozilla Reps, mejoramos nuestra instalación de mediawiki para usar datos semánticos: Semantic Mediawiki y Semantic Mediawiki Forms. Usando estas herramientas podemos compartir información entre páginas del wiki.

Página de perfil

Una vez que un colaborador crea una cuenta en el wiki, puede rellenar la información de su perfil con datos tales como nombre, foto, país, áreas en las que quiere colaborar, correo, página web, twitter… Mozilla está formado por personas, y queremos que todo el mundo lo vea cuando visite nuestra página.

Esta es una página muy importante para hacer un seguimiento de todo el mundo que está trabajando en la comunidad ya que ésta página mostrará “automágicamente” todos los proyectos, eventos, reuniones, y tareas pendientes que tenga el usuario.

Mi perfil en el wiki

Áreas

Intentamos imitar la división de Mozilla: Noticias, asistencia, Labs, difusión, control de calidad y administración técnica. Esto es lo que nos gusta llamar “Una pequeña Mozilla dentro de Mozilla”.

Cada área tiene un miembro activo a cargo para organizar y guiar a la gente interesada en colaborar en ese área.

Proyectos

Toda iniciativa es un nuevo proyecto, desde “Localización de AMO” a “Mejorar el diseño del portal” o “Consejos y trucos para principiantes”. Cualquiera puede crear un proyecto desde la página con el listado mediante un sencillo formulario.

Cada proyecto tiene un coordinador, un área a la que pertenece, estado (inactivo, en curso o finalizado), personas participando (cualquiera puede añadirse a la lista), objetivo, subproyectos (si fuera necesario), reuniones (más detalles abajo), tareas pendientes y texto libre para describir el estado o añadir enlaces e información al respecto. Los proyectos se listan en la página de su área para darles más visibilidad.

Tareas

Cualquier área o proyecto puede tener tareas, que son pequeños trabajos que se tienen que hacer asignados a un colaborador. No necesitamos una gran infraestructura como bugzilla para estas asignaciones.

Cada tarea tiene su descripción, persona a cargo, fecha límite y estado. Se listan en la página de su área/proyecto correspondiente y también en el perfil de la persona a cargo. Esto último es muy importante ya que sirve como recordatorio para que la gente sepa que tiene algo por hacer

Puedes suscribirte a todas las tareas, las de un área, proyecto y/o a tus tareas personales vía RSS para estar al día.

Reuniones

Para organizar un proyecto, tenemos la posibilidad de crear reuniones. El flujo de trabajo normalmente es así:

• El coordinador del proyecto publica un mensaje en la lista de correo anunciando la reunión y preguntando por personas interesadas y fechas (la mayoría de las veces usamos herramientas como doodle.com)
• Una vez que se ha decidido una fecha, se crea la página de la reunión con toda la información y los asistentes. Se mostrará automáticamente en la página de reuniones, en la del proyecto y en los perfiles de los asistentes.
• Usamos un servidor mumble de audio para las charlas. Hemos observado que usar audio en vez de sólo texto en IRC es más rápido y mejora las relaciones entre los colaboradores. Todas las reuniones son grabadas, subidas y enlazadas en la páginas de su reunión.
• Las notas sobre la charla se añaden a la página de la reunión y se publica un enlace en la lista de correo.
• Usamos irc como canal de apoyo para compartir enlaces y texto durante la charla. El log de irc también se adjunta a la página de la reunión.

Eventos

El seguimiento de eventos se hace también desde el wiki. Se lista cualquier evento al que asiste un colaborador, incluso si no está organizado por un mozillero. Se rellenan con fechas, lugar, organizador, número de asistentes, página web y colaboradores asistiendo para que así se liste también en los perfiles de usuario.

Es una forma genial para saber dónde están yendo los colaboradores de la comunidad y tener información sobre la presencia de Mozilla en estos eventos.

Notas finales

Esta es la forma que nos funciona a nosotros, y creemos que puede funcionar para otras comunidades. Siguiendo ésta organización hemos conseguido:

• Mejorar las relaciones personales entre colaboradores.
• Todo el mundo sabe qué está pasando y quién hace qué.
• Las ideas ya no se pierden en un limbo de correos.
• La gente nueva sabe dónde ir y a quién preguntar para empezar a participar.
• Los nuevos colaboradores tienen cosas que hacer desde el día uno y su trabajo es visible y público para el resto de la comunidad.

Y recuerda, la clave para el crecimiento de una comunidad es tener colaboradores de diferentes perfiles y motivarlos, ¡hazles ver que tanto ellos como su trabajo es parte de la comunidad! No enfoques tu comunidad sólo en localización, la mayoría de la gente quiere ayudar con difusión, creación (música, vídeo, imagen) u otros temas creativos, la mayoría de los futuros colaboradores te encontrarán a través de una red social, ¡ten presencia allí y mantén a la gente al día!

Nuestra presentación en el Mozcamp 2011 Europe fue un resumen de 10 minutos sobre todo esto

¿Preguntas? Deja un comentario, escríbeme por irc (Nukeador), Twitter o vía email (nukeador arroba mozilla-hispano punto org).

Cómo extra, os dejo la charla de Mozilla Hispano sobre organización comunitaria en el MozCamp Europe 2011:

Tiene gracia hayan tenido que pasar casi 7 años desde que empecé a colaborar en Mozilla para realizar un primer evento en donde resido, pero por una cosa u otra siempre se han hecho eventos en donde había más personas para ayudar a realizarlos (Madrid).

¿Qué es un Mozpub?

Un MozPub es un encuentro informal para charlar sobre la web abierta, software libre y cualquier tipo de tecnología o proyecto web abierto (HTML5, WebGL, webapps…).

¿De qué se habló?

A continuación os listo algunos temas que se trataron y enlaces de interés:

• Listado de cuentas de twitter que asistieron.
• Fotos en flickr (mozpubvall).
• Mozilla Hispano, áreas de colaboración.
• Proyectos en el marco de Drumbeat.
• Manifiesto de principios de Mozilla.
• El podcast de Mozilla Hispano.
• Incubador de proyectos Web FWD.
• Calendario hispano de eventos abiertos.
• Blog de Tristan Nitot sobre Mozilla y web abierta, presidente de Mozilla Europe.
• Mozilla UX: Artículos del equipo de experiencia de usuario.
• Mozilla Labs: Desarrollo de ideas.

Impresiones

Me sorprendió la buena acogida que tuvo el evento para ser el primero que organizamos en Valladolid, y la mayoría de los inscritos pudieron asistir. La gente tenía muchas ganas de conocer más, tanto sobre Mozilla como de la filosofía que hay detrás.

Pretendemos seguir realizando Mozpubs de forma periódica e incluso centrándolos en una temática diferente cada vez. Mi idea es que se puedan llegar a presentar proyectos de forma breve mientras la gente se toma unas cervezas

Seguid atentos porque ¡tenemos ganas de más!

Antes de seguir, hay que tener en cuenta un par de objetivos de Mozilla:

Objetivo 1: Al final, lo que se pretende es que la web sea una plataforma abierta, construida en base a estándares abiertos, donde todo el mundo pueda innovar y que las aplicaciones sean reutilizables. Los puntos 6 y 7 del manifiesto Mozilla. Los sistemas operativos cerrados están completamente en contra de este objetivo a largo plazo, por lo que deberíamos hacer todo lo posible por minimizar el impacto que estos sistemas operativos tienen.

Objetivo 2: Por encima de todo, queremos dar a los usuarios el control de sus vidas en la red – identidad, privacidad… etc. Punto 5 del manifiesto. Para hacer que eso ocurra debemos tener presencia en el mayor número de plataformas posibles, y hacer la experiencia del usuario tan uniforme como sea posible.

Actualmente la estrategia para iOS está basada en el objetivo 2, pero sin pensar en el objetivo 1. Mozilla desarrolla Firefox Home para iOS (iPhone e iPad) para tener presencia en la plataforma, ya que la política de Apple impide que se publiquen aplicaciones que ejecuten/interpreten código, esto es, nada de navegadores con su propio motor de javascript.

El problema radica en que Firefox Home no es un remplazo de un navegador, simplemente ofrece cierto control a los usuarios de su identidad en la red ofreciendo sus marcadores y datos. Estamos diciendo a los usuarios “usa Firefox Home  en iOS, no puedes tener Firefox pero esto también es genial” o lo que es lo mismo, estamos diciendo “usa iOS o usa Android, no nos importa cuál”. No estamos haciendo diferenciación entre una aplicación de sincronización de datos (Firefox Home) y un verdadero navegador (Firefox Mobile), no estamos diferenciando entre iOS (una plataforma cerrada) y Android (una plataforma abierta), lo cual daña al objetivo 1.

La forma de difundir Firefox hasta ahora ha sido bastante fácil, simplemente difundíamos el navegador, y boca a boca hemos llegado a más de 400 millones de usuarios. Pero actualmente el mercado ha cambiado, hay en él muchos navegadores de calidad (Chrome, Opera.. etc) y debemos diferenciarnos del resto, no somos una empresa más, somos una comunidad, debemos basarnos en nuestra filosofía abierta, en nuestros objetivos.

Dicho esto, si lo que se quiere es tener presencia en todas las plataformas posibles, y si hay recursos humanos disponibles, quizá debería hacerse una versión completa de Firefox Mobile para iOS, enviarla a la App Store, que Apple la rechace si así lo decide,y de ser así, subirla a Cydia (app store para dispositivos iOS con jailbreak). Cerca del 10% de los iPhones están jailbrokeados y Firefox puede ser una aplicación perfecta para ellos. Y lo más importante, que quede claro quién es el impide que Firefox esté disponible para sus iPhones, hacer pensar a los usuarios que la elección de una plataforma abierta es una opción mejor tanto para ellos como para su experiencia en la red.

En este caso también puede que tengas la mala suerte de usar Audacity 1.3 y no 1.2, por lo que las instrucciones de recuperación de la página de Audacity no te valgan porque la forma de nombrar los archivos no es consecutiva.

Tras investigar, la única forma de recuperarlo es:

• Ordenar los archivos por fecha.
• Renombrar basándose en la fecha de más antiguo a más nuevo con el formato b001.au b002.au
• Utilizar una herramienta para unir los trozos y generar un archivo wav.

En detalle y para una grabación en mono y usando linux:

Nos creamos una carpeta y hacemos una copia exacta del directorio con los archivos .au

mkdir recovery
cd recovery
cp -a /ruta_a_los_datos/miproyecto_data/e00/d03/ .

Ordenamos por fecha y renombramos uno a uno siguiendo el patrón:

n=1; ls -tr | while read i; do mv "$i" "b$(printf %03u $n).au"; n=$((n+1)); done

Usando la herramienta en python para la recuperación de Audacity, le decimos la carpeta en la que hemos renombrado y le dejamos que nos genere un .wav

Nota 1: Quizá necesites instalar el paquete python-wxgtk2.8 (cambia 2.8 por la última versión que haya disponible) para ejecutar la herramienta de recuperación en python.
Nota 2: Es posible que tengas que hacer el proceso con varias carpetas dentro de miproyecto_data.

Y ya estaría, hemos recuperado algo que ya creíamos perdido

A continuación resumo los pasos para instalar la última versión de los drivers y forzar la aceleración por hardware en Firefox.

Nota: La versión más actualizada de esta guía estará siempre en este artículo del wiki de Mozilla Hispano.

Nvidia

Deinstalamos cualquier versión actual de los drivers:
sudo apt-get purge nvidia*
Editamos el archivo /etc/modprobe.d/blacklist.conf y evitamos que carguen los drivers libres:
gksu gedit /etc/modprobe.d/blacklist.conf
Añadimos al final del archivo y guardamos:
blacklist amd76x_edac
blacklist vga16fb
blacklist nouveau
blacklist rivafb
blacklist nvidiafb
blacklist rivatv

Instalamos los últimos drivers disponibles en el repositorio
sudo apt-get install nvidia-glx-185

Puedes escribir sólo sudo apt-get install nvidia-glx- y dar al tabulador para que liste todos los disponibles e instalar el número más alto que veas.

Si el módulo no se ha cargado automáticamente puedes hacerlo a mano:

sudo modprobe nvidia

Genera el archivo de configuración:

sudo nvidia-xconfig

Reinicia el equipo para comprobar que todo carga correctamente.

Fuente: Ubuntuguide.net

ATI

El proceso tiene algo más de miga, pero es sencillo, podéis leerlo en este blog.

Configuración de Firefox

Escribe en la barra de direcciones about:config y acepta el mensaje de advertencia. Usando la caja de filtro busca y marca haciendo doble clic como True las siguientes opciones:

webgl.force-enabled

Quizá tengas que forzar a que Firefox no ponga tu driver en la lista negra, simplemente añade la variable a tu sesión (es posible que necesites cerrar y abrir sesión):

echo -e "#Forzar Firefox a usar aceleracion\nMOZ_GLX_IGNORE_BLACKLIST=1" >> ~/.profile

Reinicia Firefox y comprueba accediendo a about:support que en la parte inferior aparece:

Ventanas aceleradas mediante GPU 1/1 OpenGL

Fuente: Mozilla Wiki

Lo primero que hicimos fue desarrollar una web para que la gente se pudiera inscribir. La mayoría de la gente se inscribió porque vio a otras compartirlo en Twitter o Facebook. Además diferenciamos los registros de la gente de prensa y los de la gente que quería ser voluntaria en el evento y ayudarnos a montarlo todo. El código de la aplicación está en nuestro repositorio hg.

El evento tuvo lugar en el hotel Hotel Tryp Ambassador de Madrid y se acercaron unas 200 personas.

La acreditación para el evento fue la nota graciosa del mismo, ya que consistía en un diskette de 3,5 que tenía dentro una web con el viejo estilo de geocities, la cual se podía visualizar mediante un ordenador que montamos en la sala. Lo gracioso es que la página tenía oculto un “huevo de pascua” para aquellos geeks que miraran el código de la misma

La música que usamos fue sacada toda de Jamendo con licencias libres Creative Commons. Usamos grupos españoles y los citamos explicando a la audiencia que la música era libre y que podían descargarla también ellos en casa.

La charla principal fue realizada usando una web en HTML5 (no powerpoint como algunos dijeron )gracias al framework para presentaciones de Kaze, puede verse online o descargarse en un zip.

Posteriormente servimos unas pizzas y bebidas mientras sorteábamos material Mozilla (camisetas, posters, bolsas…). Dimos unas cuantas camisetas a aquellas personas que salían a comprometerse a colaborar con Mozilla Hispano este año o explicaban qué era lo que más les gustaba de Firefox 4.

El evento fue genial y pudimos hablar con mucha gente diferente, puedes ver los vídeos y las fotos en flick del mismo.

Gracias a todos los miembros, colaboradores y voluntarios de Mozilla Hispano por hacerlo posible.

Os detallo algunas consideraciones para tener bien instalado Ubuntu en un MacBook Pro compartiendo espacio con OSX:

• Seguir la guía oficial de Ubuntu para instalaciones en un Macbook.
• Aplicar las optimizaciones pertinentes (en mi caso MBP 6.2 y Ubuntu 10.10)

Además he aplicado algunas cosas a mayores para hacerlo todo más fácil.

Particiones y carpetas

El tamaño de la partición para Ubuntu que cree fue de 20 Gb.

Para montar automáticamente el disco de OSX, crear la carpeta /media/osx y añadir en el /etc/fstab

/dev/sda2   /media/osx  hfsplus  rw,user,auto,uid=501,gid=20    0  0

Además, para poder escribir con el usuario por defecto de Ubuntu hay que:

• Desde OSX desactivar el journaling del disco principal: sudo diskutil disableJournal /dev/disk0s2
• Seguir estos pasos para cambiar el uid y guid del usuario de Ubuntu.

En el home del usuario de Ubuntu borrar todas las carpetas y crear enlaces a las carpetas en el disco de osx (sustituir nuke por tu usuario):

ln -s /media/osx/Users/nuke/Downloads/ Descargas

ln -s /media/osx/Users/nuke/Documents/ Documentos

ln -s /media/osx/Users/nuke/Pictures/ Imágenes

ln -s /media/osx/Users/nuke/Music/ Música

ln -s /media/osx/Users/nuke/Web/ Web

ln -s /media/osx/Users/nuke/Movies/ Videos

ln -s /media/osx/Users/nuke/.fonts/ .fonts

ln -s /media/osx/Users/nuke/Library/Application\ Support/Firefox/ .mozilla/firefox

ln -s /media/osx/Users/nuke/Library/Thunderbird/ .thunderbird

(Podemos ampliar la lista a todas las carpetas que nos interesen)

Ventiladores

Para que los ventiladores no hagan ruido y se comporten más o menos como en OSX, estos son los valores para mi /etc/macfanctl.conf

# Config file for macfanctl daemon
#
# Note: 0 < temp_X_floor < temp_X_ceiling
# 0 < fan_min < 6200

fan_min: 2000

temp_avg_floor: 55 #45
temp_avg_ceiling: 65 #55

temp_TC0P_floor: 55 #50
temp_TC0P_ceiling: 65 #58

temp_TG0P_floor: 55 #50
temp_TG0P_ceiling: 65 #58

# log_level values:
# 0: Startup / Exit logging only
# 1: Basic temp / fan logging
# 2: Log all sensors

log_level: 0

Resumen

Con estos sencillos pasos, tanto Ubuntu como OSX usarán las mismas carpetas para guardar y trabajar con archivos e incluso podremos tener las configuraciones de algunos programas (Firefox y Thunderbird) iguales en ambos sistemas.

Firefox 4 beta

Las versiones de prueba (beta) de Firefox 4 han ido apareciendo durante estos meses, y hemos seguido la campaña “Equipo beta” para involucrar al mayor número de personas en las pruebas.

Además del sistema de envío de opinión input.mozilla.org al que llegan los comentarios que los usuarios envían directamente desde el botón de “Opinión” en el navegador, hemos habilitado unos foros en Mozilla Hispano para que la gente pueda debatir sobre estas versiones beta.

Mozilla Summit 2010

En julio estuvimos en Canadá asistiendo al encuentro mundial de Mozilla, más información en el artículo que escribí sobre ello.

Firefox Input

Mozilla habilitó un portal para las opiniones de las betas de Firefox 4, el cual se ha localizado al español como parte de la campaña.

Firefox Home

Aunque directamente no he participado en la traducción, hay que destacar el buen trabajo que se ha hecho para tener esta aplicación para iPhone en español, además de otros muchos idiomas.

Mozilla Hispano y grupos locales

Durante estos meses se ha estado preparando una página recopilando todos los grupos locales de la comunidad en español y se ha trabajado en un banner para colocar en todos los portales locales que sirva como seña de identidad común.

Además se ha creado un listado de todas las personas que actualmente están colaborando para tener una mejor visión de quiénes somos y en qué estamos interesados. De este modo los coordinadores de cada área podrán saber con cuanta gente cuentan.

Difusión y marketing en español

Se está trabajando duramente en una nueva sección de Mozilla Hispano dedicada a la difusión, marketing y eventos en español. La idea es poder coordinar a todos los países con las campañas de marketing en inglés, tener un área que sea el spreadfirefox en español y compartir el trabajo de todos ofreciendo material para realizar eventos o promocionar los productos de Mozilla.

Pronto tendremos novedades al respecto ya que el día 19 de setiembre tuvo lugar la primera reunión organizativa de los interesados de este área y hay muchas ideas y ganas por sacarlo adelante.

A raíz de este artículo en el blog de Mark Shuttleworth, me gustaría hacer un resumen y reflexión en español.

El tribalismo se define como un grupo de personas que empieza a pensar que otro grupo está equivocado de forma predeterminada, algo en lo que también se basa el racismo y el sexismo. Pero la forma más peligrosa de tribalismo es normalmente invisible y no tiene que ver con dónde nació una persona, si no dónde trabaja, cual es su equipo favorito o qué navegador usa.

Algunos de los argumentos “tribales” más repetidos son:

1. “Los demás nunca han hecho nada de utilidad”. Siendo realistas, todo el mundo se levanta por la mañana y trabaja en sus proyectos y metas, no hay ningún grupo dónde puedas decir que nadie ha hecho nada útil. Es como decir “Todos los franceses son [tu perjuicio aquí]“, es ofensivo y objetivamente falso.
2. “Cualquier afirmación contraría a mis opiniones no cuenta”. Excluyendo el trabajo de alguien por el simple hecho de que pienses que no tiene valor.

El tribalismo te hace estúpido. Tanto como el no contratar a alguien inteligente y cualificado por el simple hecho de que tiene el pelo azul o no comentar el gran trabajo de alguien simplemente por estar asociado a otra tribu.

Lo malo de ser un fanboy de un proyecto es que estás abiertamente declarando tu afiliación a una tribu y que vas a rechazar el trabajo de otras personas porque pertenecen a otra.

Evidentemente, hasta en las mejores casas se dan estos problemas de tribalismo. Las hay en Mozilla dado que es una comunidad numerosa, pero tenemos que intentar evitarlas empezando por los que colaboramos más activamente con el proyecto, para dar ejemplo a muchos usuarios que se consideran fans incondicionales de Firefox o Thunderbird y que se alimentan de guerras contra otros que lo son de otros navegadores o clientes de correo.

El objetivo de Mozilla es promover la apertura e innovación en la web abierta, y tenemos que hacer entender que sus productos son un medio y no un fin, por lo que no tiene sentido criticar los avances o trabajo de otras personas en otros proyectos que ayudan a alcanzar a sus usuarios el mismo fin, así como no tiene sentido que lo hagan ellos con Mozilla.

Las guerras de opinión (o flamewars) no ayudan a nadie, sobre todo cuando estás colaborando con un proyecto de software libre. Si colaboras en uno de ellos es porque crees que estás haciendo algo bueno y que va a beneficiar a mucha gente, no lo estás para criticar el trabajo de otras personas que hacen exactamente lo mismo que tú pero de otra manera.

Y a los usuarios se aplica exactamente lo mismo, no por usar un navegador determinado debes despreciar al resto o no opinar favorablemente cuando hacen algo bueno, sobre todo cuando son cosas que benefician a la web y en definitiva que nos benefician a todos.