Priorizando problemas

Esta página está escrita para personas que ayudan a priorizar problemas en el rastreador de problemas de Github.

Preámbulo

[9598]: “- Cualquier proyecto tiene recursos limitados, la diferencia entre proyectos será el umbral. " [9599]: “- Cualquier proyecto debería tener objetivos claros. Para Ansel, es gestionar, editar y exportar colecciones de imágenes RAW en una computadora de escritorio por un usuario final que no sea un usuario de CLI pero pone la calidad visual de la imagen por encima de todo. " [9600]: “- Cualquier proyecto tiene gastos generales, que son acciones solicitadas para cumplir los objetivos, aunque no sean directamente el objetivo y, por lo tanto, deben mantenerse mínimas. Para Ansel, es el mantenimiento del sitio web, documentación, servidores, paquetes compilados nocturnos, limpieza de código, depuración, pruebas de regresión, soporte cruzado de OS, triage de problemas, etc. " [9601]: “- Los objetivos y gastos generales deben expresarse en términos de tareas a realizar para resolver problemas (problemas). Si no hay problema que resolver, entonces no hay trabajo que hacer: el status quo también es genial, no creen trabajo por el simple hecho de hacerlo. " [9602]: “- Debido a la limitación de recursos, las tareas deben ordenarse según su prioridad.- Cualquier proyecto tiene recursos limitados, la diferencia entre proyectos será el umbral. " [9599]: “- Cualquier proyecto debería tener objetivos claros. Para Ansel, es gestionar, editar y exportar colecciones de imágenes RAW en una computadora de escritorio por un usuario final que no sea un usuario de CLI pero pone la calidad visual de la imagen por encima de todo. " [9600]: “- Cualquier proyecto tiene gastos generales, que son acciones solicitadas para cumplir los objetivos, aunque no sean directamente el objetivo y, por lo tanto, deben mantenerse mínimas. Para Ansel, es el mantenimiento del sitio web, documentación, servidores, paquetes compilados nocturnos, limpieza de código, depuración, pruebas de regresión, soporte cruzado de OS, triage de problemas, etc. " [9601]: “- Los objetivos y gastos generales deben expresarse en términos de tareas a realizar para resolver problemas (problemas). Si no hay problema que resolver, entonces no hay trabajo que hacer: el status quo también es genial, no creen trabajo por el simple hecho de hacerlo. " [9602]: “- Debido a la limitación de recursos, las tareas deben ordenarse según su prioridad.

• Cualquier proyecto debería tener objetivos claros. Para Ansel, es gestionar, editar y exportar colecciones de imágenes RAW en una computadora de escritorio por un usuario final que no sea un usuario de CLI pero pone la calidad visual de la imagen por encima de todo. " [9600]: “- Cualquier proyecto tiene gastos generales, que son acciones solicitadas para cumplir los objetivos, aunque no sean directamente el objetivo y, por lo tanto, deben mantenerse mínimas. Para Ansel, es el mantenimiento del sitio web, documentación, servidores, paquetes compilados nocturnos, limpieza de código, depuración, pruebas de regresión, soporte cruzado de OS, triage de problemas, etc. " [9601]: “- Los objetivos y gastos generales deben expresarse en términos de tareas a realizar para resolver problemas (problemas). Si no hay problema que resolver, entonces no hay trabajo que hacer: el status quo también es genial, no creen trabajo por el simple hecho de hacerlo. " [9602]: “- Debido a la limitación de recursos, las tareas deben ordenarse según su prioridad.
• Cualquier proyecto tiene gastos generales, que son acciones solicitadas para cumplir los objetivos, aunque no sean directamente el objetivo y, por lo tanto, deben mantenerse mínimas. Para Ansel, es el mantenimiento del sitio web, documentación, servidores, paquetes compilados nocturnos, limpieza de código, depuración, pruebas de regresión, soporte cruzado de OS, triage de problemas, etc. " [9601]: “- Los objetivos y gastos generales deben expresarse en términos de tareas a realizar para resolver problemas (problemas). Si no hay problema que resolver, entonces no hay trabajo que hacer: el status quo también es genial, no creen trabajo por el simple hecho de hacerlo. " [9602]: “- Debido a la limitación de recursos, las tareas deben ordenarse según su prioridad.
• Los objetivos y gastos generales deben expresarse en términos de tareas a realizar para resolver problemas (problemas). Si no hay problema que resolver, entonces no hay trabajo que hacer: el status quo también es genial, no creen trabajo por el simple hecho de hacerlo. " [9602]: “- Debido a la limitación de recursos, las tareas deben ordenarse según su prioridad.
• Debido a la limitación de recursos, las tareas deben ordenarse según su prioridad.

