Soporte grupal

Title

Soporte grupal

Patlet

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.

Problema

• Un proxecto InnerSource popular queda orfo.

• Non se conta cun sitio claro para a súa publicación.

Historia

Máis de 50 proxectos de toda a compañía empregan unha libraría de widgets UI. O equipo disólvese ao esgotarse o financiamento do equipo propietario da libraría. Nun principio, ninguén se decata mais, despois dalgún tempo, cada vez que alguén pregunta quen é o/a propietario/a, non hai resposta. Que vai pasar agora? Os novos equipos evitarán usala? Estancarase o proxecto e permanecerá así ata que finalmente os/as seus/súas usuarios/as se vexan obrigados/as a cambiar a outra cousa? Unha mágoa se iso pasase cun proxecto bo e perfectamente útil!

Contexto

• Proxecto InnerSource popular.

• Consumido como unha dependencia do tempo de compilación (por exemplo, o módulo de código).

• Ninguén lle presta soporte de forma activa.

• A compañía non pode asignar un equipo de soporte.

Aspectos que mellorar

• Ninguén ten asignado como traballo principal encargarse do caso.

• Todos/as están ocupados/as.

• A migración fóra do proxecto ten un alto custo.

Solucións

Convocar voluntarios/as interesados/as de calquera sector da compañía para formar un grupo de trusted committers que dean soporte ao proxecto. Pode ser preciso pórse en contacto con individuos específicos, en función do historial de uso e commits. É importante que sexan suficientes para que a carga de cada un/unha deles/as sexa razoablemente pequena.

Ao formarse, este grupo debería identificar ou constituír unha documentación base estándar e ferramentas de comunicación.

O grupo fará o posible para xestionar estes aspectos do proxecto:

• Mantemento. Se o proxecto está totalmente roto para o caso de uso estándar, haberá que arranxalo. É preciso manter o proxecto actualizado a medida que as dependencias e os marcos que usa seguen a desenvolverse.

• Incorporación. Se alguén ten unha pregunta sobre como empregar o proxecto, haberá que asegurarse de que obtén unha resposta razoable.

• Actualizacións. Se alguén quere engadir novas funcionalidades ao proxecto, proporcionaráselle o deseño e soporte técnico precisos para a súa contribución, de xeito que sexa tanto bo para eles/as como para o proxecto. As pull requests entrantes revisaranse de maneira oportuna.

Posto que o grupo está formado por voluntarios/as, é importante comunicar que o soporte é só o seu «mellor esforzo». E, en consecuencia, este modelo de soporte non é adecuado para proxectos de produción críticos en tempo de execución como as live API. Será máis axeitado para proxectos que se consomen no tempo de compilación, como librarías/paquetes/módulos. Non se espera que o grupo introduza ningunha funcionalidade nova para outros.

Contexto resultante

• Soporte feble para o proxecto InnerSource.

• A longo prazo, é probable que volva faltar o soporte nalgún momento. Polo que se o proxecto continúa no tempo, deberá empregarse este período de soporte grupal estable para dar cunha forma duradeira de mantelo (por exemplo, o core team).

Fundamento

A xente xeralmente estará disposta a axudar. Se alguén quere converterse en trusted committer, o máis probable é que un gran número de persoas estean de acordo. Sentirse parte dun grupo e ter certa estrutura e responsabilidade, en xeral, motiva á xente a dar o máximo posible, o que a meirande parte das veces acaba sendo suficiente.

Exemplos coñecidos

• WellSky

Estado

• Estruturado

Autoría

• Russell R. Rutledge

Tradución

• Leticia Gómez Cadahía

• María Lucía González Castro