Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create 02-ensuring-product-quality-pt-br.asciidoc #571

Merged
merged 2 commits into from
Aug 1, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
== Assegurando a qualidade do produto

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.