El siguiente documento tiene como objetivo definir esta prioridad.

Ansel se bifurcó de Darktable porque Darktable no tiene un objetivo claro, no tiene gestión de prioridades, y los gastos generales aumentan cada año, lo cual es una marca de fábricas de agotamiento y es insostenible a medio plazo.

Definiendo buenos problemas

La gestión de proyectos funciona mejor con tareas SMART. S.M.A.R.T. significa:

[9633]: “- Específico (ej: encontrar URI de imágenes que Ansel exportó en el sistema de archivos y abrirlas) " [9634]: “- Medible (ej: número de clics/pasos requeridos, tiempo de CPU para realizar la tarea en una plataforma objetivo) " [9635]: “- Accionable/Alcanzable (ej: se puede integrar en la base de código actual con solo reescrituras menores, necesita solo un par de cientos de líneas de código) " [9636]: “- Relevante/Razonable (ej: es parte de un flujo de trabajo fotográfico bastante general, sería utilizado por una parte significativa de los usuarios) " [9637]: “- Limitado en el tiempo (ej: requiere como máximo 70 horas de hombre).- Específico (ej: encontrar URI de imágenes que Ansel exportó en el sistema de archivos y abrirlas) " [9634]: “- Medible (ej: número de clics/pasos requeridos, tiempo de CPU para realizar la tarea en una plataforma objetivo) " [9635]: “- Accionable/Alcanzable (ej: se puede integrar en la base de código actual con solo reescrituras menores, necesita solo un par de cientos de líneas de código) " [9636]: “- Relevante/Razonable (ej: es parte de un flujo de trabajo fotográfico bastante general, sería utilizado por una parte significativa de los usuarios) " [9637]: “- Limitado en el tiempo (ej: requiere como máximo 70 horas de hombre).

• Medible (ej: número de clics/pasos requeridos, tiempo de CPU para realizar la tarea en una plataforma objetivo) " [9635]: “- Accionable/Alcanzable (ej: se puede integrar en la base de código actual con solo reescrituras menores, necesita solo un par de cientos de líneas de código) " [9636]: “- Relevante/Razonable (ej: es parte de un flujo de trabajo fotográfico bastante general, sería utilizado por una parte significativa de los usuarios) " [9637]: “- Limitado en el tiempo (ej: requiere como máximo 70 horas de hombre).
• Accionable/Alcanzable (ej: se puede integrar en la base de código actual con solo reescrituras menores, necesita solo un par de cientos de líneas de código) " [9636]: “- Relevante/Razonable (ej: es parte de un flujo de trabajo fotográfico bastante general, sería utilizado por una parte significativa de los usuarios) " [9637]: “- Limitado en el tiempo (ej: requiere como máximo 70 horas de hombre).
• Relevante/Razonable (ej: es parte de un flujo de trabajo fotográfico bastante general, sería utilizado por una parte significativa de los usuarios) " [9637]: “- Limitado en el tiempo (ej: requiere como máximo 70 horas de hombre).
• Limitado en el tiempo (ej: requiere como máximo 70 horas de hombre).

Un buen problema lleva a una tarea SMART. Para Ansel, eso significa problemas que se centran en un problema claramente definido que afecta un paso claramente definido del flujo de trabajo de edición de imágenes (“Tengo problemas haciendo X porque Y y me gustaría Z”).

Las preguntas y discusiones generales deberían ocurrir en https://community.ansel.photos.

Los problemas malos son:

[9662]: “- demasiado amplios (“automatizar flujo de trabajo”, “mejorar UX”), " [9663]: “- centrarse en los medios (“usar red neuronal”, “ampliar curva tonal”) en lugar del objetivo (“enmascarar el cielo”, “controlar la saturación selectivamente”), " [9664]: “- fuera del alcance (“transferir a Android”, “cambiar a Qt”, “cambiar a Vulkan”) " [9665]: “- afectar a bibliotecas/proyectos de terceros (Rawspeed, Libraw, Exiv2, Lensfun, GPhoto2, Gtk, etc.), " [9666]: “- demasiado subjetivos (“por favor, hagan las cosas como ese otro software que usé en el pasado y realmente me gusta”). Lo que al usuario A le gusta, al usuario B no le gustará, no podemos trabajar con eso.- demasiado amplios (“automatizar flujo de trabajo”, “mejorar UX”), " [9663]: “- centrarse en los medios (“usar red neuronal”, “ampliar curva tonal”) en lugar del objetivo (“enmascarar el cielo”, “controlar la saturación selectivamente”), " [9664]: “- fuera del alcance (“transferir a Android”, “cambiar a Qt”, “cambiar a Vulkan”) " [9665]: “- afectar a bibliotecas/proyectos de terceros (Rawspeed, Libraw, Exiv2, Lensfun, GPhoto2, Gtk, etc.), " [9666]: “- demasiado subjetivos (“por favor, hagan las cosas como ese otro software que usé en el pasado y realmente me gusta”). Lo que al usuario A le gusta, al usuario B no le gustará, no podemos trabajar con eso.

• centrarse en los medios (“usar red neuronal”, “ampliar curva tonal”) en lugar del objetivo (“enmascarar el cielo”, “controlar la saturación selectivamente”), " [9664]: “- fuera del alcance (“transferir a Android”, “cambiar a Qt”, “cambiar a Vulkan”) " [9665]: “- afectar a bibliotecas/proyectos de terceros (Rawspeed, Libraw, Exiv2, Lensfun, GPhoto2, Gtk, etc.), " [9666]: “- demasiado subjetivos (“por favor, hagan las cosas como ese otro software que usé en el pasado y realmente me gusta”). Lo que al usuario A le gusta, al usuario B no le gustará, no podemos trabajar con eso.
• fuera del alcance (“transferir a Android”, “cambiar a Qt”, “cambiar a Vulkan”) " [9665]: “- afectar a bibliotecas/proyectos de terceros (Rawspeed, Libraw, Exiv2, Lensfun, GPhoto2, Gtk, etc.), " [9666]: “- demasiado subjetivos (“por favor, hagan las cosas como ese otro software que usé en el pasado y realmente me gusta”). Lo que al usuario A le gusta, al usuario B no le gustará, no podemos trabajar con eso.
• afectar a bibliotecas/proyectos de terceros (Rawspeed, Libraw, Exiv2, Lensfun, GPhoto2, Gtk, etc.), " [9666]: “- demasiado subjetivos (“por favor, hagan las cosas como ese otro software que usé en el pasado y realmente me gusta”). Lo que al usuario A le gusta, al usuario B no le gustará, no podemos trabajar con eso.
• demasiado subjetivos (“por favor, hagan las cosas como ese otro software que usé en el pasado y realmente me gusta”). Lo que al usuario A le gusta, al usuario B no le gustará, no podemos trabajar con eso.

Nota al margen: algunos problemas pueden parecer cosas que necesitan más código, mientras que en realidad necesitan mejor documentación de las características actuales, o ligeros retoques de GUI (renombrar etiquetas, reorganizar widgets), así que eso es algo a tener en cuenta antes de saltar a las armas.

Definiendo prioridades

En un mundo ideal, las tareas (también conocidas como buenos problemas) se añadirían a la lista de pendientes de forma lineal, a medida que se alcanzan los hitos, y su producto de código se probaría durante un par de semanas mientras el código está congelado, hasta que se demuestre que todo se sostiene, en cuyo caso descongelaríamos el código y pasaríamos a la siguiente tarea en la lista de pendientes.

