Índice
Modelos
Agradecemento aos/ás participantes - Tras unha contribución a un proxecto InnerSource, é importante agradecer ao/á colaborador/a polo seu tempo e esforzo. Este modelo brinda unha orientación que non só recoñece dun xeito eficaz a súa contribución, senón que tamén xera un maior compromiso deste/a e doutros/as contribuidores/as.
Casos de uso cun sistema de seguimento de incidencias - o host team de InnerSource non logra ter transparencia nos plans nin no progreso, e tampouco no contexto para os cambios. Isto resólvese aumentando os casos de uso co sistema de seguimento de incidencias do proxecto para que tamén favoreza o intercambio de ideas, o debate sobre estas e o deseño de funcionalidades.
Comece como un experimento - comece a súa iniciativa InnerSource como un experimento de tempo limitado para facilitar que o persoal directivo, que non estea familiarizado con InnerSource, secunde e apoie a iniciativa.
Comité de revisión - o modelo de traballo InnerSource é un afastamento radical dos enfoques máis tradicionais, tanto para os/as desenvolvedores/as como para os/as seus/súas superiores/as. Ao establecer un comité de revisión como interface entre a iniciativa InnerSource e todos os altos cargos das áreas empresariais que participan nela, é máis probable que estes últimos se familiaricen coa iniciativa e a apoien; xa que lles brinda un certo nivel de supervisión e control, sen fomentar a microxestión.
Contracted contributor - os/as socios/as que desexen contribuír a InnerSource son disuadidos/as de facelo polos/as seus/súas superiores/as. Os contratos e acordos formais son un alivio.
Core team - incluso cando se necesita moito un proxecto InnerSource, as colaboracións e o seu uso poden verse obstaculizados porque é difícil traballar co proxecto. Estableza un core team que se dedique a coidar dos elementos fundamentais do proxecto. O traballo do core team permítelle aos/ás contribuidores/as engadir e empregar as funcionalidades que achegan valor aos seus escenarios.
Cualificación da actividade do repositorio - os/as potenciais contribuidores/as queren atopar proxectos InnerSource activos que precisen da súa participación. Ao calcular a cualificación da actividade do repositorio para cada proxecto, pódese crear unha listaxe clasificada de proxectos (por exemplo, no portal InnerSource) para que os/as posibles contribuidores/as poidan determinar dun xeito máis doado en que proxecto desexan colaborar.
Documentación base estándar - ós/ás novos/as contribuidores/as dun proxecto InnerSource teñen dificultades para determinar quen mantén o proxecto, en que traballar e como contribuír. Ao proporcionar documentación en arquivos estándar como README.md/CONTRIBUTING.md permítese un proceso de autoservizo para os/as novos/as contribuidores/as, de xeito que poidan atopar por si mesmos/as as respostas ás preguntas máis comúns.
Documente os seus principios reitores - a explicación habitual de InnerSource baseada en «aplicar as mellores prácticas de software libre dentro dunha organización» non funciona correctamente coas persoas que carecen de experiencia con software libre. Como solución, os principios InnerSource máis importantes documéntanse e publícanse de maneira aberta.
Extensións para o crecemento sostible - un proxecto InnerSource está a recibir demasiadas contribucións, o que dificulta o seu mantemento. Os/As responsables ofrecen un mecanismo de extensión fóra do proxecto principal, que permite escalar as capacidades do proxecto cun custo e gastos xerais de mantemento mínimos.
Ferramentas de comunicación - os/as usuarios/as dun proxecto InnerSource teñen problemas para obter axuda e poñerse en contacto co host team. Mediante o uso sistemático de ferramentas de comunicación asíncrona, os debates serán visibles e permanecerán arquivados e accesibles; o que se traduce nunha mellora do nivel de asistencia aos/ás usuarios/as.
Garantía de 30 días - cando se aceptan contribucións externas, existe unha aversión natural do equipo a asumir a responsabilidade do código que non foi escrito por eles/as. A través da garantía de 30 días, o equipo contribuidor acepta proporcionar correccións de erros ao equipo receptor. Isto aumentará o nivel de confianza de ambos os equipos e fará que sexa máis probable que se acepten as contribucións.
Gig marketplace - establécese un marketplace mediante a creacion dunha intranet que enumere as necesidades específicas do proxecto InnerSource como «Gigs», con requisitos explícitos de tempo e habilidades. Isto permitiralle ao personal directivo comprender mellor o compromiso no tempo e os beneficios profesionais dos seus/súas traballadores/as, o que aumentará a probabilidade de obter a aprobación para realizar contribucións InnerSource.
Licenza InnerSource - dúas entidades xurídicas que pertencen á mesma organización queren compartir o código fonte do software entre elas, mais preocúpanlles as implicacións en termos de responsabilidades legais ou de contabilidade entre as empresas.
Líder da comunidade experto/a en InnerSource - seleccione persoas con habilidades técnicas e de comunicación para liderar as comunidades e garantir o éxito no inicio dunha iniciativa InnerSource
Modelo de madurez - os equipos comezaron a adoptar InnerSource e a práctica estase estendendo a varios departamentos. Con todo, a comprensión do que constitúe un proxecto InnerSource varía. A solución consiste en proporcionar un modelo de madurez que lles permita aos equipos realizar unha autoavaliación e descubrir modelos e prácticas que aínda non coñecían.
Portal InnerSource - os/as contribuidores/as potenciais non poden descubrir dun xeito sinxelo os proxectos InnerSource nos que están interesados/as. Ao crear unha intranet que indexe toda a información dispoñible do proxecto InnerSource, permítese que os/as contribuidores/as coñezan os proxectos que lles poderían interesar; do mesmo xeito que lles serve aos/ás project owners de InnerSource para atraer a un público externo.
Requisitos comúns - o código común dun repositorio compartido non satisfai as necesidades de todos os equipos do proxecto que desexan empregalo; isto resólvese mediante a aliñación de requisitos e a refactorización.
Servizo vs. libraría - os equipos DevOps poden ser reticentes a traballar máis alá dos límites do equipo, en bases de código comúns; posto que non está definido quen sería a persoa responsable de responder ante unha situación de inactividade do servizo. Con frecuencia, a solución pode ser implantar o mesmo servizo en contextos independentes con cadeas de escalada separadas, en caso de caída do servizo ou de factorización dunha gran cantidade de código compartido nunha libraría na que se poidan facer colaboracións.
Soporte grupal - que acontece se un equipo ou unha persoa abandona un proxecto InnerSource? Para manter vivo o proxecto fórmase un novo grupo de colaboradores/as interesados/as.
Toma de decisións transparente entre equipos mediante RFC - os proxectos InnerSource que desexan lograr un alto índice de participación e tomar as mellores decisións posibles para todas as persoas involucradas, necesitan atopar formas de crear sistemas participativos durante todo o ciclo de vida do software. A publicación de documentos internos con peticións de comentarios (RFC) permite manter debates desde o comezo do proceso de deseño. Tamén aumenta as posibilidades de idear solucións cun alto grao de compromiso por parte de tódalas partes implicadas.
Trusted commiter - moitos proxectos InnerSource recibirán valoracións constantemente ou requirirán a posta en marcha de novas funcionalidades e a corrección de erros por parte dos contribuidores/as. Nestas situacións, as persoas encargadas do mantemento do proxecto buscan formas de recoñecer e recompensar o traballo do contribuidor/a máis alá das contribucións individuais.
Valoración de proxectos entre equipos - é difícil convencer acerca do valor dos proxectos InnerSource desenvolvidos entre equipos que non teñen un impacto directo nos ingresos da empresa. Velaquí unha forma de representar o seu proxecto baseada en datos, que articula o seu valor e amplifícao.
Apéndice
Recursos
Last updated
