💾 Archived View for gmi.osiux.com › 2021-03-28-tarea-en-progreso.gmi captured on 2022-06-11 at 20:50:03. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

tarea en progreso

AUTHOR: Osiris Alejandro Gomez
EMAIL: osiux@osiux.com
DATE: 2021-03-28 22:11

gestionar tareas desde la `tty`

En *`gcoop`* ^1[1] utilizamos principalmente como gestor de tareas *`redmine`* ^2[2] y a diario registro y resuelvo tareas de varios proyectos usando *`redmine-bash-utils`* ^3[3] desde mi consola (prefiero *bash* antes que *firefox*).

la secuencia ideal

Ni bien hay un nuevo *issue* es necesario evaluar si es un *bug* o se trata de un nuevo desarrollo, una mejora, o tal vez no hay nada para hacer o si es necesario solicitar *MAS DATOS* para determinar a acción a realizar.

De manera simplificada una tarea comienza en `Nueva`, cambia a `En Curso` y ni bien se termina pasa a `Resuelta` para que alguien la valide y la de por `Cerrada`.


+-----+     +-------------+     +-------+     +--------+
| new | --> | in-progress | --> | fixed | --> | closed |
+-----+     +-------------+     +-------+     +--------+

y vos con issue qué estás?

El flujo de trabajo puede variar, hay diferentes metodologías y posibles estados intermedios, pero lo más importante es saber si la tarea esta tomada por alguien y luego tener algún indicador de progreso de la misma.

Es una mala práctica iniciar una tarea sin al menos cambiarla a estado `En Curso` y luego **no comentar nada sobre ella**.

Registrar el progreso es vital para detectar cuando podemos estar *"enroscándonos"* innecesariamente y para esto nada mejor que escribir nuestros comentarios o adjuntar el log de trabajo realizado hasta el momento en el *issue*, asi el resto del equipo puede estar al tanto e incuso aportar con *tips* o alternativas de posibles soluciones y hasta ayudarnos a encontrar el camino más directo a la resolución del problema con otro enfoque.

la salida es colectiva

De nada sirve iniciar la tarea y 2 o 3 días después comentar que no tuviste varios errores, te trabaste y no podiste resolverla o por el contraro que si la pudiste resolver y sin ningún comentario simplemente la cambiás a `Resuelta`, en ambos casos no estas permitiendo una construcción colectiva y estás enfrentando el problema a solas y probablemente con una visión sesgada del problema.

Documentar durante el desarrollo te ayuda a ayudarte!

registrá todo lo que hacés!

En mi caso personal, no escribo directamente en el *Redmine*, tengo mi versión digital de cuaderno borrador o *journal*, en forma de comandos de *bash*, simplemente invocando *`jrnl`* ^4[4] puedo registrar fácilmente lo que hago a diario en archivos de texto plano que luego mediante el comando `redmine-from-jrnl` puedo convertir ese *jrnl* en un comentario de *Redmine* y gracias a esto no necesito que *Redmine* este accesible todo el tiempo, puedo trabajar *offline* y sobre todo poder buscar rápidamente en mi bitácora sobre tareas de días pasados.

Aunque también me apoyo en una libreta de papel, que luego la uso para mejorar mis *journals* y finalmente organizar el *Redmine*.

hace cuánto no informás el progreso?

Muchas veces sucede que en la *vorágine* del apuro por resolver algo crítico o porque simplemente me concentré demansiado y bajé a las profundidades de algún código, no llego a enviar mis comentarios al *Redmine*, pero sé que los tengo, por lo general esta todo el registro en mi `jrnl`.

La solución a este problema la encontré con un par de *scripts*, primero *`redmine-history`* ^5[5] revisa el historial de *bash* y muestra que comandos de `redmine` ejecuté hoy y a que hora exactamente!


redmine-history

  09:57 redmine-new-issue "scrum $(today)" 
  11:01 redmine-from-jrnl 
  11:31 redmine-add-comment-from-file issue.txt
  11:32 redmine-fix 48648
  11:32 redmine-time-entry-from-file issue.txt
  12:08 redmine-from-jrnl 
  14:18 redmine-timediff-last-comment

Luego el comando *`redmine-timediff-last-comment`* ^6[6] discrimina que comandos envían comentarios a `redmine` y calcula la diferencia de tiempo con la última ejecución:


redmine-timediff-last-comment

  02:30

De esta manera ahora puedo saber que hace exactamente `02:30 hs` que no informo nada de lo que estoy haciendo y me ayuda a ordenarme!

`timediff` en `tmux`

Agregando `#(redmine-timediff-last-comment)` al `status-right` en `~/.tmux.conf` puedo tener un indicar en todo momento que va cambiando de color pasando de verde a narajana y finalmente a rojo cuando pasó demasiado tiempo!

[IMG]

[7]

A futuro se me ocurre darle mas "inteligencia" al comando y que interactué con la *API* de *Redmine* sobre un issue en particular.