El problema es que esto implica que todos estén presentes durante la fase de pruebas, para que no congelen el código por mucho tiempo. Debido a que eso no sucede (las personas toman vacaciones, tienen hijos, cambian de hogar, cambian de trabajo, tienen una vida…), tenemos que paralelizar las pruebas del producto de tareas anteriores mientras trabajamos en la siguiente, para ser eficientes.

Esto significa que la lista de pendientes no es lineal y algunas cosas importantes pueden ser añadidas o eliminadas dinámicamente, dependiendo de lo que suceda. El problema entonces es determinar qué constituye algo lo suficientemente importante como para interrumpir el cronograma.

No hay una regla definitiva aquí, por lo que tendrás que usar tu mejor juicio, pero hay algunas reglas generales:

[9709]: “- Algo roto recientemente (una regresión) es más fácil de detectar y arreglar cuanto antes, por lo que, en el esquema general de las cosas, podría ser menos trabajo en conjunto hacerlo antes, " [9710]: “- Algo que impide que el software funcione en absoluto (crash, archivos de salida corruptos, pérdida de datos) es lo suficientemente crítico como para tener prioridad sobre las mejoras y los arreglos más cosméticos, " [9711]: “- Algo que impacta a un gran número de usuarios y donde no se puede encontrar una solución alternativa también tendrá prioridad.- Algo roto recientemente (una regresión) es más fácil de detectar y arreglar cuanto antes, por lo que, en el esquema general de las cosas, podría ser menos trabajo en conjunto hacerlo antes, " [9710]: “- Algo que impide que el software funcione en absoluto (crash, archivos de salida corruptos, pérdida de datos) es lo suficientemente crítico como para tener prioridad sobre las mejoras y los arreglos más cosméticos, " [9711]: “- Algo que impacta a un gran número de usuarios y donde no se puede encontrar una solución alternativa también tendrá prioridad.

• Algo que impide que el software funcione en absoluto (crash, archivos de salida corruptos, pérdida de datos) es lo suficientemente crítico como para tener prioridad sobre las mejoras y los arreglos más cosméticos, " [9711]: “- Algo que impacta a un gran número de usuarios y donde no se puede encontrar una solución alternativa también tendrá prioridad.
• Algo que impacta a un gran número de usuarios y donde no se puede encontrar una solución alternativa también tendrá prioridad.

Por el contrario, cualquier cosa que impacte a un pequeño número de usuarios, o características secundarias/nicho, o molestias menores que tienen soluciones alternativas, no son lo suficientemente críticas como para justificar interrumpir el cronograma. Esas se añadirán a la cola de manera FIFO.

Ansel tiene 4 niveles de prioridades, fijados como etiquetas de problemas:

[9730]: “- prioridad: crítica: Afecta funcionalidades básicas y centrales del software de manera que impiden que funcione en absoluto, " [9731]: “- prioridad: alta: Afecta funcionalidades básicas y centrales del software de manera que degrada severamente la usabilidad, " [9732]: “- prioridad: media: Afecta funcionalidades básicas y centrales del software de manera que degrada levemente la usabilidad (hay soluciones alternativas disponibles), " [9733]: “- prioridad: baja: Afecta características opcionales y de nicho.- prioridad: crítica: Afecta funcionalidades básicas y centrales del software de manera que impiden que funcione en absoluto, " [9731]: “- prioridad: alta: Afecta funcionalidades básicas y centrales del software de manera que degrada severamente la usabilidad, " [9732]: “- prioridad: media: Afecta funcionalidades básicas y centrales del software de manera que degrada levemente la usabilidad (hay soluciones alternativas disponibles), " [9733]: “- prioridad: baja: Afecta características opcionales y de nicho.

