Capítulo 6: Trabajar en comunidad

Ya está todo listo para liberar el código de tu trabajo y ahora quieres involucrar a la comunidad. ¡Fantástico! Contar con una comunidad fuerte de usuarios y colaboradores en proyectos de código abierto o datos abiertos es una gran ventaja, así que es fundamental invertir tiempo y esfuerzos en correr la voz sobre lo que estás haciendo para atraer la atención de posibles usuarios y colaboradores.

Puede que, a pesar de tus impresionantes esfuerzos —que sin duda lo son—, que a pesar de haber dado todos los pasos correctos para crear instrucciones claras y facilitarles la vida a los colaboradores, que a pesar de haber seguido esta guía al pie de la letra, tu proyecto no le interese a los demás.

Al menos no de entrada.

Es difícil no tomarse algo así a pecho, pero mientras te guste tu trabajo y uses tu programa no hay ningún problema. Nos pasa a todos; te lo aseguramos.

Este capítulo explica cómo construir y manejar una comunidad, incluyendo cómo establecer expectativas claras de conducta y administración, directrices y procesos para fomentar la participación, cómo expandir y administrar tu comunidad, y cómo manejar la asistencia técnica y la recepción pública del proyecto.

Establecimiento de expectativas

En el capítulo 1 mencionamos que es esencial fijar expectativas internas lo más temprano posible en el proceso de planificación. Pero a medida que el proyecto avanza y se abre a un público o comunidad más allá de quienes participaron en su creación inicial, fijar expectativas continúa siendo una tarea fundamental, aunque diferente. Los desarrolladores y los miembros del equipo editorial deben discutir qué expectativas comunicar. Algunas preguntas claves a hacer (a los demás y a ti mismo(a) son:

  • ¿Cuáles son tus metas? ¿Quieres que otras personas usen tu proyecto? ¿Que colaboren escribiendo código? ¿Quieres informar a la comunidad o a quienes te financian? ¿Promover la marca de tu organización?

  • ¿Quién quieres que colabore? ¿Cómo vas a construir y mantener relaciones con los colaboradores?

  • ¿Qué tipos de contribuciones estás abierto(a) a aceptar? ¿Cuánto control quieres retener sobre el proyecto?

  • ¿Cuánto esfuerzo estás dispuesto(a)/eres capaz de invertir en todo esto (tú o tu equipo)?

  • ¿Qué nivel de participación directa se necesita de la comunidad? ¿Van a usar y a acceder a los datos o al proyecto solamente? ¿o hace falta su participación directa para añadir datos/actualizaciones/moderar el proyecto? Si es esto último, hará falta más participación para que el proyecto funcione en este punto.

  • ¿Cuánto control retendrán los organizadores originales? ¿Cuánto tiempo/recursos exigirá ese nivel de control?

  • ¿Qué expectativas hay con respecto a la asistencia técnica sobre la marcha? ¿Cuán rápido puedes responder a problemas y sugerencias de nuevas características?

  • ¿Cuánto debemos informar sobre la filosofía de programación del proyecto? Por ejemplo, si se prefieren principios pythónicos o o formas específicas de construir en D3.

  • ¿Qué aspecto tiene el cronograma de trabajo del proyecto, y qué papel juega la comunidad en él? ¿Ese nivel de participación cambiará con el tiempo? (Consulta el capítulo 8)

Más cosas a considerar de antemano

En el capítulo 5 explicamos las mejores prácticas para documentar tu código. Aquí hemos reunido otros elementos a considerar a la hora de preparar el trabajo de la comunidad.

Trabajar con otras organizaciones/asociaciones

¿El proyecto involucra a varias organizaciones? ¿Es una asociación u otro tipo de colaboración? Aunque esto puede traer algunos retos logísticos y de comunicación al inicio (ver capítulo 1) lo cierto es que resulta útil y facilita las cosas, porque cada organización suele tener su propia comunidad, red o base de usuarios a quienes apelar.

Indaga con tus socios y asegúrate de que todo el mundo esté de acuerdo. Este también es el momento para pensar en invitar a otros posibles socios a unirse. Abre esas líneas de comunicación y aclara las estrategias para llegar a quienes necesites llegar.

Códigos de conducta

Tener un código de conducta para colaboradores desde el principio mostrará tu posición firme contra del acoso, evitará futuras discusiones sobre qué constituye acoso y qué no, y ayudará a frenar rápidamente cualquier comportamiento inapropiado. Aquí puedes encontrar más información sobre la importancia de tener un código de conducta y las formas de adoptar uno que funcione:

Para más ejemplos de códigos de conducta para colaboradores, consulta el Pacto del colaborador o los ejemplos que aparecen aquí.

Supervisión

Como advierte Christie Koehler (Authentic Engine), nunca es fácil pensar en la supervisión. (El Pacto del colaborador es un punto de partida popular.) Si estás bajo el ala de una organización de software sin fines de lucro, como NumFOCUS, eso ayudará a tomar e implementar estas opciones.

Comunicación

¿Hay un correo o método central de comunicación? ¿Quién está a cargo de moderarlo? ¿Quién está siguiendo el hashtag (si hubiera uno) en Twitter? He aquí un ejemplo de cómo pudiera verse esto. Está además Gitter, un cliente de chat diseñado específicamente para proyectos.

También es bueno aclarar quién está del otro lado de la línea cuando alguien de la comunidad se pone en contacto. ¿Son los creadores originales del repositorio? ¿O los colaboradores cuyos nombres aparecen en ReadtheDocs? Si aquellos han abandonado el proyecto/organización y ahora hay gente nueva encargada del mantenimiento, aclara quiénes son.

Recaudación de fondos

Recaudar fondos, especialmente si un proyecto atrae mucho el interés de la comunidad, es otro aspecto particular importante, en especial para organizaciones sin fines de lucro. Aunque el financiamiento es importante en las etapas descritas en el capítulo 1, es importante recordarles a quienes aprecian los proyectos de código abierto que estas organizaciones y esfuerzos pueden necesitar financiamiento en el futuro (para expandir el proyecto si termina necesitando más recursos que los que se pensó originalmente, por ejemplo).

Aceptar la colaboración de desarrolladores

¿Por qué?

En pocas palabras, aceptar colaboraciones de código abierto te permite beneficiarte de la experiencia de otras personas. También puede ayudarte a mejorar más rápido que lo que podrías hacerlo por tu cuenta, traer expertos externos y construir una red de apoyo para garantizar que tu proyecto siga existiendo incluso cuando ya no puedas mantenerlo personalmente.

Los colaboradores pueden ayudarte a revisar el código, arreglar errores, crear nuevas funcionalidades y mejorar el proyecto en general, pero también pueden ayudarte a detectar puntos ciegos. Los aportes de gente con perspectivas diferentes pueden contriubir a ampliar tus horizontes, a identificar cosas que simplemente pasaste por alto, y mucho más.

También hay cierto valor en el hecho mismo de construir algo públicamente. Cuando promovemos la transparencia, fomentamos la participación de la comunidad, desmitificamos nuestro trabajo, y mejoramos la confianza en el periodismo. Todas estas cosas hacen que el proceso periodístico sea menos misterioso, y con el tiempo podrían ayudar a fomentar (o a restituir) la confianza en nuestras organizaciones.

¿Qué tipos de colaboración vas a aceptar?

Como desarrollador, al liberar tu trabajo puede que tengas en mente que la gente ayude a mejorarlo, a incorporar nuevas funciones, o a tachar elementos de tu lista de cosas por hacer. Pero hay muchas más formas de colaborar. Cuando estés preparándote para liberar tu proyecto, querrás pensar en todo tipo de colaboraciones, y asegurarte de comunicar esas necesidades claramente (por ejemplo, consulta estas directrices del INN para colaboradores).

En general, y especialmente en un punto donde estás comenzando a construir una comunidad alrededor de tu proyecto, ningún aporte es insignificante. Incluso reportar errores y sugerir posibles características es una buena forma de participar. A partir de ahí, algunas personas pueden animarse a ayudar con otras tareas, como revisión o control de calidad, que son maneras menos intimidante de contribuir a una base de código.

Algunos proyectos etiquetan problemas que son buenas tareas iniciales para alguien que desee ayudar. Por ejemplo, React tiene una etiqueta denominada "buen primer problema".

No olvides que la gente sin perfil técnico también va a querer ayudar, así que piensa en formas de darles opciones para que participen. A continuación otros elementos adicionales a considerar:

  • Expandir o mejorar la documentación. Siempre es útil que personas no familiarizadas con tu proyecto traten de seguir las instrucciones que has escrito y que te avisen de problemas cuando encuentren obstáculos. También puede ser que necesites ayuda con la redacción o edición de la documentación, y ese siempre es un buen punto de partida para colaboradores menos técnicos.

  • Añadir ayuda en otros idiomas. En dependencia del tipo de proyecto, puede que quieras ponerlo en otros idiomas para otros colaboradores y usuarios. Esto va más allá de sencillamente traducir tu documentación. Puede que sea necesario traducir los elementos de la interfaz de usuario, la documentación incluida en el código y otros contenidos del proyecto.

  • Crear y promocionar la comunidad. Construir y mantener la comunidad, administrar los tickets y las solicitudes de funcionalidades, promover el proyecto e invitar a los demás a usarlo, y otros detalles que intervienen en la administración de un proyecto de código abierto son todas áreas excelentes para que los colaboradores con menos habilidades técnicas participen. Es posible que necesites preparar algunas directrices, tutoriales y documentación para que los voluntarios puedan realizar estas tareas, pero puedes aligerar tu carga de trabajo dándoles libertad a algunos miembros para que se encarguen de incrementar y gestionar la comunidad ellos mismos.

  • Priorizar tipos de problemas. Los proyectos más populares suelen verse inundados de notificaciones de problemas que no es posible resolver. Por ejemplo, puede que alguien informe haber tenido un problema relacionado con un programa de terceros que esté usando, o simplemente envíe una queja no constructiva. También puede suceder que el informe de un problema sea demasiado vago como para resolverlo sin pedir más información. Alguien de perfil no técnico puede ayudar a ordenar los elementos de acuerdo con su prioridad, etiquetándolos, respondiendo o cerrándolos.

[TAREA: más ideas para colaboradores no técnicos]

Lo más importante es facilitar al máximo la participación de la gente para que puedan hacer sus primeros aportes, sea cual sea la ayuda que puedan dar.

Informes de errores

Incluso cuando lo único que esperas de la comunidad es ayuda detectando errores, querrás asegurarte de que quede claro cuál es tu vía de comunicación preferencial, cómo enviar informes de errores y qué debería contener un buen informe. Puedes incluir un grupo de directrices o un ejemplo para que quede más claro.

Ejemplos de guías para informes de errores:

Si estás usando Github, puedes incluir tu plantilla de informe de errores en el repositorio en un archivo que se llame ISSUE_TEMPLATE.md que se llenará automáticamente para los usuarios que informen de un problema nuevo.

Ejemplos de plantillas de problemas:

En dependencia del tamaño y alcance de tu proyecto, es posible que quieras gestionar los informes de errores y otras colaboraciones voluntarias un poco diferente.

En proyectos más pequeños, podrías decidir recibir los informes de errores en tu correo electrónico, pero en proyectos grandes (o si manejas muchos proyectos) es buena idea usar una dirección de correo específica para eso, o incluso implementar un sistema de seguimiento de errores para gestionar el volumen de solicitudes que recibes.

[TAREA: añadir recomendaciones de sistemas de rastreo de errores y sugerencias para proyectos/equipos de diferentes tamaños, etc.]

Para proyectos muy grandes, puede que necesites una persona dedicada específicamente a dar asistencia técnica o a gestionar la comunidad.

Sean cuales sean las herramientas que elijas usar, si esperas que la gente se encargue de las tareas y/o los mejoramientos que has publicado, asegúrate de compartir tu hoja de ruta en un lugar público y exponer claramente los problemas con instrucciones suficientes para que alguien que acaba de sumarse pueda trabajar armónicamente en el proceso de tu equipo. También puedes incluir banderas (como las etiquetas de Github) para elementos como "Se busca ayuda" ("help wanted" en inglés) o "Bueno para principiantes" para darles a los miembros de la comunidad una idea de dónde hacer su aporte.

En este artículo de Sumana Harihareswara puedes leer más recomendaciones generales.

Promover tu proyecto de código abierto

Entonces, ¿cómo promueves tu proyecto para que la gente pueda colaborar? Los proyectos de código abierto triunfan cuando tienen vínculos fuertes con la comunidad que los apoya y cuentan con su respaldo. Esto es incluso más relevante con proyectos de código abierto en periodismo, que suelen lidiar con problemas que afectan a la comunidad, desde vecindarios hasta ciudades o países enteros.

Muchos medios de prensa ya tienen vínculos con su comunidad, y como empresas mediáticas, suelen tener a su disposición varias vías de comunicación. Al planear el lanzamiento inicial, vale la pena pensar en cuáles de esos canales pueden funcionar para anunciar y promover un proyecto en particular. ¿La audiencia de tu contenido editorial incluye diseñadores, desarrolladores y otros posibles colaboradores? ¿Pueden ayudarte a establecer vínculos con otros miembros de tu comunidad técnica local o ayudarte a correr la voz sobre tus proyectos? ¿Hay listas de correos para desarrolladores de los medios (ej. NICAR-L-SPA), conferencias (ej. SRCCON, Mozfest, NICAR), canales de Slack (News Nerdery, Lonely Coder, etc.), o meetups (ej. Hacks/Hackers) que podrían querer enterarse de tu proyecto?

Aunque estos pueden ser buenos lugares para comenzar a promover tu trabajo, también querrás ser proactivo(a) y buscar comunidades de posibles usuarios y contribuidores con buenas probabilidades de tener interés en tu proyecto. Piensa en el público más amplio de la aplicación:

  • ¿Hay medios de prensa parecidos que podrían beneficiarse de tu trabajo?

  • ¿Hay una comunidad del lenguaje que estás usando que podría interesarse en cómo lo estás usando? (Algunos lenguajes tienen comunidades más activas que otros).

  • ¿Tu herramienta puede satisfacer necesidades más allá de los límites de la redacción? (Por ejemplo, una herramienta que ayude a limpiar y a interconectar datos sería útil para los desarrolladores en un medio de prensa, pero también podría servirle a la comunidad general de visualizadores de datos y científicos de datos.)

  • ¿Qué grupos esperas que usen/contribuyan al proyecto?

  • ¿Cuáles son las mejores formas de llegar a ellos? (Twitter, Github, Facebook, reuniones directas con los líderes de la comunidad).

Si no has hecho contacto con estas organizaciones, es una buena oportunidad para presentarse e idealmente comenzar una relación duradera en la que podrán compartir y aprender los unos de los otros en los años que siguen.

Aunque puede usarse un enfoque amplio y plataformas técnicas, no olvides conectarte directamente con posibles miembros de la comunidad a la que quieres apelar. Sus opiniones serán clave para desarrollar un enfoque que se adapte a la realidad. Toma en consideración las divisiones sociales que podrían presentarse, incluyendo clase, raza, sexo e idioma. Asegúrate de no ahuyentar a posibles colaboradores sin darte cuenta.

Y por supuesto, una forma excelente de atraer el interés y el apoyo de la comunidad es colaborar tu mismo(a) en proyectos de otras personas. Tener un historial de colaboración en la comunidad incrementará las posibilidades de que los demás quieran ayudarte.

De hecho, para conectarse con comunidades de todo tipo, he aquí algo muy importante a tener en cuenta: las relaciones se construyen con el tiempo, así que empieza a trabajar antes de que te haga falta.

Mantener la calidad del código

[TAREA: información sobre cómo decir que "no" amablemente, rechazar las relaciones públicas, etc. sin ahuyentar a colaboradores bienintencionados]

Créditos de colaboración

Los proyectos de código abierto suelen ser el producto de la colaboración de muchas personas, que normalmente trabajan voluntariamente donando su tiempo libre. Es importante reconocer sus aportes y hacerles sentir que son miembros valiosos de tu comunidad. Puede que la gente quiera ser reconocida de diferentes formas (o no ser reconocida en absoluto), así que asegúrate de preguntarles qué prefieren. He aquí algunas ideas para reconocer a tus colaboradores:

  • Da las gracias (públicamente y/o en privado)

  • Añade una etiqueta en Github a los aportes hechos por la comunidad

  • Menciona a las personas que han colaborado con cada versión en las notas del lanzamiento

  • Envíales pegatinas u otras misceláneas

  • Valora darles más responsabilidad/derechos/opiniones a los colaboradores habituales

  • Ofrece escribirles cartas de recomendación para sus empleos/solicitudes de beca

  • Averigua si alguien que conozcas puede estar interesado en contratarles

  • Aquí algunos recursos para premiar a los colaboradores:

    Ayuda a citar tu código asignándole un DOI

    Crear un archivo humanos.txt para reconocer las colaboraciones

Encuentros cara a cara

Si tu proyecto incluye colaboradores (asalariados y voluntarios) de diferentes ciudades, deberías valorar reunirte con ellos en persona unas cuantas veces al año. He aquí por qué y cómo hacer que esos encuentros sean productivos.

Aceptar colaboraciones editoriales

En los proyectos editoriales suele haber otras formas de involucrar a la comunidad. En esos casos, es importante concentrarse en qué ganarán directamente quienes participen. ¿Qué aspectos de su comunidad van a revelarse? ¿Qué problema se solucionará o paliará? ¿Qué información podrán recabar?

Al hacer esto es esencial recordar que las comunidades, especialmente las que cuentan con servicios de medios de prensa, tienen más de una forma de comunicarse. Evalúa varios métodos de comunicación y reduce tus opciones, pero no las reduzcas demasiado porque un proyecto con potencial para resultar atractivo podría no despegar por falta de promoción.

Si el proyecto necesita de la participación de una parte de la comunidad (digamos, un vecindario o trabajadores de una industria dada), reunirse en persona con ellos o con sus miembros principales es esencial de una forma que a veces no es el caso con comunidades predominantemente virtuales. Saber qué tipos de canales, especialmente qué redes sociales, prefieren estos grupos y las mejores formas de contactarlos ayudará en ambos casos.

Estudio de caso: Durante varias décadas, Burton Street (un barrio predominantemente negro en Ashville) ha estado bajo amenaza de ser devastado por un proyecto de carretera interestatal. En 2009, un periódico local trabajó con una organización local de fotógrafos y miembros de la comunidad para recolectar fotos de lugares vinculados a sus vidas y les proporcionó vías para enviar sus historias e información sobre los hogares que se perderían y los efectos de las demoliciones. El objetivo era crear un mapa en línea y un proyecto fotográfico que fuera fácilmente navegable y explorable (y abierto a nuevos aportes de información después de hacerse público). Esto se combinó luego con video y con una serie de artículos sobre la historia y el futuro probable del vecindario. Como les dio a los vecinos una oportunidad de contar directamente sus historias después de décadas de ser ignorados por el gobierno de la ciudad, la mayoría participó o hizo algún tipo de aporte y el proyecto recibió un amplio apoyo de la comunidad, lo cual a su vez ayudó a llamar la atención más allá de los límites de la audiencia predominantemente blanca del periódico.

Poco después de la publicación del proyecto y de la presión pública que siguió, el Departamento de Transporte se comprometió a reducir drásticamente la cantidad que casas que iban a ser demolidas en Burton Street, y el tema ha pasado a ser mucho más importante en los debates y decisiones políticas locales desde entonces, lo cual además ha contribuido a crear más conciencia sobre la segregación que de hecho existe en el área. Esto también le ganó a la Asociación Comunitaria de Burton Street el reconocimiento del gobierno local y financiamiento para poder desarrollar su propio plan de desarrollo futuro para su comunidad. El proyecto ganó algunos premios multimedia a nivel estatal y nacional.

Para saber más sobre cómo se realizó la coordinación de los diferentes grupos en este esfuerzo común, consulta el capítulo 1. Para conocer más sobre los problemas que tuvo que enfrentar a la larga por falta de un plan de desactivación, consulta el capítulo 8.

Verificación

Un aspecto particularmente único de algunos proyectos de código abierto es la necesidad de verificación. Si los colaboradores están enviando datos o información que necesitan ser verificados por razones legales y éticas, los desarrolladores y el equipo editorial deberán trabajar estrechamente en un proceso claro y coherente que garantice la validez de la información, sin dejar de proteger la identidad de la fuente en caso de que desee permanecer anónima. [TAREA: ejemplos de verificación]

Lidiar con el lado oscuro de la comunidad

También queremos mencionar que, como en toda comunidad, va a haber gente cuyo comportamiento no será el mejor.

Hacer cumplir el código de conducta

Al principio de este capítulo, hablamos de llegar a un acuerdo sobre un código de conducta. A continuación más información al respecto. En primer lugar, ¿por qué tener uno? Es común asumir que, simplemente por que uno mismo(a) no ha experimentado acoso en internet, o porque tu proyecto no tiene ningún contenido hostil, no es necesario tener un código de conducta (o que puedes esperar a que pase algo para adoptar uno). Pero para ayudar a garantizar la seguridad, armonía y apertura de tu comunidad a gente de las procedencias más diversas, querrás tener un reglamento que establezca qué comportamientos se consideran inadecuados y qué hará el equipo del proyecto al respecto.

Dicho esto, tener un código de conducta no será suficiente: también necesitarás a alguien que lo haga cumplir. Cuando estés escribiendo o adoptando un código de conducta, piensa en cómo vas a encargarte de las siguientes cuestiones desde el punto de vista práctico y logístico, tomadas de Ada Initiative):

  • Especificar qué comportamientos o tipos de comportamientos son inaceptables

  • Dar instrucciones detalladas para que la gente reporte violaciones del Código de conducta

  • Diseñar un proceso detallado y bien documentado para lidiar con las quejas, designando encargados que se ocupen de los informes, de investigar si lo sucedido constituye una violación del código, y de implementar cualquier sanción o medida (desde advertencias escritas hasta expulsiones permanentes)

