Information: Período de revisión de los PR del código

También tuve la impresión de que el proceso se escribió teniendo en cuenta los repositorios centrados en la comunidad, es decir, los RP más cercanos a los cambios organizacionales.

De acuerdo, el código puede verse como la implementación de reglas que cambian la forma en que funciona la organización, pero las restricciones estrictas sobre cómo codificamos no serán factibles. Detendrá el desarrollo hasta una práctica parada.

¿Tal vez hacer que el proceso sea más claro en esto, para que no se aplique en los PR de código?

¿Tan rápido como sea posible? Entonces, ¿idealmente se fusionaría instantáneamente después de abrir una solicitud de extracción o un problema? ¿Necesitamos una ventana para el diálogo?

Yo diría que instantáneamente está más allá de lo que es posible. :-) Necesitamos permitir que los revisores hagan una revisión informada, pero dado que ya necesitan tiempo para hacerlo, y no ocurre ninguna fusión antes de que la hayan hecho, "al instante" es meramente hipotético.

Por lo tanto, no estoy del todo de acuerdo con @megoth , que simplemente no podemos hacer que el proceso se aplique al código, ya que hay cambios de código que son polémicos.

Sin embargo, también vale la pena señalar que el objetivo de usar un sistema de revisión es que los cambios de código no son irreversibles. No es antes de que un cambio de código haya llegado a una versión completa que la reversión es realmente tan importante, y eso lleva aún más tiempo.

Creo que la conclusión aquí es que realmente no puede haber una regla estricta sobre cuánto tiempo debe mantenerse cada PR (ya sea para el código o de otro modo) antes de fusionarse.

Muchos cambios de código y muchos cambios de documentación de cara a humanos no serán controvertidos, y no hay razón para forzar un retraso de 14 días o 3 días o incluso 3 horas entre el envío de relaciones públicas y la fusión en algo como "error tipográfico corregido". , hipervínculo a hipervínculo"...

Por lo general, las relaciones públicas deben ser revisadas por alguien que esté familiarizado con las cosas que se están modificando, ya sea código o no. Parece razonable decir algo como "w OR ((x y/or y) AND z) revisará todos los PR para este repositorio/archivo/lo que sea" -- el marco de tiempo de las revisiones puede variar con la carga de trabajo de los revisores. del momento, así como el objetivo de relaciones públicas!

Los cambios potencialmente polémicos, de cualquier tipo, deben ser notados como tales por esos revisores, en quienes se debe confiar para solicitar una revisión más amplia, que podría incluir "superiores" de cualquier tipo.

La razón por la que optaría por un período fijo es que ha habido conversaciones sobre 1) problemas y solicitudes de extracción que no se tratan con la suficiente rapidez 2) problemas y solicitudes de extracción que no se publican lo suficiente como para dar la oportunidad de dar su opinión y la legitimidad de sugerencias siendo cuestionadas como resultado. No escribirlo explícitamente significa que las personas que trabajan en Solid durante mucho tiempo tienen una ventaja sobre los recién llegados que tienen que adivinar las reglas tácitas de compromiso que hacen que unirse a la comunidad no sea un entorno abierto y transparente.

Como solución, ¿debemos decir que hay un período de 3 días para que todas las solicitudes de extracción y los problemas se manejen una vez publicados?

Todavía tengo un problema con él como una solución de "talla única". Creo que tendrá varios efectos perjudiciales para la calidad del código y el progreso del proyecto.

En primer lugar, no hay reglas de compromiso implícitas que no hayan existido durante al menos cinco años , y es una práctica muy común en miles y miles de proyectos. Entonces, por supuesto, si es completamente nuevo en el desarrollo en general, estará en desventaja, pero eso no se debe a nada en particular con Solid, siempre hay una curva de aprendizaje involucrada al ingresar a un nuevo campo de actividad. Como he dicho, para mí es importante que Solid tenga un umbral de entrada muy bajo, pero no estoy seguro de que el desarrollo de servidores sea donde las personas deberían comenzar a desarrollar sus habilidades, entornos en los que no necesitarían cooperar estrechamente con otros los desarrolladores en la misma base de código probablemente sean más adecuados para ellos.

