Information: Período de revisão de PRs de código

Também fiquei com a impressão de que o processo foi escrito tendo em mente os repos centrados na comunidade, ou seja, PRs mais próximos das mudanças organizacionais.

Concordo, o código pode ser visto como a implementação de regras que mudam a forma como a organização funciona, mas essas restrições rígidas sobre como codificamos não serão factíveis. Ele irá travar o desenvolvimento a uma parada prática.

Talvez tornar o processo mais claro sobre isso, para que não seja aplicado em PRs de código?

O mais rápido possível? Então, o ideal seria mesclar instantaneamente depois de abrir uma solicitação de pull ou um problema? Precisamos de uma janela para o diálogo?

Eu diria que instantaneamente está além do que é possível. :-) Precisamos permitir que os revisores façam uma revisão informada, mas como eles já precisam de tempo para fazer isso, e nenhuma mesclagem acontece antes que eles tenham feito isso, "instantaneamente" é meramente hipotético.

Portanto, não concordo inteiramente com @megoth , que simplesmente não podemos fazer com que o processo se aplique ao código, pois há alterações no código que são controversas.

No entanto, também vale a pena notar que o objetivo de usar um sistema de revisão é que as alterações de código não são irreversíveis. Não é antes de uma mudança de código chegar a uma versão completa que a reversão é realmente um grande negócio, e isso leva ainda mais tempo.

Eu acho que a linha de fundo aqui é que realmente não pode haver uma regra rígida para quanto tempo cada PR (seja para código ou não) deve ser mantido antes de ser mesclado.

Muitas alterações de código e muitas alterações de documentação voltadas para humanos não serão controversas, e não há razão para forçar um atraso de 14 dias ou 3 dias ou até 3 horas entre o envio do PR e a mesclagem em algo como "corrigido erro de digitação , hiperlink para hiperlink"...

Os PRs geralmente devem ser revisados ​​por alguém(s) familiarizado(s) com as coisas que estão sendo alteradas -- seja código ou não. Parece razoável dizer algo como "w OU ((x e/ou y) E z) revisará todos os PRs para este repositório/arquivo/qualquer coisa" -- o prazo das revisões pode variar de acordo com a carga de trabalho do(s) revisor(es) do momento, bem como o alvo PR!

Mudanças potencialmente controversas - de qualquer tipo - devem ser notadas como tal por esses revisores, que devem ser confiáveis ​​para solicitar uma revisão mais ampla, incluindo potencialmente "superiores" de qualquer tipo.

A razão pela qual eu optaria por um período fixo é que houve conversas sobre 1) problemas e solicitações pull que não foram tratadas com rapidez suficiente 2) questões e solicitações pull não foram publicadas o suficiente para dar uma chance de dar entrada e a legitimidade de sugestões sendo questionadas como resultado. Não escrevê-lo explicitamente significa que as pessoas que trabalham no Solid há muito tempo têm uma vantagem sobre os recém-chegados que precisam adivinhar as regras tácitas de engajamento que tornam a adesão à comunidade não um ambiente aberto e transparente.

Como solução, devemos dizer que há um período de 3 dias para que todos os pull requests e problemas sejam tratados uma vez publicados?

Eu ainda tenho um problema com ele como uma solução "tamanho único". Eu acho que terá vários efeitos prejudiciais para a qualidade do código e o progresso do projeto.

Em primeiro lugar, não há regras tácitas de engajamento que não existam há pelo menos cinco anos , e é uma prática muito comum em milhares e milhares de projetos. Portanto, se você é completamente novo no desenvolvimento em geral, estará em desvantagem, mas isso não se deve a nada em particular com o Solid, sempre há uma curva de aprendizado envolvida ao entrar em um novo campo de atuação. Como eu disse, para mim é importante que o Solid tenha um limite de entrada muito baixo, mas não tenho certeza se o desenvolvimento de servidores é onde as pessoas deveriam começar a desenvolver suas habilidades, ambientes onde não precisariam cooperar estreitamente com outros desenvolvedores na mesma base de código provavelmente são mais adequados para eles.

