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
2023-10-26 - Tradução Eneri Junior
2023-10-26 - Tradução Humberto Zilio