Muchos RP, si no la mayoría, naturalmente tendrán un período de revisión de más de tres días, limitado por la disponibilidad de revisores. Sin embargo, naturalmente también nos esforzamos por obtener RP relativamente pequeños que sean fáciles de revisar. Es una buena práctica hacer eso, de modo que obtenga comentarios tempranos y no sea demasiado difícil para los revisores. Sin embargo, eso a menudo significa que resolver una tarea más grande implicará varios PR incrementales. Si cada RP requiere un período de revisión de tres días, se retrasará significativamente el desarrollo. Si esa es la política, entonces sospecho que nosotros, como desarrolladores, terminaríamos no escribiendo PR pequeños, sino haciendo un PR grande para que no tenga que esperar un período de revisión de tres días para cada uno.

Eso daría como resultado PR más grandes que son más difíciles de revisar, una desviación del desarrollo ágil y un mayor riesgo de que se cuelen errores en el proceso de revisión.

Me interesaría mucho saber qué están haciendo otros proyectos más grandes en este sentido, pero para mí, un enfoque único para todos no es deseable ni alcanzable.

Es difícil para mí decirlo, ya que soy un administrador de versiones, pero creo que @TallTed lo apoyaría, el proceso debería quedar en gran medida a discreción del administrador de versiones. El administrador de versiones debe asegurarse de que se pregunte a los revisores más adecuados, que se solicite una cantidad adecuada de revisores según el problema y que las fusiones no ocurran antes de que la cantidad correcta de revisores haya respondido con una aprobación, que las fusiones no ocurran. No sucederá si se solicitan cambios, si las ramas correctas están bloqueadas para hacer cumplir el proceso de revisión, si los RP potencialmente polémicos se señalan, por ejemplo, a la atención del líder de la comunidad a través de algún medio de notificación y, de hecho, otros revisores son bienvenidos a hacerlo. también.

Solo quería incluir las notas de la conversación de la reunión de apoyo comunitario. Estos puntos fueron hechos por diferentes personas dentro del Equipo Solid:

• El período de revisión de 3 días podría ralentizar el trabajo sólido.
• ¿Cuál es el beneficio práctico de un período de tiempo? El beneficio práctico sería crear un entorno inclusivo más abierto con un proceso de toma de decisiones transparente que se pueda entender y consultar.
• ¿Cuál es el problema que estamos tratando de resolver? ¿Hay otras formas de solucionarlo? Lo que realmente estamos tratando de resolver es que existen restricciones cuando se realizan cambios y no tuvieron la oportunidad de brindar su perspectiva. El límite de tiempo es una forma de dar oportunidad. Otro enfoque para invitar a la inclusión es asegurarse de que las sugerencias se publiquen en un entorno que las personas puedan verificar, por ejemplo, sólidas/sugerencias.
  – Discriminar un efecto secundario más que la raíz.
• ¿Dónde está la línea entre inclusión y eficiencia? Do-ocracy necesitas dejar que las personas que hacen cosas decidan. Tener poca autonomía es otro extremo al que no debemos ir. Metrocracia – do-ocracia. La implementación de estos ideales puede ser tóxica para las minorías.

• Tratemos de estar a la vanguardia. ¿Qué podemos aprender de los errores? No hagamos todo como se hacía antes, reflexionemos por qué estamos haciendo lo que estamos haciendo. Trabaja en traducir las especificaciones a lenguaje natural. Especialmente cuando las especificaciones están evolucionando, es difícil mantenerlas actualizadas. Podría ser muy largo y más fácil de leer para las personas, puede ser demasiado para masticar. Proponiendo tratar de encontrar temas dentro de la especificación. Encuentre formas de distribuir formas de ver la especificación. Escribir más tutoriales, para resolver varios problemas. También hay espacio para publicaciones de blog que explican elementos de la especificación. Conviértelo en golosinas masticables.

• Podemos eliminar las confirmaciones, son reversibles, sin embargo, ¿es práctica la reversión? La reversión de las confirmaciones de la comunidad es lenta, por lo que tardará aún más en revertirse. Más difícil de revertir en el servidor porque los elementos se crearon sobre decisiones anteriores.