Muitos, se não a maioria, dos PRs terão naturalmente um período de revisão de mais de três dias, limitado pela disponibilidade dos revisores. No entanto, também estamos naturalmente nos esforçando para obter PRs relativamente pequenos e fáceis de revisar. É uma boa prática fazer isso, para que você obtenha feedback antecipado e não seja muito difícil para os revisores. No entanto, isso geralmente significa que resolver uma tarefa maior envolverá vários PRs incrementais. Se cada PR exigir um período de revisão de três dias, isso retardará significativamente o desenvolvimento. Se essa for a política, suspeito que nós, como desenvolvedores, acabaríamos não escrevendo PRs pequenos, mas sim fazendo um PR grande para que você não precisasse esperar por um período de revisão de três dias para cada um.

Isso resultaria em PRs maiores que são mais difíceis de revisar, um afastamento do desenvolvimento ágil e um maior risco de erros passarão pelo processo de revisão.

Eu estaria muito interessado em ouvir o que outros projetos maiores estão fazendo a esse respeito, mas para mim, uma abordagem de tamanho único não é desejável nem alcançável.

É difícil para mim dizer isso, já que sou um gerente de lançamento, mas acho que @TallTed daria suporte a isso, o processo deve ficar a critério do gerente de lançamento. O gerente de versão deve certificar-se de que os revisores mais adequados sejam solicitados, que um número adequado de revisores seja solicitado dependendo do problema e que as mesclagens não ocorram antes que o número certo de revisores tenha respondido com uma aprovação. não acontecer se houver alterações solicitadas, se as ramificações corretas estiverem bloqueadas para impor o processo de revisão, se PRs potencialmente contenciosos forem trazidos, por exemplo, à atenção do Líder da Comunidade por meio de algum meio de notificação e, de fato, outros revisores são certamente muito bem-vindos para fazer isso também.

Só queria incluir as notas da conversa da reunião de suporte da comunidade. Esses pontos foram levantados por diferentes pessoas dentro do Solid Team:

• O período de revisão de 3 dias pode retardar o trabalho sólido.
• Qual é o benefício prático de um período de tempo? O benefício prático seria criar um ambiente inclusivo mais aberto com processo de tomada de decisão transparente que possa ser entendido e referido.
• qual é o problema que estamos tentando resolver? Existem outras formas de resolver? O que estamos realmente tentando resolver é que existem restrições quando as mudanças são feitas e eles não tiveram a oportunidade de fornecer sua perspectiva. O limite de tempo é uma forma de dar oportunidade. Outra abordagem para convidar à inclusão é garantir que as sugestões sejam postadas em um ambiente que as pessoas possam verificar, por exemplo, sólidos/sugestões.
  – A discriminação é um efeito colateral e não a raiz.
• Onde está a linha entre inclusão e eficiência? Do-ocracia você precisa deixar as pessoas que fazem as coisas decidirem. Ter pouca autonomia é outro extremo ao qual não devemos ir. Metocracia – do-ocracia. A implementação desses ideais pode ser tóxica para as minorias.

• Vamos tentar estar na vanguarda. O que podemos aprender com os erros. Não vamos fazer tudo como antes, vamos refletir sobre o porquê de estarmos fazendo o que estamos fazendo. Trabalhe na tradução das especificações em linguagem natural. Especialmente quando as especificações estão evoluindo, é difícil mantê-las atualizadas. Pode ser muito longo e mais fácil para as pessoas lerem, pode ser demais para mastigar. Propondo tentar encontrar tópicos dentro da especificação. Encontre maneiras de distribuir maneiras de olhar para a especificação. Escreva mais tutoriais, para resolver vários problemas. Também há espaço para postagens no blog explicando os elementos da especificação. Torná-lo em petiscos mastigáveis.

• Podemos remover commits, eles são reversíveis, no entanto, a reversão é prática? Reverter o commit da comunidade é lento, então levará ainda mais tempo para reverter. Mais difícil de reverter no servidor porque os itens são construídos em cima de decisões anteriores.