Lidiar con oposiciones

A veces algunas instituciones o intereses pueden oponerse a un proyecto de código abierto por la información que va a revelar y por creer que sus intereses políticos se verán afectados. Es importante que todos los involucrados en el proyecto coordinen de antemano y estén al tanto del contexto político de una comunidad dada, de manera tal que puedan tomar una posición resuelta y coordinada. Esto permitirá a los involucrados, especialmente en el lado editorial, anticiparse a lo que pasará cuando el proyecto se haga público, para que todas las organizaciones involucradas puedan estar listas para responder con argumentos. Particularmente en el período inmediato al lanzamiento del proyecto en público, esto puede ayudar a modelar la percepción a favor del proyecto y servir para fomentar la participación de la comunidad.

Estudio de caso: Registros publicados recientemente sobre el programa 1035 del gobierno federal de EE.UU. que suministra a los departamentos de policía equipos y armas sobrantes del ejército, revelaron que el jefe de la policía de un pueblito de Carolina del Norte con un departamento de siete empleados había recibido una gran cantidad de armamento, incluyendo un lanzagranadas. La información fue resaltada por un periódico local, y el jefe de la policía, nada feliz con la revelación, acusó a la prensa por todo lo alto de inmiscuirse en asuntos de orden público. El periódico rápidamente defendió el uso de esos registros públicos como un elemento esencial para proteger el derecho de la ciudadanía a esa información, lo cual le ganó más apoyo de los lectores para seguir hurgando en los registros.

