Compartir a través de

Gestión de solicitudes de incorporación de cambios

En este artículo se documenta cómo se administran las solicitudes de incorporación de cambios en el repositorio de PowerShell-Docs. Este artículo está diseñado para ser una ayuda laboral para los miembros del equipo de PowerShell-Docs. Publicamos esta información aquí para proporcionar transparencia del proceso a nuestros colaboradores públicos.

procedimientos recomendados

  • Solicite una revisión. La persona que envía la solicitud de incorporación de cambios no debe fusionar la solicitud de incorporación de cambios sin una revisión por pares.
  • Asigne al revisor cuando se envíe el PR. La asignación temprana permite al revisor responder antes con comentarios editoriales.
  • Usa comentarios para describir la naturaleza del cambio que se va a enviar. Por ejemplo, si el cambio es menor, explique el cambio y que no necesita una revisión técnica completa. Asegúrese de que @mention el revisor.
  • Use la característica de sugerencia de comentario para facilitar al autor aceptar el cambio sugerido. Para obtener más información, consulte Revisión de los cambios propuestos en una solicitud de incorporación de cambios.

Pasos para el proceso de PR

  1. Escritor: Crear PR
    • Rellene la plantilla PR
    • Vincula cualquier problema resuelto por el PR
    • Uso de la característica de cierre automático de GitHub para cerrar el problema
    • Revisar y desactivar cada elemento de la lista de comprobación
  2. Escritor: Asignar revisor de pares
  3. Revisor: revisión y comentarios (según sea necesario)
  4. Escritor: Incorporación de comentarios de revisión
  5. Ambos: Revisión de la representación en versión preliminar
  6. Ambos: Revisión del informe de validación: corrección de advertencias y errores
  7. Revisor: Marcar la revisión "Aprobada"
  8. Mantenedor de repositorios: Fusión de RP

Lista de comprobación del revisor de contenido

Consulte la lista de comprobación editorial para obtener una lista más completa.

  • Revisión de gramática, estilo, concisión, precisión técnica
  • Asegúrese de que los ejemplos se siguen aplicando para la versión de destino
  • Comprobación de la representación en versión preliminar
  • Compruebe los metadatos: ms.date, quite ms.assetid y asegúrese de que los campos necesarios estén completos.
  • Validar la corrección de Markdown
    • Consulte la guía de estilo para obtener reglas de formato específicas del contenido.
  • Reorganiza los ejemplos de la manera siguiente:
    • Párrafo de introducción
    • Código y salida
    • Explicación detallada del código (según sea necesario)
  • Comprobación de la precisión de los hipervínculos
    • Reemplazar o quitar vínculos de TechNet/MSDN
    • Asegurar el número mínimo de redireccionamientos al destino
    • Asegurar HTTPS
    • Tipo de vínculo correcto
      • Vínculos de archivos para archivos locales
      • Vínculos url para archivos fuera del conjunto de documentos
    • Eliminar regiones de las direcciones URL
    • Simplificación de las direcciones URL que apuntan a learn.microsoft.com
  • Verificar que el contenido versionado sea correcto en todas las ediciones.

Proceso de combinación de ramas

La main rama es la única rama que se debe combinar en live. Las fusiones de ramas de corta duración (de trabajo) se deben comprimir antes de integrarse en main.

Combinar desde/hasta release-branch principal en directo
rama de trabajo squash y fusionar squash y fusionar No permitida
release-branch — fusionar No permitida
principal fusionar mediante cambio de base — fusionar

Lista de comprobación de fusión de PR

  • Revisión de contenido completada
  • Rama de destino correcta para el cambio
  • No hay conflictos de combinación
  • Todos los pasos de validación y compilación se completan exitosamente.
    • Las advertencias y sugerencias deben corregirse (consulte Notas para las excepciones).
    • No hay vínculos rotos
    • La acción Lista de comprobación se ejecutó y pasó
    • Si se desencadenó una comprobación de autorización, ha sido aprobada.
  • Combinar según la tabla

Notas

Se pueden omitir las advertencias siguientes:

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.

Cuando se combina una solicitud de incorporación de cambios, se cambia el encabezado de la rama de destino. Las solicitudes de incorporación de cambios abiertas que se basaban en el HEAD anterior ahora están obsoletas. Un mantenedor tiene el derecho necesario para ignorar las advertencias de fusión y fusionar la solicitud de incorporación de cambios obsoleta en GitHub. La combinación de una solicitud de incorporación de cambios obsoleta es segura si las solicitudes de incorporación de cambios combinadas anteriormente no tocaron los mismos archivos.

Para actualizar la solicitud, seleccione el botón Actualizar rama. Elija la opción Actualizar con rebase . Para obtener más información, consulte Actualización de la rama de solicitud de incorporación de cambios.

Publicación en directo

Periódicamente, los cambios acumulados en la main rama deben publicarse en el sitio web activo.

  • La rama main se fusiona a live cada día laborable a las 15:00, hora estándar del Pacífico (PST).
  • La main rama debe combinarse a live después de cualquier cambio significativo.
    • Cambios en 50 o más archivos
    • Después de fusionar una rama de lanzamiento
    • Cambios en configuraciones de repositorio o conjunto de documentos (docfx.json, configuraciones de OPS, scripts de compilación, etc.)
    • Cambios en el archivo de redirección
    • Cambios en el TOC
    • Después de combinar una rama "proyecto" (reorganización de contenido, actualización masiva de datos, etc.)
  • Last updated on