Estándares, Gobernanza y Mejores Prácticas Comunitarias

Hábitos de aprendizaje continuo para ingenieros senior de Go.

Estas reglas convierten la señal comunitaria y el conocimiento de gobernanza en prácticas de equipo que puedes auditar en retrospectivas, no en conocimiento tribal.

Cómo Usar Esta Lista

• Marca los elementos durante las revisiones trimestrales de la plataforma o después de cada lanzamiento menor de Go.
• Asigna propietarios de categorías: personal para propuestas, plataforma para dependencias, líderes para documentación de estándares.
• Empareja los elementos no marcados con tickets que enlacen a las páginas de sección para obtener el razonamiento.
• Exporta un resumen a los gerentes de ingeniería como evidencia de la salud de la cadena de herramientas.

A - Fuentes oficiales y alfabetización

• Marca go.dev, pkg.go.dev y la versión actual de doc/go1.N. Los ingenieros no deben buscar en blogs aleatorios para preguntas sobre especificaciones.
• Revisa las notas de la versión antes de aprobar las actualizaciones de la imagen de Go. Las secciones de tiempo de ejecución y vet vienen antes que los resaltados de sintaxis.
• Suscríbete al RSS del blog de Go o delega a un autor de resúmenes semanales. La justificación del diseño llega aquí primero.
• Cita enlaces versionados de pkg.go.dev en los ADRs. Los lectores futuros deben saber qué API revisaste.
• Ejecuta govulncheck en cada cambio de módulo. La señal de CVE es parte de la gobernanza, no extras de seguridad opcionales.
• Enseña a los nuevos empleados el índice de estándares en la primera semana. Señala el wiki interno más Conceptos Básicos de Comunidad y Gobernanza.

B - Comunidad y propuestas

• Mantén una lista de vigilancia de propuestas para los paquetes que estandarizas. gh issue list semanal supera los cambios sorpresa en la biblioteca estándar.
• Comenta en las propuestas solo con repros y análisis de compatibilidad. Los comentarios de "+1" desperdician el tiempo del revisor.
• Archiva los RFCs internos cuando las propuestas se rechacen. Enlaza el problema de GitHub para detener debates recurrentes.
• Ejecuta un gremio mensual: una charla de conferencia + un ejercicio de repositorio. Los videos solos no cambian el código.
• Apoya la preparación de charlas de meetups o internas para ingenieros de nivel medio. Enseñar construye la misma claridad que los ADRs.
• Separa la inspiración de la conferencia de los compromisos de la hoja de ruta. Las ideas de pasillo aún necesitan prueba de propuesta o nota de versión.

C - Estándares del equipo y documentación

• Aplica gofmt y golangci-lint en CI, no en discusiones de revisión. Los revisores enseñan el juicio que los linters no pueden codificar.
• Requiere godoc en símbolos exportados que comiencen con el nombre. pkg.go.dev es tu superficie de API externa.
• Documenta //nolint con el ID de regla y la referencia del ADR. Las supresiones silenciosas se convierten en deuda permanente.
• Mantén la hoja de trucos de estándares de codificación junto a la configuración del linter. La deriva entre la documentación y .golangci.yml confunde a los nuevos empleados.
• Registra cambios de API que rompen en las actualizaciones mayores de módulos o en paquetes solo internos. Las promesas de compatibilidad sobreviven a los sprints.
• Refleja las adiciones de vet upstream dentro de un sprint de la actualización. Luchar contra nuevos analizadores desperdicia ciclos de revisión.

D - Gobernanza de dependencias y licencias

• Trata las nuevas líneas require como cambios controlados. Lista blanca de YAML o CODEOWNERS en go.mod.
• Escanea las licencias en versiones fijadas, no en la rama principal flotante. La pestaña de licencias de pkg.go.dev es el primer pase, el equipo legal confirma.
• Bloquea clases SPDX DESCONOCIDAS o prohibidas en CI. Los archivos LICENSE faltantes detienen el envío para paquetes SaaS.
• Usa días de estabilidad de Renovate y pruebas posteriores a la actualización. -race en módulos críticos detecta regresiones upstream.
• Documenta cada directiva replace con una fecha de caducidad en un ADR. Las bifurcaciones son cirugía, no conveniencia casual.
• Audita los gráficos indirectos trimestralmente. El riesgo se esconde a dos saltos de tus importaciones directas.

E - Preparación para el futuro y actualizaciones

• Inventaría GOEXPERIMENT y GODEBUG por servicio. Las anulaciones necesitan propietarios y trimestres de puesta a punto en los ADRs.
• Ejecuta go fix antes de fusionar las actualizaciones de directivas de Go. Los modernizadores alinean el código con las nuevas expectativas de vet.
• Canaliza los valores predeterminados del tiempo de ejecución con comandos de reversión documentados. El GC de Green Tea y los cambios de TLS afectan el p99 silenciosamente.
• Rastrea las deprecaciones mencionadas en las notas de la versión en un YAML compartido. Vincula los símbolos a los propietarios de migración.
• Elimina las claves de reversión antes del objetivo de eliminación de godebug. Los hacks permanentes del entorno se convierten en cebo para incidentes.
• Actualiza secuencialmente a través de las versiones menores compatibles cuando sea posible. Las notas omitidas acumulan sorpresas de compatibilidad.

Preguntas Frecuentes

Relacionado

• Comunidad de Go y Artesanía a Largo Plazo - explicador sobre la artesanía sostenida de SME
• Conceptos Básicos de Comunidad y Gobernanza - ejemplos de incorporación ejecutables
• Estándares de Codificación y Convenciones de Documentación para Equipos - referencia de estilo aplicable
• Gobernanza de Dependencias y Cumplimiento de Licencias - tablas de políticas de módulos
• Preparación para el Futuro: Propuestas, Experimentos y Hoja de Ruta - patrones de inventario de experimentos

Versiones de Stack: Esta página fue escrita para Go 1.26.x (predeterminado Green Tea GC, modernizadores go fix - verifica el parche en la compilación), chi (última versión - verifica en la compilación), gin (última versión - verifica en la compilación), echo (última versión - verifica en la compilación), google.golang.org/grpc (última versión - verifica en la compilación), sigs.k8s.io/controller-runtime (última versión - verifica en la compilación), kubebuilder (última versión - verifica en la compilación), tinygo (última versión - verifica los objetivos de la placa en la compilación), wazero (última versión - verifica en la compilación) y golangci-lint (última versión - verifica el conjunto de linters en la compilación).