Estado Actual de Roverto

[GioSunrider]

Actualmente el rover se encuentra funcional, el codigo de @David-Estevez subido (ojo que hay que descomentar la linea de move) Falta para la OSHWDem 2019 intalarle una camara FPV para hacer el gamberro por alli. Tambien estaria bien ponerle un conector de bateria para que no queden cosas "al aire".

[David-Estevez]

Bueno, voy a aprovechar esta issue para intentar sentar las bases de una issue "como Dios manda", de manera similar a lo que @Siotma intentó hacer en Printer One. En primer lugar, que quede claro que no es nada contra ti, ni contra esta issue en particular, @GioSunrider, pero por algún lado hay que empezar, y te ha tocado a ti que eres fuerte y sé que podrás con ello 💪

Esperemos que con lo que saquemos de esta búsqueda de la issue perfecta™️ podamos hacer una plantila o algo para guiar a la gente que ponga issues.

¿Cómo poner una issue efectiva?

Título

El título de la issue debe identificar una tarea a realizar, lo más explícita y directamente posible para que podamos saber qué hay que hacer para cerrarla. En lugar de Estado Actual de Roverto, sería mucho más efectivo algo así como Documentar el estado actual de Roverto.

Descripción de la issue

Hay que intentar dar unos antecedentes que expliquen la issue o que ayuden a resolverla, así como explicar qué hay que hacer. En el caso de esta issue, eso se hace (:clap: :clap:) pero todavía se puede pulir un poco más:

Actualmente el rover se encuentra funcional, el codigo de @David-Estevez subido (ojo que hay que descomentar la linea de move)

• ¿Qué código? GitHub nos da herramientas para poner todo esto mucho más claro. Para referirnos a un código, podemos enlazar a un commit concreto: ¿es este el código al que te refieres? ¿Es este otro? (mi código no tienen ningún move comentado, eso fue cosa del de @madelgj , así que referirse a una versión concreta nos ahorra esta clase de dudas).
• ¿Subido dónde? "Subir" también es ambiguo, porque puede referirse tanto a GitHub como al rover.
• ¿Qué move? Este o este otro. Para evitar ambiguedades, ,es mejor referirse a números de línea, o usar GitHub y poner un link a la línea.
• Aún mejor sería subir el código que has modificado para que todos podamos acceder a él. Si no estás seguro de si vale o no, crea una brach o un pull request propio, pero sube el código para que no se pierda.

Falta para la OSHWDem 2019 intalarle una camara FPV para hacer el gamberro por alli. Tambien estaria bien ponerle un conector de bateria para que no queden cosas "al aire".

Sobre esto no hay mucha queja posible, quizá (siendo quisquilloso) usar una lista para que quede más claro:

• Instalar cámara FPV
• Poner un conector de batería (opcional)

1 issue, 1 problema a resolver

Aquí se han entremezclado dos cosas: el hecho de que hay que documentar el estado actual, y tus propuestas de cosas para mejorar el rover para la OSHWDem. Para que sean lo más efectivas posibles, es mejor abrir una issue distinta por cada problema a resolver.

Documentación de proyectos

Las issues son fantásticas para gestionar cosas que se están haciendo o faltan por hacer, pero no lo son tanto para documentar cosas. En este caso, para documentar los cambios que se le han ido haciendo a Roverto, creo que pegaría más hacerlo en un cuaderno de bitácora, por ejemplo, en el que todos vayamos semana tras semana poniendo qué hemos tocado en el robot para evitarnos sustos.

Recapitulando

Como he dicho antes, este comentario pretende que mejoremos la calidad de nuestras issues en RoboFactory, no te lo tomes a mal. Siempre digo que toda documentación es mejor que nada, incluso si es una foto a un garabato en un papel o una pizarra (esto lo hago yo mucho, ver "Project X" 😅) . Si la documetación está online todos nos benefiaremos de ella cuando estemos trabajando en el proyecto y no sepamos cómo funciona algo o qué cambios se han hecho ( y por qué).