Recientemente he intentado entrar en colaboración de código abierto en GitHub y me he encontrado con una situación en la que tengo curiosidad por saber cuál es la forma preferida de proceder.
Hace aproximadamente un mes, encontré un proyecto en GitHub para una biblioteca que ya había estado usando durante un tiempo y en el que encontré (y solucioné) algunos errores.
Como una incursión inicial en la colaboración de GitHub, encontré el repositorio que parecía tener el mayor volumen de actividad reciente, arreglé un error, agregué pruebas unitarias, presioné a GitHub e hice una solicitud de extracción. En unas pocas horas, el responsable del repositorio que bifurqué había aceptado el RP y se fusionó con otros RP de otras personas que también habían estado esperando.
Impulsado por esto, arreglé tres errores más que había encontrado, cada uno en una rama separada de mi propio repositorio, y presenté un problema y una solicitud de extracción para cada uno por separado.
Eso fue hace poco más de un mes, y las solicitudes de extracción han estado allí, intactas, desde entonces. El usuario cuyo repositorio había bifurcado no parece estar muy activo, ya que solo hizo 7 contribuciones totales en GitHub en el último año, y ese repositorio no ha tenido ningún compromiso desde la primera solicitud de extracción que hice.
Entonces mi pregunta:
¿Cómo se procede en esta situación? Idealmente, me gustaría evitar crear fragmentación de la biblioteca al realizar un montón de cambios en mi propio repositorio que no se fusionan en el repositorio principal. No obstante, me gustaría continuar haciendo correcciones de errores y agregando características, pero si fusiono todo en mi rama maestra y baso todas las nuevas correcciones fuera de esa rama, entonces si el responsable del repositorio que bifurqué alguna vez vuelve, gané No puedo dividir todos los cambios en solicitudes de extracción separadas para cada función / corrección de errores (he leído que las solicitudes de extracción generalmente deben ser una solicitud de extracción por función o corrección de errores).
¿Debo mantener una rama que esté en sintonía con el repositorio original, basar todas mis nuevas ramas en esa y luego mantener todas las confirmaciones fusionadas en mi rama maestra? Parece que eso me dejaría con un montón de ramas y una tarea cada vez más pesada cada vez que necesite fusionar nuevos cambios en mi rama maestra.
¿Cuál es la forma típica en que uno abordaría una situación como esta? Parece ser bastante común que un proyecto simplemente se abandone con los colaboradores originales que no están cerca para revisar las nuevas solicitudes de extracción. ¿Es esta una situación en la que alguien debería tomar el timón y correr con él? Parece que crearía fragmentación si los contribuyentes originales vuelven y quieren trabajar en el proyecto nuevamente.
fuente
Respuestas:
Todavía no he tenido esta situación, pero eso es lo que intentaría:
Intenta contactar al propietario
Tal vez realmente perdieron interés, pero están dispuestos a transferir el proyecto a otra persona, en particular a alguien que ya ha demostrado un compromiso considerado.
Pero tal vez solo están ocupados con otra cosa (trabajo, vacaciones, enfermedad, otros proyectos) y no tuvieron tiempo para manejar su RP, pero planean hacerlo más tarde.
O tal vez realmente han dejado de trabajar en el proyecto de forma permanente por cualquier motivo.
Sin preguntar, no lo descubrirás.
Póngase en contacto con la comunidad.
Seguramente hay otras personas que han contribuido o al menos utilizado el proyecto. Verifique quién ha bifurcado el proyecto (incluso si no han realizado ningún cambio, aún podrían estar interesados en ver este proyecto próspero); Compruebe quién ha informado de problemas o ha comentado sobre ellos Tal vez también haya una comunidad fuera de GitHub, por ejemplo, una lista de correo, un foro o miembros de StackOverflow.
Estoy eventualmente tomando el control del proyecto, es posible que desee su apoyo. Y necesitan saber dónde está el nuevo repositorio maestro.
Continuar haciendo buenas solicitudes de extracción
Esto muestra tanto al propietario como a la comunidad que usted lo toma en serio y les permite juzgar sus contribuciones.
fuente
Si el propietario del repositorio original no se encuentra en ninguna parte y está ausente durante un tiempo considerable, publicaría mi propio repositorio como una versión diferente del proyecto.
Con esto, asume el liderazgo del desarrollo de la biblioteca y no la deja morir en un rincón sin actualizarse nunca más. Si el propietario original alguna vez cierra el repositorio, el mundo aún puede usar la versión bifurcada.
fuente
fork
el proyecto y en elREADME.md
, dejar una referencia y "gracias" al propietario original.Como la mayoría de los proyectos pequeños y medianos de código abierto y gratuito de hoy en día están alojados en github, gitlab o similar, sería posible automatizar parte del proceso , utilizando sus API web.
Suponiendo que el repositorio original esté en
https://github.com/someUserX/projectY/
, el proceso podría verse así:("manual") Póngase en contacto con el autor original de diferentes maneras, al menos a través de su correo electrónico git committer y un problema (si está habilitado).
En el caso de un permiso recibido o ninguna respuesta dentro de algunas semanas, se podría ejecutar un script que utilizaría la API web de los servidores para realizar pasos como estos:
cree una nueva organización (GitHub) llamada
projectY
, y allí bifurque el repositorio original ->https://github.com/projectY/projectY/
fuente