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
  • Historia
  • Contexto
  • Resistencias
  • Soluciones
  • Contexto Resultante
  • Razonamiento
  • Instancias Conocidas
  • Estado
  • Autor
  • Histórico de Traducciones

¿Te fue útil?

Editar en GitHub
Exportar como PDF
  1. Patrones

Grupo de Soporte

Title

Grupo de Soporte

Patlet

¿Qué sucede si un equipo o individuo deja de mantener un proyecto InnerSource? Mantén el proyecto activo formando un grupo de personas interesadas.

Problema

  • Un proyecto InnerSource popular queda huérfano.

  • No tiene un equipo claro que lo adopte.

Historia

Una librería de widgets de UI es utilizada por más de 50 proyectos en toda la empresa. El financiamiento para el equipo propietario de la librería se agota y el equipo se disuelve. Al principio, nadie lo nota, pero después de un tiempo cuando alguien pregunta "¿quién es el propietario?" no hay respuesta. ¿Qué sucederá después? ¿Los nuevos equipos evitarán usarlo? ¿El proyecto se estancará y persistirá hasta que sus usuarios eventualmente se vean forzados a migrar a otra solución? ¡Qué lástima sería si esto le sucediera a un proyecto perfectamente bueno y útil!

Contexto

  • Proyecto InnerSource popular.

  • Consumido como una dependencia en tiempo de compilación (por ejemplo, módulo de código).

  • Nadie lo está manteniendo activamente.

  • La empresa no puede asignar un equipo para mantenerlo.

Resistencias

  • Nadie está asignado por su trabajo diario para trabajar en ello.

  • Todos están ocupados.

  • Alto costo para migrar fuera del proyecto.

Soluciones

El grupo debe hacer su mejor esfuerzo para gestionar estos aspectos del proyecto:

  • Mantenimiento. Si el proyecto está completamente roto para el caso de uso estándar, entonces arréglalo. Mantén el proyecto actualizado a medida que las dependencias y los frameworks que utiliza continúan evolucionando.

  • Incorporación. Si alguien tiene una pregunta sobre cómo usar el proyecto, asegúrate de que obtenga una respuesta razonable.

  • Actualizaciones. Si alguien quiere agregar una nueva funcionalidad al proyecto, dale el soporte de diseño y técnico necesario para que lo construya de manera que funcione para ellos y sea una buena adición al proyecto. Revisa las pull requests entrantes de manera oportuna.

Dado que este grupo está compuesto por voluntarios, es importante comunicar que el soporte es solo "mejor esfuerzo". En consecuencia, este modelo de soporte no es adecuado para proyectos críticos en tiempo de ejecución, como APIs en vivo. Es más adecuado para proyectos que se consumen en tiempo de compilación, como librerías/paquetes/módulos. No se espera que el grupo implemente ninguna funcionalidad nueva para otros.

Contexto Resultante

  • Hay algún soporte frágil para el proyecto InnerSource.

Razonamiento

Instancias Conocidas

  • WellSky

Estado

Estructurado

Autor

Histórico de Traducciones

AnteriorGarantía de 30 DíasSiguienteHerramientas de Comunicación

Última actualización hace 2 meses

¿Te fue útil?

Llama a voluntarios interesados de cualquier parte de la empresa para formar un grupo de s para mantener el proyecto. Es posible que necesites contactar a individuos específicos basándote en el historial de commits o de uso. Es importante que haya suficientes personas para que la carga sobre cada uno sea razonablemente pequeña.

Al formarse, este grupo debe identificar o crear y .

A largo plazo, es probable que el grupo de soporte se disuelva nuevamente en algún momento. Si el proyecto continúa a largo plazo, utiliza este período de grupo de soporte estable para encontrar una forma de mantenerlo a largo plazo (por ejemplo, ).

La gente generalmente quiere ayudar. Si hay un alcance personal para que alguien se una como , generalmente hay varias personas que dirán "sí". Sentirse parte de un grupo y recibir algo de estructura y responsabilidad generalmente motiva a las personas a hacer su mejor esfuerzo, lo cual muchas veces resulta ser suficiente.

2025-04-03 - Traducción

2025-04-03 - Traducción

Trusted Committer
Documentación Base Estándar
Herramientas de Comunicación
Equipo Central
Trusted Committer
Russell R. Rutledge
Oscar Lobaton S.
Roman Martin Gil