LogoLogo
Contribute to InnerSource PatternsJoin the community
🇪🇸 Español
🇪🇸 Español
  • Introducción
  • Tabla de Contenidos
  • Explorar Patrones
  • Contribuir a este libro
  • Patrones
    • Casos de uso del Gestor de Tareas (Issue Tracker)
    • Colaborador Contratado
    • Comenzar como Experimento
    • Comité de Revisión
    • Documenta tus Principios Rectores
    • Documentación Base Estándar
    • Equipo Central (Core Team)
    • Extensiones para un Crecimiento Sostenible
    • Garantía de 30 Días
    • Grupo de Soporte
    • Herramientas de Comunicación
    • Licencia InnerSource
    • Líder de Comunidad Dedicado
    • Mercado de Gigs
    • Modelo de Madurez
    • Portal InnerSource
    • Proceso Estándar de Publicación
    • Puntuación de Actividad del Repositorio
    • Reconocimiento a los Participantes
    • Requerimientos Comunes
    • Servicio vs Librería
    • Toma de Decisiones Transparente Entre Equipos usando RFCs
    • Trusted Committer
    • Valoración de Proyectos Transversales
  • Apéndice
    • Plantilla de Patrones
    • Glosario
    • Extras
      • Plantilla de README
      • Plantilla de CONTRIBUTING
      • Plantilla de COMMUNICATION
      • Plantilla de RFC
  • Recursos
    • Este libro en GitHub
    • InnerSource Commons
Con tecnología de GitBook
En esta página
  • Title
  • Patlet
  • Problema
  • Contexto
  • Resistencias
  • Solución
  • Contexto Resultante
  • Instancias Conocidas
  • Autores
  • Agradecimientos
  • Estado
  • Créditos
  • Histórico de Traducciones

¿Te fue útil?

Editar en GitHub
Exportar como PDF
  1. Patrones

Herramientas de Comunicación

Title

Herramientas de Comunicación

Patlet

Los usuarios de un proyecto InnerSource tienen dificultades para obtener ayuda y contactar con el equipo anfitrión. Mediante el uso consistente de herramientas de comunicación asincrónica, el proyecto hace que las discusiones sean visibles, archivadas y buscables, lo que conduce a un mejor nivel de soporte para los usuarios.

Problema

Un equipo está abierto a recibir contribuciones de los usuarios posteriores de su componente. Sin embargo, la coordinación y comunicación ocurre de manera improvisada, lo que lleva a compartir información incoherente, retrasos en las respuestas recibidas, y contribuyentes contactando a múltiples miembros del equipo anfitrión antes de recibir una respuesta definitiva.

Contexto

  • Un equipo depende del componente de otro equipo.

  • Le gustaría hacer contribuciones a ese componente.

  • Incluso cuando ocurre por escrito, la comunicación sucede de manera individual.

Resistencias

  • El equipo anfitrión está interesado en recibir contribuciones y dispuesto a guiar a los contribuyentes.

  • Los equipos tienen una fuerte cultura de comunicación verbal y poca experiencia en establecer canales de comunicación asincrónica específicos para proyectos.

  • Los canales de comunicación pueden estar alineados con grupos específicos que deben ser alcanzados pero no por propósito de comunicación.

Solución

El equipo anfitrión debe proporcionar canales de comunicación públicos dentro de la empresa, archivados, buscables y enlazables a los que cualquier persona en la empresa pueda suscribirse, ya que hay beneficios medibles al mantener canales de comunicación escritos y abiertos.

El objetivo al optimizar los canales de comunicación para proyectos InnerSource debe ser alinear la comunicación en torno a temas, no en torno a ciertos grupos de personas.

Un proyecto debe establecer las siguientes herramientas de comunicación:

  1. Canales de discusión públicos que tienen una estructura menos rígida. Típicamente, serán listas de correo, foros en línea, sistemas de preguntas y respuestas o incluso canales de chat archivados. Usualmente es suficiente comenzar con solo un canal para el proyecto. Si el tráfico aumenta demasiado, es útil separar las discusiones sobre el uso del proyecto de las discusiones sobre el desarrollo del proyecto.

Aunque la comunicación puede ocurrir fuera de estos canales escritos, se debe traer la mayor cantidad de información posible a los canales asincrónicos.

Los miembros del equipo anfitrión deben esforzarse por dirigir las preguntas que reciben personalmente (por ejemplo, por correo electrónico o mensajes privados) hacia los canales de comunicación oficiales.

Contexto Resultante

Con la comunicación ocurriendo abiertamente, otros pueden seguir fácilmente el progreso del proyecto y participar activamente contribuyendo. Otros observando y leyendo reduce la barrera para involucrarse, aumentando la probabilidad de recibir contribuciones.

Con las preguntas siendo respondidas en público, más personas pueden agregar su perspectiva llevando a una imagen completa - esto incluye no solo a los miembros del equipo anfitrión, sino también a los usuarios del proyecto.

Mantener la comunicación en canales asincrónicos permite que los participantes con diferentes horarios - ya sea debido a diferentes zonas horarias o debido a diferentes rutinas, horarios de reuniones, rutinas de equipo - contribuyan significativamente al proyecto.

Responder preguntas en estos canales significa que no solo otros miembros del equipo pueden escuchar y proporcionar información adicional, sino que también que otros usuarios con la misma pregunta ven (o encuentran más tarde) la respuesta anterior, lo que lleva a una menor necesidad de repetir explicaciones.

Instancias Conocidas

  • Europace AG

  • Paypal Inc.

  • Mercado Libre

Autores

Isabel Drost-Fromm

Agradecimientos

Sebastian Spier (por el visual)

Estado

  • Estructurado

  • Redactado en Diciembre 2019

Créditos

Histórico de Traducciones

AnteriorGrupo de SoporteSiguienteLicencia InnerSource

Última actualización hace 1 mes

¿Te fue útil?

Gestor de tareas dedicado donde la comunicación estructurada, la toma de decisiones y el seguimiento del progreso pueden ocurrir de manera transparente para todos los miembros del equipo anfitrión y también para los usuarios y contribuyentes posteriores. Para más aplicaciones del Gestor de Tareas, ver .

Un canal privado donde la comunicación sobre temas sensibles puede ocurrir entre - por ejemplo, agregar más Trusted Committers al equipo anfitrión. Este canal debe usarse con mucho cuidado para que la comunicación por defecto sea abierta y se mantenga privada solo en circunstancias muy raras.

Todos los canales de comunicación deben estar documentados en el archivo README.md del proyecto. Para más detalles sobre el uso de este archivo, ver .

Establecer y usar consistentemente canales de comunicación asincrónica oficiales ayuda a crear un nivel base de que puede ser referenciada nuevamente cuando surgen preguntas similares.

Ilustraciones de por Storyset

2025-04-03 - Traducción

2025-04-03 - Traducción

Casos de Uso del Gestor de Tareas
Trusted Committers
Documentación Base Estándar
documentación pasiva
People
Oscar Lobaton S.
Roman Martin Gil
Herramientas de Comunicación Recomendadas para un Proyecto InnerSource