Sumário

Padrões

Avaliação de Projeto entre Equipes - É difícil vender o valor de projetos InnerSource entre equipes que não proporcionam um impacto direto na receita da empresa. Aqui está uma maneira baseada em dados para representar seu projeto que articula seu valor e o amplifica.
Casos de uso do Issue Tracker - A equipe responsável pelo InnerSource falha em tornar não apenas os planos e o progresso transparentes, mas também o contexto das mudanças. Isso é resolvido aumentando os casos de uso do Issue Tracker do projeto para também servir como espaço para brainstorming, discussões de implementação e design de recursos.
Colaborador Contratado - Associados que desejam contribuir com o InnerSource são desencorajados a fazê-lo por sua gerência de linha. O alívio é fornecido por meio de contratos e acordos formais.
Comitê de Revisão - O Modelo de Trabalho InnerSource é uma ruptura radical das abordagens mais tradicionais, tanto para desenvolvedores quanto para gerentes. Ao estabelecer um Comitê de Revisão como uma interface entre a iniciativa InnerSource e todos os gerentes sêniores das unidades de negócios que participam dela, é mais provável que estes últimos se familiarizem com a iniciativa e a apoiem, uma vez que isso lhes proporciona um certo nível de supervisão e controle sem promover a microgestão.
Documentação Base Padrão - Novos contributors para um projeto InnerSource têm dificuldade em descobrir quem é o responsável pelo projeto, o que trabalhar e como contribuir. Fornecer documentação em arquivos padrão como README.md/CONTRIBUTING.md permite um processo de autoatendimento para novos contributors, para que possam encontrar as respostas para as perguntas mais comuns por conta própria.
Documente seus Princípios Orientadores - A explicação comum do InnerSource, "aplicando as melhores práticas de código aberto dentro de uma organização", não funciona bem com pessoas que não possuem um background em código aberto. Como solução, os princípios mais importantes do InnerSource são documentados e publicados amplamente.
Elogiar Participantes - Após uma contribuição de InnerSource, é importante agradecer ao contribuidor pelo seu tempo e esforço. Este padrão fornece orientações que não apenas reconhecem efetivamente a contribuição, mas também promovem um maior envolvimento do contribuidor e de outros.
Equipe Central - Mesmo quando um projeto InnerSource é amplamente necessário, as contribuições e uso podem ser prejudicados porque o projeto é difícil de trabalhar. Estabelecer uma equipe central dedicada a cuidar dos itens fundamentais do projeto. O trabalho deles permite que os contributors adicionem e usem recursos que oferecem valor para seus cenários.
Extensões para Crescimento Sustentável - Um projeto InnerSource está recebendo um grande número de contribuições, tornando a manutenção difícil. Ao oferecer um mecanismo de extensão fora do projeto principal, os mantenedores possibilitam a expansão das capacidades do projeto com custos mínimos e sobrecarga de manutenção.
Ferramentas de Comunicação - Os usuários de um projeto InnerSource têm dificuldade em obter ajuda e entrar em contato com a equipe responsável pelo projeto. Ao usar consistentemente ferramentas de comunicação assíncronas, o projeto torna as discussões visíveis, arquivadas e pesquisáveis, o que leva a um nível melhorado de suporte para os usuários.
Garantia de 30 dias - Ao aceitar contribuições de fora da sua própria equipe, há uma aversão natural em assumir a responsabilidade pelo código que não foi escrito pela própria equipe. Através da Garantia de 30 dias, a equipe contribuinte concorda em fornecer correções de bugs para a equipe receptora, o que aumentará o nível de confiança entre as duas equipes e torna mais provável que as contribuições sejam aceitas.
Gig Marketplace - Estabeleça um mercado criando um site intranet que liste necessidades específicas de projetos InnerSource como "Gigs", com requisitos explícitos de tempo e habilidades. Isso permitirá que os gerentes entendam melhor o compromisso de tempo de seus funcionários e os benefícios profissionais, aumentando assim a probabilidade de obter a aprovação para fazer contribuições InnerSource.
Inicie como um Experimento - Comece a sua iniciativa InnerSource como um experimento com limite de tempo para tornar mais fácil para os gestores que não estão familiarizados com o InnerSource endossar e apoiar a iniciativa.
Licença InnerSource - Duas entidades jurídicas que pertencem à mesma organização desejam compartilhar código-fonte de software entre si, mas estão preocupadas com as implicações em termos de responsabilidades legais ou contabilidade entre empresas.
Líder de Comunidade Dedicado - Selecione pessoas com habilidades tanto em comunicação quanto em técnicas para liderar as comunidades e garantir o sucesso na iniciativa InnerSource
Modelo de Maturidade - As equipes começaram a adotar o InnerSource. A prática está se espalhando para vários departamentos. No entanto, a compreensão do que constitui um projeto InnerSource varia. A solução é fornecer um modelo de maturidade para permitir que as equipes realizem uma autoavaliação e descubram padrões e práticas das quais ainda não têm conhecimento.
Portal InnerSource - Potenciais contribuidores não conseguem descobrir facilmente os projetos de InnerSource que lhes interessam. Ao criar um site de intranet que indexa todas as informações disponíveis sobre projetos de InnerSource, você permite que os contribuidores aprendam sobre projetos que possam interessá-los e que os proprietários de projetos de InnerSource atraiam um público externo.
Processo de Liberação Padrão - As equipes podem hesitar em adotar um projeto InnerSource se não tiverem certeza de sua maturidade. Para abordar isso, notas de lançamento consistentes e artefatos publicados são cruciais. Essas práticas demonstram um compromisso sólido com o projeto, transmitindo confiança e garantindo aos usuários o comprometimento contínuo com software sustentável e bem gerenciado.
Repositório Pontuação de Atividade - Potenciais contribuidores desejam encontrar projetos InnerSource ativos que precisem de sua ajuda. Ao calcular uma pontuação de atividade do repositório para cada projeto, uma lista classificada de projetos pode ser criada (por exemplo, no Portal InnerSource), para que os potenciais contribuidores possam determinar mais facilmente em qual projeto desejam contribuir.
Requisitos Comuns - O código comum em um repositório compartilhado não está atendendo às necessidades de todas as equipes de projeto que desejam usá-lo; isso é resolvido por meio do alinhamento de requisitos e refatoração.
Serviço vs. Biblioteca - Equipes em um ambiente DevOps podem relutar em trabalhar além dos limites de suas equipes em bases de código comuns, devido à ambiguidade sobre quem será responsável por responder a interrupções de serviço. A solução é perceber que muitas vezes é possível implantar o mesmo serviço em ambientes independentes com cadeias de escalonamento separadas no caso de interrupções de serviço, ou separar grande parte do código compartilhado em uma biblioteca única e colaborar nela.
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.
Tomada de Decisão Transparente entre Equipes usando RFCs - Projetos InnerSource que desejam alcançar altas taxas de participação e tomar as melhores decisões possíveis para todos os envolvidos precisam encontrar maneiras de criar sistemas participativos ao longo de todo o ciclo de vida do software. A publicação de documentos internos de "Requests for Comments" (RFCs) permite discussões desde o início do processo de design e aumenta as chances de construir soluções com um alto grau de comprometimento de todas as partes envolvidas.
Trusted Committer - Muitos projetos InnerSource se encontram em uma situação em que consistentemente recebem feedback, funcionalidades e correções de bugs de contribuidores. Nessas situações, os mantenedores do projeto buscam maneiras de reconhecer e recompensar o trabalho do contribuidor acima e além de contribuições individuais.