• prioridad: alta: Afecta funcionalidades básicas y centrales del software de manera que degrada severamente la usabilidad, " [9732]: “- prioridad: media: Afecta funcionalidades básicas y centrales del software de manera que degrada levemente la usabilidad (hay soluciones alternativas disponibles), " [9733]: “- prioridad: baja: Afecta características opcionales y de nicho.
• prioridad: media: Afecta funcionalidades básicas y centrales del software de manera que degrada levemente la usabilidad (hay soluciones alternativas disponibles), " [9733]: “- prioridad: baja: Afecta características opcionales y de nicho.
• prioridad: baja: Afecta características opcionales y de nicho.

Definiendo hitos

Los parámetros de los módulos se guardan como blobs binarios. Gestionamos estos manejando su tamaño de bit. Cuando se añade un nuevo parámetro, debemos escribir código para manejar la conversión, es decir, el tamaño de bit diferente del blob del parámetro, e incrementamos la versión interna de los parámetros del módulo. No se escribe código para la compatibilidad hacia atrás, por lo que las imágenes editadas con módulos más nuevos no pueden abrirse en módulos más antiguos. Los parámetros del módulo también se usan en estilos, preajustes y archivos XMP.

Por estas razones, cualquier problema que llevaría a agregar parámetros en módulos (ya sea los módulos de procesamiento de imágenes en el cuarto oscuro o los módulos de mesa de luz que gestionan la exportación y los metadatos), rompería la compatibilidad hacia atrás y debe planificarse para la próxima versión principal del software (1.0, 2.0, 3.0, etc.). Esto significa que solo se permiten cambios en la GUI y el comportamiento dentro de la misma versión principal, y se pueden planificar para la próxima versión menor (0.1, 0.2, 0.3, luego 1.1, 1.2, 1.3, etc.).

Ansel solo tiene 2 hitos a la vez: la próxima versión menor y la próxima versión principal.

Definiendo dificultad

La dificultad está directamente relacionada con la cantidad de trabajo requerido por una tarea, es decir:

[9776]: “- el número de líneas de código a escribir, " [9777]: “- el número de archivos a cambiar, " [9778]: “- la probabilidad de romper características existentes, lo que lleva a un trabajo de prueba adicional, " [9779]: “- la existencia de características similares o teoría escrita para lograr la tarea, " [9780]: “- el gasto general de hacer que los cambios y características funcionen de manera confiable en todos los sistemas operativos.- el número de líneas de código a escribir, " [9777]: “- el número de archivos a cambiar, " [9778]: “- la probabilidad de romper características existentes, lo que lleva a un trabajo de prueba adicional, " [9779]: “- la existencia de características similares o teoría escrita para lograr la tarea, " [9780]: “- el gasto general de hacer que los cambios y características funcionen de manera confiable en todos los sistemas operativos.

• el número de archivos a cambiar, " [9778]: “- la probabilidad de romper características existentes, lo que lleva a un trabajo de prueba adicional, " [9779]: “- la existencia de características similares o teoría escrita para lograr la tarea, " [9780]: “- el gasto general de hacer que los cambios y características funcionen de manera confiable en todos los sistemas operativos.
• la probabilidad de romper características existentes, lo que lleva a un trabajo de prueba adicional, " [9779]: “- la existencia de características similares o teoría escrita para lograr la tarea, " [9780]: “- el gasto general de hacer que los cambios y características funcionen de manera confiable en todos los sistemas operativos.
• la existencia de características similares o teoría escrita para lograr la tarea, " [9780]: “- el gasto general de hacer que los cambios y características funcionen de manera confiable en todos los sistemas operativos.
• el gasto general de hacer que los cambios y características funcionen de manera confiable en todos los sistemas operativos.

Estimar la dificultad de manera precisa es algo que solo un desarrollador experimentado puede hacer.

Definiendo naturaleza

La naturaleza de los problemas se maneja con etiquetas. Tenemos:

[9805]: “- regresiones (cosas que solían funcionar pero fueron rotas por cambios recientes), " [9806]: “- errores (cosas que nunca han funcionado en los últimos años), " [9807]: “- mejoras (cosas que necesitan ser mejoradas o agregadas), " [9808]: “- no se arreglará (no es un error, sino una elección de característica o diseño o necesidad impuesta por dependencias de terceros), " [9809]: “- pregunta (no debería estar en Github, sino en https://community.ansel.photos), " [9810]: “- duplicado (problema ya reportado), " [9811]: “- incierto (el problema no se puede entender), " [9812]: “- inválido (el problema es “malo” según la definición anterior de un buen problema).- regresiones (cosas que solían funcionar pero fueron rotas por cambios recientes), " [9806]: “- errores (cosas que nunca han funcionado en los últimos años), " [9807]: “- mejoras (cosas que necesitan ser mejoradas o agregadas), " [9808]: “- no se arreglará (no es un error, sino una elección de característica o diseño o necesidad impuesta por dependencias de terceros), " [9809]: “- pregunta (no debería estar en Github, sino en https://community.ansel.photos), " [9810]: “- duplicado (problema ya reportado), " [9811]: “- incierto (el problema no se puede entender), " [9812]: “- inválido (el problema es “malo” según la definición anterior de un buen problema).

• errores (cosas que nunca han funcionado en los últimos años), " [9807]: “- mejoras (cosas que necesitan ser mejoradas o agregadas), " [9808]: “- no se arreglará (no es un error, sino una elección de característica o diseño o necesidad impuesta por dependencias de terceros), " [9809]: “- pregunta (no debería estar en Github, sino en https://community.ansel.photos), " [9810]: “- duplicado (problema ya reportado), " [9811]: “- incierto (el problema no se puede entender), " [9812]: “- inválido (el problema es “malo” según la definición anterior de un buen problema).
• mejoras (cosas que necesitan ser mejoradas o agregadas), " [9808]: “- no se arreglará (no es un error, sino una elección de característica o diseño o necesidad impuesta por dependencias de terceros), " [9809]: “- pregunta (no debería estar en Github, sino en https://community.ansel.photos), " [9810]: “- duplicado (problema ya reportado), " [9811]: “- incierto (el problema no se puede entender), " [9812]: “- inválido (el problema es “malo” según la definición anterior de un buen problema).
• no se arreglará (no es un error, sino una elección de característica o diseño o necesidad impuesta por dependencias de terceros), " [9809]: “- pregunta (no debería estar en Github, sino en https://community.ansel.photos), " [9810]: “- duplicado (problema ya reportado), " [9811]: “- incierto (el problema no se puede entender), " [9812]: “- inválido (el problema es “malo” según la definición anterior de un buen problema).
• pregunta (no debería estar en Github, sino en https://community.ansel.photos), " [9810]: “- duplicado (problema ya reportado), " [9811]: “- incierto (el problema no se puede entender), " [9812]: “- inválido (el problema es “malo” según la definición anterior de un buen problema).
• duplicado (problema ya reportado), " [9811]: “- incierto (el problema no se puede entender), " [9812]: “- inválido (el problema es “malo” según la definición anterior de un buen problema).
• incierto (el problema no se puede entender), " [9812]: “- inválido (el problema es “malo” según la definición anterior de un buen problema).
• inválido (el problema es “malo” según la definición anterior de un buen problema).

Las prioridades son relativas

Vea https://www.youtube.com/watch?v=8fnfeuoh4s8 . Tener que reparar el auto para cambiar la bombilla es una gran metáfora de hacer código en un software de 12 años con cientos de miles de líneas de código escrito por personas que no se hablaron entre sí y no documentaron sus cambios. Arreglar el auto no es de máxima prioridad hasta que se convierta en el requisito previo para arreglar la luz de alta prioridad.

Tu trabajo como triager

En última instancia, solo un desarrollador experimentado podrá clasificar con precisión los problemas. Pero la razón requiere que un desarrollador experimentado se emplee para hacer cosas que solo un desarrollador experimentado puede hacer: escribir código simple para resolver eficientemente problemas técnicos que requieren cierta cantidad de teoría y diseño.

El compromiso es tener triagers que ayuden a priorizar problemas obvios para que los desarrolladores solo tengan que lidiar con los problemas menos obvios y se centren en la codificación.

[9849]: “1. etiqueta solo los problemas que entiendas y te sientas cómodo al clasificar. No tienes que hacerlos todos, está bien si no sabes. " [9850]: “2. para temas que entiendas: " [9851]: " - asigna una etiqueta de prioridad si puedes, " [9852]: " - asigna una etiqueta de naturaleza si puedes, " [9853]: " - asigna un hito si puedes, " [9854]: " - cierra inmediatamente el problema si es inválido o duplicado. " [9855]: “3. para temas que no entiendas: " [9856]: " - intenta hacer más preguntas al autor, " [9857]: " - asegúrate de que los autores proporcionen toda la información relevante (OS, hardware, pasos para reproducir errores), " [9858]: “4. es mejor si no haces nada que si lo haces mal: los problemas sin etiquetas son más fáciles de detectar que los problemas con etiquetas incorrectas. " [9859]: “5. no dudes en llamar a reuniones por video: es mejor sentarse juntos durante 30 minutos para tener una charla productiva y ajustar decisiones que intercambiar interminables hilos de mensajes inútiles.1. etiqueta solo los problemas que entiendas y te sientas cómodo al clasificar. No tienes que hacerlos todos, está bien si no sabes. " [9850]: “2. para temas que entiendas: " [9851]: " - asigna una etiqueta de prioridad si puedes, " [9852]: " - asigna una etiqueta de naturaleza si puedes, " [9853]: " - asigna un hito si puedes, " [9854]: " - cierra inmediatamente el problema si es inválido o duplicado. " [9855]: “3. para temas que no entiendas: " [9856]: " - intenta hacer más preguntas al autor, " [9857]: " - asegúrate de que los autores proporcionen toda la información relevante (OS, hardware, pasos para reproducir errores), " [9858]: “4. es mejor si no haces nada que si lo haces mal: los problemas sin etiquetas son más fáciles de detectar que los problemas con etiquetas incorrectas. " [9859]: “5. no dudes en llamar a reuniones por video: es mejor sentarse juntos durante 30 minutos para tener una charla productiva y ajustar decisiones que intercambiar interminables hilos de mensajes inútiles. 2. para temas que entiendas: " [9851]: " - asigna una etiqueta de prioridad si puedes, " [9852]: " - asigna una etiqueta de naturaleza si puedes, " [9853]: " - asigna un hito si puedes, " [9854]: " - cierra inmediatamente el problema si es inválido o duplicado. " [9855]: “3. para temas que no entiendas: " [9856]: " - intenta hacer más preguntas al autor, " [9857]: " - asegúrate de que los autores proporcionen toda la información relevante (OS, hardware, pasos para reproducir errores), " [9858]: “4. es mejor si no haces nada que si lo haces mal: los problemas sin etiquetas son más fáciles de detectar que los problemas con etiquetas incorrectas. " [9859]: “5. no dudes en llamar a reuniones por video: es mejor sentarse juntos durante 30 minutos para tener una charla productiva y ajustar decisiones que intercambiar interminables hilos de mensajes inútiles.

• asigna una etiqueta de prioridad si puedes, " [9852]: " - asigna una etiqueta de naturaleza si puedes, " [9853]: " - asigna un hito si puedes, " [9854]: " - cierra inmediatamente el problema si es inválido o duplicado. " [9855]: “3. para temas que no entiendas: " [9856]: " - intenta hacer más preguntas al autor, " [9857]: " - asegúrate de que los autores proporcionen toda la información relevante (OS, hardware, pasos para reproducir errores), " [9858]: “4. es mejor si no haces nada que si lo haces mal: los problemas sin etiquetas son más fáciles de detectar que los problemas con etiquetas incorrectas. " [9859]: “5. no dudes en llamar a reuniones por video: es mejor sentarse juntos durante 30 minutos para tener una charla productiva y ajustar decisiones que intercambiar interminables hilos de mensajes inútiles.
• asigna una etiqueta de naturaleza si puedes, " [9853]: " - asigna un hito si puedes, " [9854]: " - cierra inmediatamente el problema si es inválido o duplicado. " [9855]: “3. para temas que no entiendas: " [9856]: " - intenta hacer más preguntas al autor, " [9857]: " - asegúrate de que los autores proporcionen toda la información relevante (OS, hardware, pasos para reproducir errores), " [9858]: “4. es mejor si no haces nada que si lo haces mal: los problemas sin etiquetas son más fáciles de detectar que los problemas con etiquetas incorrectas. " [9859]: “5. no dudes en llamar a reuniones por video: es mejor sentarse juntos durante 30 minutos para tener una charla productiva y ajustar decisiones que intercambiar interminables hilos de mensajes inútiles.
• asigna un hito si puedes, " [9854]: " - cierra inmediatamente el problema si es inválido o duplicado. " [9855]: “3. para temas que no entiendas: " [9856]: " - intenta hacer más preguntas al autor, " [9857]: " - asegúrate de que los autores proporcionen toda la información relevante (OS, hardware, pasos para reproducir errores), " [9858]: “4. es mejor si no haces nada que si lo haces mal: los problemas sin etiquetas son más fáciles de detectar que los problemas con etiquetas incorrectas. " [9859]: “5. no dudes en llamar a reuniones por video: es mejor sentarse juntos durante 30 minutos para tener una charla productiva y ajustar decisiones que intercambiar interminables hilos de mensajes inútiles.
• cierra inmediatamente el problema si es inválido o duplicado. " [9855]: “3. para temas que no entiendas: " [9856]: " - intenta hacer más preguntas al autor, " [9857]: " - asegúrate de que los autores proporcionen toda la información relevante (OS, hardware, pasos para reproducir errores), " [9858]: “4. es mejor si no haces nada que si lo haces mal: los problemas sin etiquetas son más fáciles de detectar que los problemas con etiquetas incorrectas. " [9859]: “5. no dudes en llamar a reuniones por video: es mejor sentarse juntos durante 30 minutos para tener una charla productiva y ajustar decisiones que intercambiar interminables hilos de mensajes inútiles.

3. para temas que no entiendas: " [9856]: " - intenta hacer más preguntas al autor, " [9857]: " - asegúrate de que los autores proporcionen toda la información relevante (OS, hardware, pasos para reproducir errores), " [9858]: “4. es mejor si no haces nada que si lo haces mal: los problemas sin etiquetas son más fáciles de detectar que los problemas con etiquetas incorrectas. " [9859]: “5. no dudes en llamar a reuniones por video: es mejor sentarse juntos durante 30 minutos para tener una charla productiva y ajustar decisiones que intercambiar interminables hilos de mensajes inútiles.
   • intenta hacer más preguntas al autor, " [9857]: " - asegúrate de que los autores proporcionen toda la información relevante (OS, hardware, pasos para reproducir errores), " [9858]: “4. es mejor si no haces nada que si lo haces mal: los problemas sin etiquetas son más fáciles de detectar que los problemas con etiquetas incorrectas. " [9859]: “5. no dudes en llamar a reuniones por video: es mejor sentarse juntos durante 30 minutos para tener una charla productiva y ajustar decisiones que intercambiar interminables hilos de mensajes inútiles.
   • asegúrate de que los autores proporcionen toda la información relevante (OS, hardware, pasos para reproducir errores), " [9858]: “4. es mejor si no haces nada que si lo haces mal: los problemas sin etiquetas son más fáciles de detectar que los problemas con etiquetas incorrectas. " [9859]: “5. no dudes en llamar a reuniones por video: es mejor sentarse juntos durante 30 minutos para tener una charla productiva y ajustar decisiones que intercambiar interminables hilos de mensajes inútiles.
4. es mejor si no haces nada que si lo haces mal: los problemas sin etiquetas son más fáciles de detectar que los problemas con etiquetas incorrectas. " [9859]: “5. no dudes en llamar a reuniones por video: es mejor sentarse juntos durante 30 minutos para tener una charla productiva y ajustar decisiones que intercambiar interminables hilos de mensajes inútiles.
5. no dudes en llamar a reuniones por video: es mejor sentarse juntos durante 30 minutos para tener una charla productiva y ajustar decisiones que intercambiar interminables hilos de mensajes inútiles.

¡Gracias!