• No estamos haciendo nada diferente a otro proyecto. Aunque establecer un período de tiempo es diferente de las prácticas anteriores, lo que estamos tratando de hacer es construir un modelo diferente, y los modelos anteriores han sido dominados por un grupo homogéneo, entonces, ¿queremos usar prácticas pasadas o esforzarnos por estar al límite? de pensamiento? ¿Podríamos aprender de ejemplos anteriores cómo no caer en las mismas trampas y analizar qué funcionó? Prometemos ser diferentes: lo que funcionó en el pasado no ha funcionado.

• ¿Podríamos diferenciar entre los repositorios? ¿Si es así, cómo?

• ¿Es el código diferente de las reglas? El servidor sólido de Node tiene un impacto en la sociedad al igual que el repositorio de la comunidad y la especificación sólida. Entonces, ¿cómo diferenciar? Es difícil evaluar qué tendrá un impacto social, especialmente cuando los profesionales que realizan esa evaluación no pueden acceder a la información porque no está en un idioma que puedan interpretar.
• Solid Server es una pieza normativa de software que tiene un enorme impacto en la sociedad, por lo que las decisiones de código tienen un gran impacto.
• Las solicitudes de extracción individuales son pequeños fragmentos de cambios que no tienen esa propiedad. Solo están ahí para hacer que los cambios sean incrementales para envolver nuestras mentes alrededor de eso. No es lo mismo que un cambio social porque no son lo mismo cualitativa y cuantitativamente.
• Los tres repositorios de especificaciones y el repositorio de la comunidad deberían tener procesos más estrictos, por ejemplo, con un período de revisión mínimo definido y un revisor asignado. La especificación tiene un gran efecto normativo. Buena manera de distinguir los repos por el efecto normativo que pueden tener en general. El repositorio comunitario y las especificaciones sólidas están en esa categoría. Entonces sería bueno tener una fusión transparente.

• Podría tener un conjunto de reglas híbridas para el servidor sólido de nodo que diga que si el cambio se desvía de la especificación, necesita un tiempo de revisión más largo. Los casos en los que implementamos las especificaciones en el código que se desvían de la especificación también son importantes para tener un proceso.

• El flujo de trabajo y los pasos no están documentados.

• Los ingenieros confían más en una tubería que los no ingenieros. Tal vez estamos confiando en esto. Tal vez hay un punto. La demografía de la cultura de los desarrolladores, tal vez porque pensamos que así es como debe ser.
• Las decisiones clave se disfrazan de técnicas cuando en realidad tienen implicaciones masivas más allá de lo técnico.
• El código puede tener un tremendo impacto en la sociedad, por lo que es importante comprender el impacto y permitir que las personas participen.
• Lenguaje natural: las especificaciones podrían actualizarse en cualquier caso. Al hacer eso, hay una mejor manera de explicar las cosas. No iría tan lejos como para volver a escribir elementos técnicos como no técnicos. Existe la oportunidad de mejorar la legibilidad de la especificación para garantizar que sea correcta. Recibirá un gran rechazo diciendo que se eliminará el técnico.
  
  
  
  • Necesitamos construir cosas que sean aceptadas y, por lo tanto, deben ser comprensibles para todos.
  
  

@TallTed , ¿tiene alguna idea sobre las actas de la reunión en el comentario anterior?

Como camino a seguir propongo lo siguiente:

Las solicitudes de extracción y los problemas asociados a los siguientes repositorios deben estar abiertos durante un mínimo de tres días:
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

Las solicitudes de extracción y las incidencias asociadas a todos los demás repositorios se pueden cerrar de inmediato y no tienen un tiempo mínimo para permanecer abiertas, a menos que se desvíen de las especificaciones, en cuyo caso deben estar abiertas durante un mínimo de tres días.

¿Alguna objeción?

Funciona para mi. También existe la posibilidad de agregar texto a la descripción del rol del Administrador de versiones, describiendo lo que deben hacer con los repositorios restantes.

También me gusta esta solución :smile_cat: Escribamos el razonamiento en algún lugar también, para que la gente entienda nuestro pensamiento detrás de él.

@kjetilk Sí, agregaré una nota a https://github.com/solid/community/pull/44

@megoth ok incluirá una breve descripción en el archivo Léame del repositorio de la comunidad

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