Apêndice

Recursos

AnteriorIntrodução PróximoExplorar Padrões

Atualizado há 1 ano

Padrões

Avaliação de Projeto entre Equipes - É difícil vender o valor de projetos InnerSource entre equipes que não proporcionam um impacto direto na receita da empresa. Aqui está uma maneira baseada em dados para representar seu projeto que articula seu valor e o amplifica.

Casos de uso do Issue Tracker - A equipe responsável pelo InnerSource falha em tornar não apenas os planos e o progresso transparentes, mas também o contexto das mudanças. Isso é resolvido aumentando os casos de uso do Issue Tracker do projeto para também servir como espaço para brainstorming, discussões de implementação e design de recursos.

Colaborador Contratado - Associados que desejam contribuir com o InnerSource são desencorajados a fazê-lo por sua gerência de linha. O alívio é fornecido por meio de contratos e acordos formais.

Comitê de Revisão - O Modelo de Trabalho InnerSource é uma ruptura radical das abordagens mais tradicionais, tanto para desenvolvedores quanto para gerentes. Ao estabelecer um Comitê de Revisão como uma interface entre a iniciativa InnerSource e todos os gerentes sêniores das unidades de negócios que participam dela, é mais provável que estes últimos se familiarizem com a iniciativa e a apoiem, uma vez que isso lhes proporciona um certo nível de supervisão e controle sem promover a microgestão.

Documentação Base Padrão - Novos contributors para um projeto InnerSource têm dificuldade em descobrir quem é o responsável pelo projeto, o que trabalhar e como contribuir. Fornecer documentação em arquivos padrão como README.md/CONTRIBUTING.md permite um processo de autoatendimento para novos contributors, para que possam encontrar as respostas para as perguntas mais comuns por conta própria.

Documente seus Princípios Orientadores - A explicação comum do InnerSource, "aplicando as melhores práticas de código aberto dentro de uma organização", não funciona bem com pessoas que não possuem um background em código aberto. Como solução, os princípios mais importantes do InnerSource são documentados e publicados amplamente.

Elogiar Participantes - Após uma contribuição de InnerSource, é importante agradecer ao contribuidor pelo seu tempo e esforço. Este padrão fornece orientações que não apenas reconhecem efetivamente a contribuição, mas também promovem um maior envolvimento do contribuidor e de outros.

Equipe Central - Mesmo quando um projeto InnerSource é amplamente necessário, as contribuições e uso podem ser prejudicados porque o projeto é difícil de trabalhar. Estabelecer uma equipe central dedicada a cuidar dos itens fundamentais do projeto. O trabalho deles permite que os contributors adicionem e usem recursos que oferecem valor para seus cenários.

