Vamos começar com a responsabilidade mais frequentemente associada ao Trusted Committer: garantir a qualidade do produto.
Em uma comunidade InnerSource, os Trusted Committers possuem todas as decisões relacionadas à tecnologia, especialmente aquelas relacionadas à qualidade do produto. A propriedade implica a necessidade de assegurar que as decisões em vigor sejam seguidas. Isso inclui comunicar e-se necessário-defender essas decisões, dentro e fora da comunidade. Mas os Trusted Committers não necessariamente tomam todas as decisões relacionadas à tecnologia ou fazem todo o trabalho para implementá-las.
É tarefa do Trusted Committer comunicar e esclarecer padrões de qualidade em sua comunidade e formulá-los de uma maneira que seja compreensível e acionável por seus https://innersourcecommons.org/learn/learning-path/contributor [Contributors]. Isso inclui documentação escrita, é claro, mas a maneira mais eficaz para os Trusted Committers comunicarem esses padrões de qualidade é através do exemplo. Achamos que pode ser um objetivo útil para uma comunidade InnerSource tentar se distinguir dos projetos tradicionais de desenvolvimento de software não apenas na forma como eles organizam o desenvolvimento, mas também na qualidade do software que eles produzem. Um alto nível de qualidade de software é essencial para estabelecer e manter a confiança na comunidade InnerSource por parte de seus usuários e sua administração. Todos nós sabemos como uma release ruim pode quebrar essa confiança em um instante.
Os Trusted Committers também garantem que a comunidade tenha a infraestrutura e as ferramentas necessárias para produzir software de qualidade. A revisão por pares, geralmente executada como parte de pull requests (PRs), é frequentemente usada para assegurar a qualidade. Embora geralmente todos podem começar e participar de pull requests apontando melhorias necessárias, geralmente é apenas o Trusted Committer que pode aceitar e mesclar ou rejeitar uma contribuição. Isto é o que nós dissemos antes quando nós falamos que "Trusted Committers podem levar o código mais perto da produção." Os Trusted Committers também devem ajudar os https://innersourcecommons.org/learn/learning-path/contributor [Contributors] durante um PR para finalizar suas contribuições.
Dito isso, é trabalho do contributor fazer isso acontecer. O trabalho de um Trusted Committer não é aceitar todas as contribuições por padrão, mas apenas aquelas que atendem aos critérios definidos em termos de qualidade e escopo. E os Trusted Committers devem evitar reescrever o código de um contribuidor para torná-lo "adequado" o máximo possível, mesmo que isso signifique gastar mais tempo apoiando https://innersourcecommons.org/learn/learning-path/contributor [Contributors] em um PR. Os Trusted Committers têm uma perspectiva de longo prazo e entendem que esse tipo de apoio é um investimento na longevidade da comunidade, e aumentará a velocidade de desenvolvimento da comunidade a longo prazo.
Às vezes, os requisitos ou limitações do projeto não são conhecidos antecipadamente e são descobertos durante o desenvolvimento. Os Trusted Committers também são responsáveis por assegurar que essas descobertas sejam capturadas e documentadas para os https://innersourcecommons.org/learn/learning-path/product-owner [Product Owners] e os https://innersourcecommons.org/learn/learning-path/contributor [Contributors].
Mas o alcance do Trusted Committer em relação à qualidade vai além dos pull requets. Os Trusted Committers pensam sobre a qualidade em um nível estratégico e garantem a longevidade do software que está sendo construído. Isso implica em responsabilidades orientadas ao código, desde assegurar a limpeza do código até manter a integridade conceitual do software geral. Ele também envolve tarefas orientadas ao gerenciamento, como garantir que a comunidade tenha tempo suficiente para refatorar seu software ou mover uma data de release em favor de melhorias de qualidade, se necessário. A eficácia do Trusted Committer está fortemente relacionada com a saúde do código.
Na ausência deste último, os Trusted Committers terão que gastar muito de seu valioso tempo validando e documentando soluções alternativas para erros ou uma arquitetura frágil e não terão tempo suficiente para migrar e orientar https://innersourcecommons.org/learn/learning-path/contributor [Contributors].
Em conclusão, garantir a qualidade do produto é uma responsabilidade fundamental dos Trusted Committers. Eles estabelecem padrões de qualidade e dão o exemplo. Eles participam de pull requests e ajudam https://innersourcecommons.org/learn/learning-path/contributor [Contributors] a atender os padrões de qualidade. Eles também assumem a responsabilidade pela saúde do software a longo prazo.
