LogoLogo
Contribute to InnerSource PatternsJoin the community
🇧🇷 Português Brasileiro
🇧🇷 Português Brasileiro
  • Introdução
  • Sumário
  • Explorar Padrões
  • Contribuir para Este Livro
  • Padrões
    • Avaliação de Projeto entre Equipes
    • Casos de uso do Issue Tracker
    • Colaborador Contratado
    • Comitê de Revisão
    • Documentação Base Padrão
    • Documente seus Princípios Orientadores
    • Elogiar Participantes
    • Equipe Central
    • Extensões para Crescimento Sustentável
    • Ferramentas de Comunicação
    • Garantia de 30 dias
    • Gig Marketplace
    • Inicie como um Experimento
    • Licença InnerSource
    • Líder de Comunidade Dedicado
    • Modelo de Maturidade
    • Portal InnerSource
    • Processo de Liberação Padrão
    • Repositório Pontuação de Atividade
    • Requisitos Comuns
    • Serviço vs. Biblioteca
    • Suporte em Grupo
    • Tomada de Decisão Transparente entre Equipes usando RFCs
    • Trusted Committer
  • Apêndice
    • Modelo de Padrão
    • Extras
      • Modelo de README
      • Modelo de CONTRIBUTING
  • Recursos
    • Este livro no GitHub
    • InnerSource Commons
Fornecido por GitBook
Nesta página
  • Title
  • Patlet
  • Problema
  • História
  • Contexto
  • Forças
  • Solução
  • Contexto Resultante
  • Justificativa
  • Instâncias Conhecidas
  • Estado
  • Autores
  • Histórico de Tradução

Isto foi útil?

Editar no GitHub
Exportar como PDF
  1. Padrões

Suporte em Grupo

Title

Suporte em Grupo

Patlet

O que acontece se uma equipe ou indivíduo não suporta mais um projeto InnerSource? Mantenha o projeto vivo formando um grupo de indivíduos interessados.

Problema

  • Um projeto InnerSource popular está órfão.

  • Não há um destino óbvio para ele.

História

Uma biblioteca de widgets de interface do usuário é usada por mais de 50 projetos em toda a empresa. O financiamento da equipe que é proprietária da biblioteca se esgota e a equipe se dissipa. No início, ninguém percebe, mas depois de um tempo, sempre que alguém pergunta "quem é o responsável", não há uma resposta. O que acontecerá em seguida? As novas equipes evitarão usá-lo? O projeto estagnará e permanecerá até que seus usuários eventualmente sejam forçados a migrar para outra solução? Que pena se isso acontecer a um projeto perfeitamente bom e útil!

Contexto

  • Projeto InnerSource popular.

  • Consumido como uma dependência de tempo de compilação (por exemplo, módulo de código).

  • Ninguém está oferecendo suporte ativamente.

  • A empresa não pode alocar uma equipe para oferecer suporte.

Forças

  • Ninguém é designado por seu trabalho diário para trabalhar nele.

  • Todos estão ocupados.

  • Alto custo para migrar do projeto.

Solução

O grupo deve fazer o melhor para gerenciar esses aspectos do projeto:

  • Manutenção. Se o projeto estiver completamente quebrado para o caso de uso padrão, então conserte-o. Mantenha o projeto atualizado à medida que as dependências e estruturas que ele usa continuam a evoluir.

  • Integração. Se alguém tiver uma pergunta sobre como usar o projeto, certifique-se de que eles obtenham uma resposta razoável.

  • Atualizações. Se alguém desejar adicionar um novo recurso ao projeto, forneça o suporte de design e técnico necessário para que eles o construam, de modo que funcione para eles e seja uma boa adição ao projeto. Revise as solicitações de pull que chegam de forma oportuna.

Uma vez que este grupo é composto por voluntários, é importante comunicar que o suporte é "melhor esforço" apenas. Portanto, este modelo de suporte não é adequado para projetos críticos em tempo de execução, como APIs em produção. Ele é mais adequado para projetos que são consumidos no momento de compilação, como bibliotecas/pacotes/módulos. Não se espera que o grupo implemente qualquer nova funcionalidade para outros.

Contexto Resultante

  • Existe algum suporte frágil para o projeto InnerSource.

Justificativa

Instâncias Conhecidas

  • WellSky

Estado

Structured

Autores

Histórico de Tradução

AnteriorServiço vs. BibliotecaPróximoTomada de Decisão Transparente entre Equipes usando RFCs

Atualizado há 1 ano

Isto foi útil?

Chamar voluntários interessados de qualquer parte da empresa para formar um grupo de s para oferecer suporte ao projeto. Você pode precisar entrar em contato com indivíduos específicos com base no histórico de commits ou uso. É importante que haja pessoas suficientes para que a carga sobre cada uma seja razoavelmente pequena.

Ao formar este grupo, ele deve identificar ou criar e .

A longo prazo, é provável que o suporte do grupo se dissolva novamente em algum momento. Se o projeto continuar a longo prazo, aproveite este período de suporte estável do grupo para encontrar uma maneira duradoura de suportá-lo (por exemplo, ).

As pessoas geralmente querem ajudar. Se houver uma abordagem pessoal para que alguém se junte como um , geralmente haverá várias pessoas que dirão "sim". Sentir-se parte de um grupo e ser atribuído a alguma estrutura e responsabilidade geralmente motiva as pessoas a fazer o seu melhor, o que muitas vezes acaba sendo suficiente.

2023-10-26 - Tradução

2023-10-26 - Tradução

Trusted Committer
Standard Base Documentation
Communication Tooling
Core Team
Trusted Committer
Russell R. Rutledge
Eneri Junior
Humberto Zilio