Solicitudes de incorporación de cambios: MRTK2

Requisitos previos

Si no ha contribuido a un proyecto de Microsoft antes, es posible que se le pida que firme un contrato de licencia de contribución. Un comentario en la solicitud de incorporación de cambios le permitirá saber si lo hace.

Importante

Si es empleado de Microsoft y no es miembro de la organización de Microsoft en GitHub, vincule sus cuentas de Microsoft y GitHub en corpnet visitando Código abierto en Microsoft antes de iniciar la solicitud de incorporación de cambios. Hay algunas cosas de proceso que tendrá que hacer antes de tiempo.

Creación de una solicitud de incorporación de cambios

Cuando esté listo para enviar una solicitud de incorporación de cambios, cree una solicitud de incorporación de cambios destinada a la rama principal . Para ver las correcciones de errores durante un período de estabilización de versión, busque la rama más reciente prerelease/* . Las nuevas características siempre deben entrar en main.

Lea las directrices y asegúrese de que la solicitud de incorporación de cambios cumple las directrices.

• Asegúrese de hacer referencia a cualquier problema o solicitud de característica o tarea a la que esté relacionada la solicitud de incorporación de cambios.
• Compruebe que la solicitud de incorporación de cambios solo contiene archivos o cambios relacionados con la solicitud de incorporación de cambios.
• Compruebe que la documentación está actualizada e incluida. Compruebe que todos los campos públicos tengan comentarios.
• Si agrega una nueva característica, compruebe que se incluyen pruebas para validar la característica (consulte UnitTests).
• Si corrige un error, escriba una prueba para comprobar la corrección del error.

Los mantenedores del proyecto revisarán los cambios. Nuestro objetivo es revisar todos los cambios en un plazo de tres días laborables. Por favor, solucione cualquier comentario de revisión, inserte en la rama de tema y publique un comentario que nos permita saber que hay cosas nuevas que revisar.

Nota:

Todas las solicitudes de incorporación de cambios enviadas al proyecto también se examinarán de acuerdo con la guía de estándares de codificación de MRTK, por lo que debe revisarlas antes de enviar su solicitud de incorporación de cambios para garantizar un proceso sin problemas.

Directrices de solicitud de incorporación de cambios

Estas directrices se basan en las prácticas de ingeniería de Google.

Mantener pequeñas las solicitudes de incorporación de cambios

Las solicitudes de incorporación de cambios más pequeñas se revisan de forma más rápida y exhaustiva, es menos probable que introduzcan errores, que sean más fáciles de revertir y que sean más fáciles de combinar.

Las solicitudes de incorporación de cambios deben ser lo suficientemente pequeñas como para que un ingeniero pueda revisarlas en menos de 30 minutos. Intente realizar un cambio mínimo que aborde solo una cosa. Si debe crear una solicitud de incorporación de cambios grande, divídala en varias solicitudes de incorporación de cambios que se incluyan en la rama local o en una rama de características de MRTK. Evite agregar nuevos recursos (por ejemplo, archivos fbx, obj) y, en su lugar, intente volver a usar los recursos existentes.

Las pruebas deben agregarse en la misma solicitud de incorporación de cambios que la corrección o característica, excepto en caso de emergencias.

Las pruebas son la mejor manera de asegurarse de que los cambios no vuelven a retroceder el código existente, pero también es fácil olvidarse de las pruebas al enviar solicitudes de incorporación de cambios. Requerir que entren con la solicitud de incorporación de cambios son una excelente manera de garantizar que las pruebas se escriban.

Cada característica y corrección de errores deben tener pruebas asociadas. Si no tiene la experiencia ni el tiempo necesario para escribir una prueba, cree un problema para escribir las pruebas y marcarlas con la etiqueta Considerar para iteración actual.

La documentación debe agregarse en la misma solicitud de incorporación de cambios que una corrección o característica

La mayoría de los desarrolladores examinan primero la documentación, no el código, al comprender cómo usar una característica. Asegurarse de que la documentación está actualizada facilita mucho el consumo y la confianza de MRTK. La documentación siempre debe agruparse con la extracción relacionada para garantizar que los elementos permanezcan actualizados y coherentes.

Asegúrese de que cada campo público, método, propiedad tiene comentarios de resumen de barra diagonal triple para que nuestro sitio docfx pueda generar descripciones para campos o métodos. Si es necesario, actualice los archivos markdown en la carpeta Documentación.

Las descripciones de solicitudes de incorporación de cambios deben describir los cambios de forma clara y completa.

Las descripciones claras y completas de las solicitudes de incorporación de cambios garantizan que los revisores comprendan lo que están revisando.

Si agrega características que contienen experiencia de usuario, agregue una imagen o un gif de la característica que va a cambiar. Este es un buen ejemplo. Otra sugerencia es tener un gif de Before y After, por ejemplo, en esta solicitud de incorporación de cambios. Una herramienta que se recomienda para generar gifs a partir de capturas de pantalla es ScreenToGif.