diff --git a/Documentation/translations/pt_BR/index.rst b/Documentation/translations/pt_BR/index.rst index 4a13b3d14d5a..749c5fc3f355 100644 --- a/Documentation/translations/pt_BR/index.rst +++ b/Documentation/translations/pt_BR/index.rst @@ -76,6 +76,7 @@ kernel e sobre como ver seu trabalho integrado. Como começar Requisitos mínimos Conclave (Continuidade do projeto) + Modelos de Maturidade para Contribuição no Kernel Linux Manuais dos mantenedores Processo do subsistema de rede (netdev) Processo do subsistema SoC diff --git a/Documentation/translations/pt_BR/process/contribution-maturity-model.rst b/Documentation/translations/pt_BR/process/contribution-maturity-model.rst new file mode 100644 index 000000000000..bb003c4cd0d9 --- /dev/null +++ b/Documentation/translations/pt_BR/process/contribution-maturity-model.rst @@ -0,0 +1,111 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================================================= +Modelos de Maturidade para Contribuição no Kernel Linux +======================================================= + + +Contexto +======== + +Como parte do Linux Kernel Maintainers’ Summit de 2021, houve uma +`discussão `_ sobre os desafios na +contratação de mantenedores do kernel, bem como a sucessão de mantenedores. +Algumas das conclusões daquela discussão incluíram que as empresas que fazem +parte da comunidade do Kernel Linux precisam permitir que os engenheiros atuem +como mantenedores como parte de seu trabalho, para que possam crescer e se +tornar líderes respeitados e, eventualmente, mantenedores do kernel. Para +apoiar um fluxo forte de talentos, os desenvolvedores devem ser autorizados e +incentivados a assumir contribuições no upstream, como revisar os patches de +outras pessoas, refatorar a infraestrutura do kernel e escrever documentação. + +Para tanto, o Conselho Técnico Consultivo (Technical Advisory Board - TAB) da +Linux Foundation propõe este Modelo de Maturidade para Contribuição no Kernel +Linux. Essas expectativas comuns para o engajamento da comunidade upstream visam +aumentar a influência de desenvolvedores individuais, aumentar a colaboração +de organizações e melhorar a saúde geral do ecossistema do Kernel Linux. + +O TAB insta as organizações a avaliarem continuamente seu modelo de maturidade +em Open Source e a se comprometerem com melhorias para se alinharem a este +modelo. Para ser eficaz, essa avaliação deve incorporar o feedback de toda a +organização, incluindo a gerência e os desenvolvedores de todos os níveis de +senioridade. No espírito do Open Source, incentivamos as organizações a +publicarem suas avaliações e planos para melhorar seu engajamento com a +comunidade upstream. + +Nível 0 +======= + +* Engenheiros de Software não têm permissão para contribuir com patches para o + kernel Linux. + + +Nível 1 +======= + +* Engenheiros de Software têm permissão para contribuir com patches para o + kernel Linux, seja como parte de suas responsabilidades de trabalho ou em seu + próprio tempo. + +Nível 2 +======= + +* Espera-se que os Engenheiros de Software contribuam para o Kernel Linux como + parte de suas responsabilidades de trabalho. +* Os Engenheiros de Software receberão apoio para participar de conferências + relacionadas ao Linux como parte de seu trabalho. +* As contribuições de código no upstream de um Engenheiro de Software serão + consideradas em promoções e avaliações de desempenho. + +Nível 3 +======= + +* Espera-se que os Engenheiros de Software revisem patches (incluindo patches + escritos por engenheiros de outras empresas) como parte de suas + responsabilidades de trabalho. +* A contribuição com apresentações ou artigos para conferências acadêmicas ou + relacionadas ao Linux (como as organizadas pela Linux Foundation, Usenix, + ACM, etc.) é considerada parte do trabalho do engenheiro. +* As contribuições comunitárias de um Engenheiro de Software serão consideradas + em promoções e avaliações de desempenho. +* As organizações relatarão regularmente as métricas de suas contribuições em + open source e acompanharão essas métricas ao longo do tempo. Essas métricas + podem ser publicadas apenas internamente na organização ou, a critério da + organização, algumas ou todas podem ser publicadas externamente. As métricas + fortemente sugeridas incluem: + + * O número de contribuições ao kernel no upstream por equipe ou organização + (por exemplo, todas as pessoas que se reportam a um gerente, diretor ou + vice-presidente). + * A porcentagem de desenvolvedores de kernel que fizeram contribuições no + upstream em relação ao total de desenvolvedores de kernel na organização. + * O intervalo de tempo entre os kernels usados nos servidores e/ou produtos + da organização e a data de publicação do kernel upstream no qual o kernel + interno se baseia. + * O número de commits fora da árvore (out-of-tree) presentes nos kernels + internos. + +Nível 4 +======= + +* Os Engenheiros de Software são incentivados a dedicar uma parte do seu tempo + de trabalho focados no Trabalho no Upstream, o qual é definido como a revisão + de patches, atuação em comitês de programa, melhoria da infraestrutura central + do projeto -- como escrita ou manutenção de testes, redução de dívida técnica + no upstream, escrita de documentação, etc. +* Os Engenheiros de Software recebem apoio para ajudar a organizar conferências + relacionadas ao Linux. +* As organizações considerarão o feedback dos membros da comunidade em + avaliações de desempenho oficiais. + +Nível 5 +======= + +* O desenvolvimento de kernel no upstream é considerado um cargo formal, com + pelo menos um terço do tempo do engenheiro dedicado à realização de Trabalho + no Upstream. +* As organizações buscarão ativamente o feedback dos membros da comunidade como + um fator nas avaliações de desempenho oficiais. +* As organizações relatarão internamente e de forma regular a proporção entre o + Trabalho no Upstream e o trabalho focado em atingir diretamente os objetivos + de negócios. \ No newline at end of file