Estudio de caso: Una coalición local de medios de prensa estaba preparando un proyecto donde los trabajadores locales, previa verificación, proporcionarían información sobre sus salarios reales de forma anónima. Un grupo de presión que representaba a dueños de restaurantes atacó al proyecto por considerar que afectaba a los negocios locales. Los medios de la comunidad habían previsto esa reacción y ya tenían preparada una declaración asegurando que el proyecto era necesario para combatir el estigma alrededor de temas como salarios y compensaciones, especialmente en las profesiones peor pagadas, y quizás también revelar problemas de discrepancias o discriminación en los pagos. En el texto también destacaron que los trabajadores tenían el derecho legal a hablar públicamente de sus salarios y condiciones.

Spam

¿Cómo lidiar con problemas/tickets no deseados? [TAREA: ejemplos de organizaciones que han liberado sus proyectos editoriales y han tenido que lidiar con problemas de spam]

Asistencia técnica

  • [TAREA: más información sobre asistencia técnica aquí]

  • Gestionar la asistencia técnica

  • Pagada vs. gratis

  • Descanso + cómo lidiar con el agotamiento

Estudio de caso: Después de coordinar con servicios electorales, con medios de prensa y desarrolladores locales, el proyecto Programa para Asheville acordó una reunión para trabajar juntos en una herramienta para las elecciones de 2016, específicamente para las campañas estatales y locales menos conocidas, que sin embargo pueden tener un impacto grande en la vida de la comunidad y pueden ser muy competitivas (en una de ellas la votación tuvo un margen de 300 votos). Todas las partes habían comunicado de antemano lo que planeaban hacer, pero querían debatirlo más en una reunión para verificar que todos estuvieran en sintonía. Para que los lectores pudieran tomar sus propias decisiones, la gente de la prensa y algunos activistas escribieron reseñas de las oficinas locales y estatales que no estaban regodeándose en la jerga legal, sino que estaban explicando la importancia de las posiciones, y recomendaron otros vínculos para "Leer más" en medios locales y estatales que habían cubierto estos problemas ampliamente. Rápidamente los servicios electorales proporcionaron acceso a datos clave y a las herramientas que habían desarrollado. El proyecto se encargó de la programación. El resultado fue una herramienta electoral que tuvo una amplia distribución local, en parte gracias a la cooperación de los medios y los servicios electorales locales. Aunque en toda elección influyen muchos factores, Buncombe terminó teniendo una asistencia a las urnas mucho mayor que el promedio del estado.

Puntos a verificar

  • [ ] Ten un código de conducta
  • [ ] Discute quién se encargará de hacer cumplir el código de conducta y cómo lo hará
  • [ ] Comparte el manual de estilo del proyecto si tienes uno
  • [ ] Trabaja con los editores para desarrollar un proceso de verificación, si fuera necesario
  • [ ] Ten canales de comunicación (canal IRC, Slack, listas de correo, rastreador de problemas, etc.) y promuévelos
  • [ ] Escribe un documento para colaboradores (ej. CONTRIBUTING.md)
  • [ ] Asegúrate de que los miembros de tu comunidad sepan cómo contactarte, cómo enviar informes de errores, y qué deben incluir en un buen informe de errores.
  • [ ] Incluye a los colaboradores en los créditos