Qual è il protocollo da seguire se desidero apportare modifiche significative al software nel repository github pubblico di qualcun altro?

La mia impressione è che tu possa, se vuoi, contattare l'autore e vedere se sarebbero interessati al cambiamento. Probabilmente vorranno avere un'idea del tipo di modifiche che si desidera apportare e probabilmente vorranno un piccolo esempio del refactoring. Questo presuppone che siano persino aperti all'idea. Possono avere ragioni (buone o cattive) per fare le cose nel modo in cui le stanno facendo attualmente, ad es. prestazioni, preferenze essenzialmente ideologiche, o il loro conforto con le tecniche che vuoi usare. Anche se sono d'accordo con te sul fatto che i tuoi cambiamenti potrebbero essere utili, il progetto potrebbe trovarsi in uno stato stabile in cui un atteggiamento "se non è rotto, non aggiustarlo" non è irragionevole. C'è la possibilità che ti offrano di aggiungerti come manutentore, o anche di offrirti di farti diventare il manutentore, se non sono particolarmente interessati a essere responsabili del codice e credono che tu sia disposto e in grado di assumerti la responsabilità . Questo probabilmente non accadrà immediatamente però.

Quanto sopra è necessario se vuoi che i manutentori attuali prendano le tue modifiche nella loro versione. Non è necessario se non ti interessa particolarmente. In tal caso, puoi semplicemente fare una forchetta e fare qualsiasi cosa fintanto che la licenza lo consente. Se la forcella è principalmente per uso personale, probabilmente non ne saranno nemmeno a conoscenza. Se la promuovi come alternativa alla libreria originale, allora i manutentori originali probabilmente non saranno contenti se non hai comunicato con loro in anticipo, e potrebbero non essere felici in entrambi i modi (anche se ciò sarà probabilmente ovvio in anticipo se tu comunicato con loro in anticipo). Detto questo, finché si seguono i termini della licenza, non possono fermarti. Le terze parti potrebbero anche non essere soddisfatte delle biforcazioni inutili in quanto aggiungono rumore all'ecosistema, rendendo più difficile la ricerca di librerie gestite e di qualità.

D'altra parte, non è chiaro il motivo per cui vuoi anche farlo. Viene in gran parte come non ti piace il modo in cui lo hanno codificato, e lo avresti fatto diversamente. Non vedo perché questo dovrebbe essere importante per te come consumatore. Tecnicamente, un refactoring è una semantica che preserva il cambiamento, e quindi se i tuoi cambiamenti fossero davvero dei refactoring, non farebbe differenza per i consumatori a valle. Tuttavia, sospetto che tu stia usando il termine in un senso più ampio e ciò che desideri realmente è un'API diversa per la libreria. Potrebbe essere possibile farlo come un wrapper attorno alla libreria esistente, nel qual caso non è necessario coordinarsi con i manutentori attuali e il carico di manutenzione su di te per il wrapper sarà probabilmente significativamente inferiore.

Hai effettivamente accesso in scrittura a questo repository?

Il modo per farlo sarebbe quello di fare una modifica che sia abbastanza piccola da essere rivista, e quindi di pubblicare una richiesta di pull in modo che qualcuno possa rivedere la tua modifica e unirla nel repository. E poi fai il prossimo cambiamento e così via.

O forzi il repository. Prendilo così com'è, fai una copia e quella copia è tua. In teoria, fai ciò che vuoi. In pratica, fai esattamente quello che ho detto nel mio primo paragrafo, tranne il fatto che puoi essere tu stesso il recensore se non trovi qualcuno che lo faccia.

Ciò che è essenziale è che dopo ogni cambiamento di questo tipo, si prova abbastanza per essere sicuri che tutto funzioni ancora come dovrebbe. Perché pianifichi di fare grandi cambiamenti, quindi se trovi due mesi dopo che alcuni cambiamenti sono stati piuttosto sciatti, hai un problema. Scrivere i test che passano prima e dopo le modifiche aiuta.