Prompt para Git en Bash

Si eres programador y has trabajado con Git, seguramente habrás comprobado alguna vez si el repositorio en el que estás trabajando está actualizado, la rama en la que te encuentras, etc. Pero cada vez que haces esto tienes que ejecutar alguna instrucción de Git. ¿No sería más cómodo tener siempre esa información a simple vista?

Continúa leyendo {title}

¿Qué es NotABug?

NotABug o NotABug.org es una plataforma que permite gestionar repositorios de código con Git. La plataforma utiliza un programa llamado Gogs, que es software libre, lo que permite que pueda ser instalado localmente o en un servidor.

Entre sus características destacan las siguientes:

  • Alojamiento para proyectos públicos y privados.
  • Repositorios Git, Wiki y sistema de seguimiento de errores.
  • Privacidad para los usuarios y visitantes: funciona también en la red Tor y tiene todo el código JavaScript alojado en su propio servidor.
  • Interfaz gráfica sencilla y muy rápida.
  • Alojamiento gratuito para proyectos de software libre.

Estoy registrado en NotABug desde el 26 de julio de 2016, y es la única plataforma que utilizo actualmente para desarrollar mis propios proyectos. También he colaborado con proyectos interesantes en NotABug como Awesome gamedev, LibreVideoJS, LibreVideoJS-wp, Résumér, mkblog.sh y la página web de la comunidad Peer. Puedes encontrar más información sobre los proyectos en los que estoy involucrado visitando mi perfil de NotABug.

Hasta ahora NotABug es la mejor plataforma que conozco para desarrollar programas usando Git. Es fácil de usar y de realizar proyectos colaborativos. Además, la interfaz gráfica es muy sencilla y ágil, a diferencia de otras alternativas como Gitlab.

Desarrolladores ingratos

cr1 cr2

Nunca me había pasado que alguien despreciara los errores que le señalara ni rechazara mis contribuciones a pesar de ser correctas. Anteriormente, incluso cuando me equivoqué al hacer una corrección, siempre me respondieron más amablemente.

En particular, a dicho personaje le señalé un error y pasó de él excusándose diciendo que se trataba de un componente que usa el proyecto pero no forma parte de él. Esto es una escusa pésima, ya que el error afecta a su proyecto. En contraposición, los desarrollares del fork de gogs para notabug.org y Unknown Horizons (por poner ejemplos que conozco de primera mano) hacen lo correcto: han sido notificados varios errores de los que no tenían la culpa directamente, pero hasta que no los corrigieron colaborando con el otro proyecto o actualizaron a una versión del software sin los errores, no cerraron los tiques (también llamado issues). Es absurdo ignorar los problemas por pequeños que sean, y más cuando te afectan, pues forman parte de las dependencias de tu proyecto. Al idiota que os he mencionado le arreglé el error a dicho proyecto (aunque el individuo cerró la incidencia antes de que lo hiciera).

Al individuo, también le avisé en otro tique de que la licencia Creative Commons no sirve para el código y le insté a que usara una que tuviera validez para el software. La licencia Creative Commons sirve para el contenido de un libro, sitio web, etc., no para el código fuente.

Lo más extraño fue que aún habiéndole dicho esto mostrándole las explicaciones de los propios creadores de la licencia, volvió a ignorar el tique irresponsablemente. En resumen, pasó de los dos errores que le mostré y me contestó con desprecio. Exactamente lo contrario a lo que estoy acostumbrado y lo que me ha pasado con otros equipos de desarrollo.

En el equipo de desarrollo de Unknown Horizons del que formo parte siempre nos agradamos de que alguien contribuya a nuestro proyecto y le agradecemos su trabajo, aceptamos con gusto correcciones de nuestros errores, les aclaramos cosas que no entienden y ayudamos a los colaboradores a terminar las mejoras que han empezado. Siempre estamos agradecidos y les respondemos amablemente porque son nuestros amigos, ya que nos ayudan recibiendo poco o nada a cambio.

Si por el contrario, una persona que colabora con un repositorio se encuentra con un equipo de desarrolladores que son incapaces de admitir sus errores y que responden altivamente, siente que no tiene sentido perder el tiempo en volver a ayudar a personas con el síndrome de Estocolmo que van a despreciar e insultar su buena voluntad.