Comment on page
Suporte em Grupo
Suporte em Grupo
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.
- Um projeto InnerSource popular está órfão.
- Não há um destino óbvio para ele.
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!
- 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.
- Ninguém é designado por seu trabalho diário para trabalhar nele.
- Todos estão ocupados.
- Alto custo para migrar do projeto.
Chamar voluntários interessados de qualquer parte da empresa para formar um grupo de Trusted Committers 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 Standard Base Documentation e Communication Tooling.
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.
- Existe algum suporte frágil para o projeto InnerSource.
- 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, Core Team).
As pessoas geralmente querem ajudar. Se houver uma abordagem pessoal para que alguém se junte como um Trusted Committer, 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.
- WellSky
Structured