Partilhar via

Gerenciando solicitações pull

Este artigo documenta como gerenciamos solicitações pull no repositório PowerShell-Docs. Este artigo foi concebido para ser uma ajuda de emprego para os membros da equipa PowerShell-Docs. Publicamos essas informações aqui para fornecer transparência ao processo para nossos colaboradores públicos.

Melhores práticas

  • Solicite uma revisão. A pessoa que envia o PR não deve fundir o PR sem uma revisão por pares.
  • Atribua o revisor por pares quando o PR for enviado. A atribuição antecipada permite que o revisor responda mais cedo com comentários editoriais.
  • Use comentários para descrever a natureza da alteração que está sendo enviada. Por exemplo, se a alteração for menor, explique a alteração e que você não precisa de uma revisão técnica completa. Certifique-se de @mention o revisor.
  • Use o recurso de sugestão de comentário para facilitar a aceitação da alteração sugerida pelo autor. Para obter mais informações, consulte Revisão de alterações propostas em uma solicitação pull.

Etapas do processo de RP

  1. Escritor: Criar Relações Públicas
    • Preencha o modelo de RP
    • Vincular quaisquer questões resolvidas pelo PR
    • Use o recurso de fechamento automático do GitHub para fechar o problema
    • Percorra e assinale cada item da lista de verificação
  2. Escritor: Atribuir revisor de pares
  3. Revisor: revisões e comentários (conforme necessário)
  4. Redator: incorpore o feedback das avaliações
  5. Ambos: Rever a renderização da antevisão
  6. Ambos: Rever relatório de validação - corrigir Avisos e Erros
  7. Revisor: Marcar avaliação "Aprovado"
  8. Mantenedor de Repo: Merge PR

Lista de verificação do revisor de conteúdo

Consulte a lista de verificação editorial para obter uma lista mais abrangente.

  • Revisão de gramática, estilo, concisão e precisão técnica
  • Garantir que os exemplos ainda se apliquem à versão de destino
  • Verifique a visualização da renderização
  • Verifique metadados - ms.date, remova ms.assetid, verifique os campos obrigatórios
  • Validar a correção da marcação
    • Consulte o guia de estilo para obter regras de formatação específicas do conteúdo
  • Reorganize os exemplos da seguinte forma:
    • Parágrafo introdutório
    • Código e saída
    • Explicação detalhada do código (conforme necessário)
  • Verifique a precisão dos hiperlinks
    • Substituir ou remover links do TechNet/MSDN
    • Garantir o número mínimo de redirecionamentos para o destino
    • Garantir HTTPS
    • Tipo de link correto
      • Links de arquivo para arquivos locais
      • Links de URL para arquivos fora do docset
    • Remover localizações de URLs
    • Simplifique URLs apontando para learn.microsoft.com
  • Verifique se o conteúdo versionado está correto em todas as versões

Processo de mesclagem de filiais

A main sucursal é a única sucursal que deve ser incorporada no live. As fusões de ramos de curta duração (em funcionamento) devem ser esmagadas antes da fusão em main.

Mesclar de/para ramificação de lançamento Principal viver
ramo de trabalho aglutinar e fundir aglutinar e fundir Não permitido
ramificação de lançamento — unir Não permitido
Principal incorporar alterações (rebase) — unir

Lista de verificação de fusões PR

  • Revisão de conteúdo concluída
  • Ramificação de destino correta para a alteração
  • Sem conflitos de mesclagem
  • Todos os passos de validação e construção
    • Avisos e sugestões devem ser corrigidos (consulte Notas para exceções)
    • Sem links quebrados
    • A ação Lista de verificação foi executada e aprovada
    • Se uma verificação de autorização foi acionada, ela foi aprovada
  • Mesclar de acordo com a tabela

Observações

Os seguintes avisos podem ser ignorados:

Can't find service name for `<version>/<modulepath>/About/About.md`

Metadata with following name(s) are not allowed to be set in YAML header, or as file level
metadata in docfx.json, or as global metadata in docfx.json: `locale`. They are generated by
Docs platform, so the values set in these 3 places will be ignored. Please remove them from all
3 places to resolve the warning.

Quando um PR é mesclado, o HEAD da ramificação de destino é alterado. Todas as RPs abertas que se baseavam no HEAD anterior estão agora desatualizadas. Um mantenedor tem a permissão necessária para ignorar os avisos de mesclagem e mesclar PRs desatualizados no GitHub. Integrar um pull request desatualizado é seguro se os pull requests anteriormente integrados não afetaram os mesmos arquivos.

Para atualizar a RP, selecione o botão Atualizar ramificação . Escolha a opção Atualizar com rebase . Para obter mais informações, consulte Atualizando sua ramificação de solicitação pull.

Publicação ao vivo

Periodicamente, as alterações acumuladas main no ramo precisam ser publicadas no site ao vivo.

  • O main ramo é integrado em live todos os dias úteis às 15h, horário de PST.
  • A main sucursal deve ser incorporada ao live após qualquer alteração significativa.
    • Alterações em 50 ou mais ficheiros
    • Depois de integrar uma ramificação de lançamento
    • Alterações nas configurações de repositório ou docset (docfx.json, configurações de OPS, scripts de construção, etc.)
    • Alterações no arquivo de redirecionamento
    • Alterações ao sumário
    • Depois de fundir uma ramificação de "projeto" (reorganização de conteúdo, atualização em massa, etc.)
  • Last updated on