• Não estamos fazendo nada diferente de outro projeto. Embora definir um período de tempo seja diferente das práticas anteriores, o que estamos tentando fazer é construir um modelo diferente, e os modelos anteriores foram dominados por um grupo homogêneo, então queremos usar práticas anteriores ou nos esforçar para estar no limite de pensamento? Poderíamos aprender com exemplos anteriores como não cair nas mesmas armadilhas e analisar o que funcionou? Estamos prometendo ser diferentes – o que funcionou no passado não funcionou.

• Poderíamos diferenciar entre os repos? Se sim, como?

• O código é diferente das regras? O servidor sólido do nó tem um impacto na sociedade, assim como o repositório da comunidade e a especificação Solid. Então como diferenciar? Difícil avaliar o que terá impacto na sociedade, principalmente quando os profissionais que fazem essa avaliação não podem acessar as informações porque não estão em uma linguagem que possam interpretar.
• O servidor sólido é um software normativo que tem um enorme impacto na sociedade, portanto, as decisões de código têm um grande impacto.
• Os pull requests individuais são pequenos pedaços de mudanças, que não possuem essa propriedade. Eles estão lá apenas para tornar as mudanças incrementais para envolver nossas mentes em torno disso. Não é o mesmo que uma mudança social porque eles são qualitativamente e quantitativamente diferentes.
• Os três repositórios de especificações e o repositório da comunidade devem ter processos mais rígidos, por exemplo, com um período mínimo de revisão definido e revisor alocado. A especificação tem o grande efeito normativo. Boa maneira de distinguir os repos pelo efeito normativo que podem ter em geral. O repositório da comunidade e as especificações sólidas estão nessa categoria. Então seria bom ter uma mesclagem transparente.

• Poderia ter uma regra híbrida definida para node-solid-server dizendo que se a mudança se desviar da especificação, ela precisa de um tempo de revisão mais longo. Os casos em que implementamos as especificações no código que se desviam da especificação também são importantes para se ter um processo.

• O fluxo de trabalho e as etapas não são documentados.

• Engenheiros confiam mais em um pipeline do que não engenheiros. Talvez estejamos confiando nisso. Talvez haja um ponto. Demografia da cultura do desenvolvedor, talvez seja porque achamos que é assim que deveria ser.
• As decisões-chave são disfarçadas de técnicas quando, na verdade, têm implicações massivas além das técnicas.
• O código pode ter um tremendo impacto na sociedade, tão importante para entender o impacto e permitir que as pessoas participem.
• Linguagem natural – as especificações podem usar alguma atualização em qualquer caso. Ao fazer isso, há uma maneira melhor de explicar a coisa. Não iria tão longe a ponto de reescrever elementos técnicos como não técnicos. Há oportunidade de melhorar a legibilidade da especificação para garantir que ela esteja correta. Vai ter muito empurrão de volta dizendo que o técnico será retirado.
  
  
  
  • Precisamos construir coisas que sejam aceitas e, portanto, precisam ser compreendidas por todos.
  
  

@TallTed você tem alguma opinião sobre a ata da reunião no comentário anterior?

Como caminho a seguir, proponho o seguinte:

As solicitações pull e os problemas associados aos seguintes repositórios precisam estar abertos por no mínimo três dias:
https://github.com/solid/solid-spec
https://github.com/solid/web-access-control-spec
https://github.com/solid/webid-oidc-spec
https://github.com/solid/community

As solicitações pull e problemas associados a todos os outros repositórios podem ser encerrados imediatamente e não têm um tempo mínimo para ficarem abertos, a menos que se desviem da especificação, caso em que precisam ficar abertos por no mínimo três dias.

Alguma objeção?

Funciona para mim. Também é possível adicionar texto à descrição do papel do Release Manager, descrevendo o que ele deve fazer com os repositórios restantes.

Eu também gosto desta solução :smile_cat: Vamos escrever o raciocínio em algum lugar também, para que as pessoas entendam nosso pensamento por trás disso

@kjetilk Sim, adicionarei uma nota a https://github.com/solid/community/pull/44

@megoth ok incluirá uma breve descrição no readme do repositório da comunidade

https://github.com/solid/community/blob/master/README.md