[Ietf-lac] Mejoras al Datatracker (Re: Camino hacia Adelante (ietf-lac))

[Alvaro Retana]

On June 27, 2018 at 10:16:01 PM, Prof. Diego Dujovne (diego.dujovne at mail.udp.cl) wrote:

[Cambio de tema para esta tangente.]

Diego:

Hola!  Cómo estás?

...
            El proceso implica unir cronológicamente las mailing lists, las 
transcripciones de las interim calls, los issues en el repositorio, las 
transcripciones de las sesiones de la IETF y tener charlas con chairs en 
su escaso tiempo disponible para entender para dónde va el grupo, y 
cuáles son los objetivos y la política que se va a asumir, más allá de lo que 
dice el charter. Para lograr esto, hacen falta tanto recursos para asistir,
como tiempo para digerir. 
           Entonces, mi propuesta de solución es unificar sistemas y ordenar
la información. Creo que hay muchas fuentes y muy variadas y a esto le
falta evolución. No es una línea de tiempo de un I-D y/o de un WG, pero casi. Ahi
creo que falta una herramienta y que la IETF puede mejorar considerablemente
si se aplica a realizar esto, al menos desde un punto en adelante. 
           Creo también que solo con la foto estática sola no es suficiente y que
esto puede conllevar un cambio de cultura difícil de digerir para una comunidad
que desde el inicio ha colaborado de esta manera. 
Me interesa entender más lo que estás proponiendo.  Parece, desde el punto de vista de un ID, que te gustaría ver las decisiones, mensajes, discusiones relacionadas más fácilmente que como está ahora: en el datatracker puedo ver la historia de las versiones, los cambios de status (y otra historia), las reuniones en las que se discutió el documento y hasta buscar las listas de correo por menciones…pero todo en ventanas/tabs diferentes, y la correlación tiene que ser manual.  Eso es lo que querés unificar, cierto?

Además de lo anterior, hay discusiones y experimentos con el RFC Editor para el uso de GitHub (u otros sistemas como Phabricator) para que los cambios en los documentos sean más fáciles y transparentes….  Lo que también significa un cambio de la cultura actual del correo…y que sería necesario unificar...

Como estoy seguro que sabes, el desarrollo de herramientas en el IETF se lleva a cabo significativamente por voluntarios — incluyendo en el CodeSprint [1].  En los últimos 6 meses el IESG ha estado tratando de mejorar los procesos para que el desarrollo no dependa principalmente de un grupo pequeño de personas.  Un trabajo como el que proponés no es de un día de desarrollo — sería interesante discutir tus ideas con el equipo.  

También sería interesante si hay personas en este grupo (ietf-lac) dispuestas a colaborar en este trabajo [*]. :-)

Gracias!

Alvaro.

[1] https://www.ietf.org/how/runningcode/code-sprint/ 



[*] Por cierto: yo tengo un par de otros proyectos en los que puedo usar ayuda.

(1) Además de entender que está pasando en la lista y con los documentos en marcha, otra de las barreras de entrada es entender cómo los RFCs existentes se relacionan entre ellos: esto es importante para los participantes, pero también para los implementadores.  Qué significa soportar IPv6…o BGP…??  No se tiene que soportar un solo RFC, y la relación no está claramente indicada en los documentos o el datatracker.  Necesitamos entonces un “mapa” de las tecnologías, la relación entre los RFCs, cuales son obligatorios, opcionales, etc.  Este tema lo he discutido en otras ocaciones en la lista y dentro del área de enrutamiento, y parece que a muchos les gusta la idea…pero no hemos encontrado a nadie con el tiempo para hacerlo.  Creo que Hugo había enviado un “mapa” del DNS a la lista hace unos meses…

(2) En mi “tiempo libre” estoy tratando de investigar la relación entre la publicación de documentos, sus períodos y las fechas de las reuniones…mi hipótesis es que existe una correlación fuerte entre las dos, y que esa es una de las razones por las que el trabajo en el IETF dura tanto — si cambiamos algunos de los comportamientos podemos acelerar los procesos y hacer que la organización sea más eficiente (y hasta predictiva en algunos casos).  Esto claramente no es trabajo técnico, pero es de fijarse en la operación del IETF por dentro...






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/ietf-lac/attachments/20180628/8ed71ada/attachment.html>