Extensões para Crescimento Sustentável - Um projeto InnerSource está recebendo um grande número de contribuições, tornando a manutenção difícil. Ao oferecer um mecanismo de extensão fora do projeto principal, os mantenedores possibilitam a expansão das capacidades do projeto com custos mínimos e sobrecarga de manutenção.

Ferramentas de Comunicação - Os usuários de um projeto InnerSource têm dificuldade em obter ajuda e entrar em contato com a equipe responsável pelo projeto. Ao usar consistentemente ferramentas de comunicação assíncronas, o projeto torna as discussões visíveis, arquivadas e pesquisáveis, o que leva a um nível melhorado de suporte para os usuários.

Garantia de 30 dias - Ao aceitar contribuições de fora da sua própria equipe, há uma aversão natural em assumir a responsabilidade pelo código que não foi escrito pela própria equipe. Através da Garantia de 30 dias, a equipe contribuinte concorda em fornecer correções de bugs para a equipe receptora, o que aumentará o nível de confiança entre as duas equipes e torna mais provável que as contribuições sejam aceitas.

Gig Marketplace - Estabeleça um mercado criando um site intranet que liste necessidades específicas de projetos InnerSource como "Gigs", com requisitos explícitos de tempo e habilidades. Isso permitirá que os gerentes entendam melhor o compromisso de tempo de seus funcionários e os benefícios profissionais, aumentando assim a probabilidade de obter a aprovação para fazer contribuições InnerSource.

Inicie como um Experimento - Comece a sua iniciativa InnerSource como um experimento com limite de tempo para tornar mais fácil para os gestores que não estão familiarizados com o InnerSource endossar e apoiar a iniciativa.

Licença InnerSource - Duas entidades jurídicas que pertencem à mesma organização desejam compartilhar código-fonte de software entre si, mas estão preocupadas com as implicações em termos de responsabilidades legais ou contabilidade entre empresas.

Líder de Comunidade Dedicado - Selecione pessoas com habilidades tanto em comunicação quanto em técnicas para liderar as comunidades e garantir o sucesso na iniciativa InnerSource

Modelo de Maturidade - As equipes começaram a adotar o InnerSource. A prática está se espalhando para vários departamentos. No entanto, a compreensão do que constitui um projeto InnerSource varia. A solução é fornecer um modelo de maturidade para permitir que as equipes realizem uma autoavaliação e descubram padrões e práticas das quais ainda não têm conhecimento.

Portal InnerSource - Potenciais contribuidores não conseguem descobrir facilmente os projetos de InnerSource que lhes interessam. Ao criar um site de intranet que indexa todas as informações disponíveis sobre projetos de InnerSource, você permite que os contribuidores aprendam sobre projetos que possam interessá-los e que os proprietários de projetos de InnerSource atraiam um público externo.

Processo de Liberação Padrão - As equipes podem hesitar em adotar um projeto InnerSource se não tiverem certeza de sua maturidade. Para abordar isso, notas de lançamento consistentes e artefatos publicados são cruciais. Essas práticas demonstram um compromisso sólido com o projeto, transmitindo confiança e garantindo aos usuários o comprometimento contínuo com software sustentável e bem gerenciado.

Repositório Pontuação de Atividade - Potenciais contribuidores desejam encontrar projetos InnerSource ativos que precisem de sua ajuda. Ao calcular uma pontuação de atividade do repositório para cada projeto, uma lista classificada de projetos pode ser criada (por exemplo, no Portal InnerSource), para que os potenciais contribuidores possam determinar mais facilmente em qual projeto desejam contribuir.

Requisitos Comuns - O código comum em um repositório compartilhado não está atendendo às necessidades de todas as equipes de projeto que desejam usá-lo; isso é resolvido por meio do alinhamento de requisitos e refatoração.

Serviço vs. Biblioteca - Equipes em um ambiente DevOps podem relutar em trabalhar além dos limites de suas equipes em bases de código comuns, devido à ambiguidade sobre quem será responsável por responder a interrupções de serviço. A solução é perceber que muitas vezes é possível implantar o mesmo serviço em ambientes independentes com cadeias de escalonamento separadas no caso de interrupções de serviço, ou separar grande parte do código compartilhado em uma biblioteca única e colaborar nela.

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.

Tomada de Decisão Transparente entre Equipes usando RFCs - Projetos InnerSource que desejam alcançar altas taxas de participação e tomar as melhores decisões possíveis para todos os envolvidos precisam encontrar maneiras de criar sistemas participativos ao longo de todo o ciclo de vida do software. A publicação de documentos internos de "Requests for Comments" (RFCs) permite discussões desde o início do processo de design e aumenta as chances de construir soluções com um alto grau de comprometimento de todas as partes envolvidas.

Trusted Committer - Muitos projetos InnerSource se encontram em uma situação em que consistentemente recebem feedback, funcionalidades e correções de bugs de contribuidores. Nessas situações, os mantenedores do projeto buscam maneiras de reconhecer e recompensar o trabalho do contribuidor acima e além de contribuições individuais.