Come posso gestire un programmmmer difficile che si unisce a un progetto open source?

Ho uno script open source per un sito specifico (sto cercando di non chiamare nulla per nome qui) che io e alcuni altri sviluppatori abbiamo recentemente spostato su GitHub. Abbiamo ottenuto diversi nuovi sviluppatori da quando siamo passati al nuovo sistema, incluso uno molto attivo in particolare. Tuttavia, questo attivo ha iniziato a cambiare molto del progetto.

Prima di tutto, ha eliminato il nostro sistema di versioning (non come Git, ma così - l'abbiamo chiamato versioni v4.1.16) e ha detto che sarebbe meglio semplicemente inviare il codice al sito quando pensiamo che sia pronto. Ora non c'è posto centralizzato per mettere le note di rilascio, che è diventato fastidioso.

La cosa che mi ha reso quasi pronto a fare le valigie e andare è stata la sceneggiatura push. Un altro sviluppatore del progetto ha scritto un semplice script push basato su Python. Dato che teniamo online più versioni dello script in vari luoghi, ho iniziato a codificare un programma Java più grande con un'interfaccia grafica che sostituirà lo script Python. Sono andato su IRC per notificarlo a tutti e ho ricevuto una risposta molto fastidiosa dal programmatore dicendo che il vecchio script basato su Python può fare tutto ciò che il mio può fare ed è molto più leggero (ha anche commentato il fatto che pensava Python era migliore di Java e così via). Ho esaminato il codice per il vecchio script push e ho visto che nessuna delle funzionalità che diceva esistessero.

Quindi ora voglio sapere cosa fare. Ho trascorso molto del mio tempo in questo progetto, quindi non voglio solo alzarmi e andarmene, ma trovo difficile lavorare con questo nuovo sviluppatore. D'altro canto, ora è il committer numero 1 del progetto, con ancora più impegni rispetto allo sviluppatore principale. Non sono davvero sicuro di cosa fare al riguardo. Qualcun altro ha riscontrato questo problema? Se è così, cosa hai fatto?

AGGIORNAMENTO 1 : Ho disabilitato l'accesso commit di tutti e sto chiedendo alle persone di passare attraverso le richieste pull. Ho anche proposto diverse misure per risolvere le altre questioni. Tutti gli altri non hanno mostrato alcun supporto per questo. Il fastidioso dev ha semplicemente detto che le persone che non seguono da vicino la "commessa dell'azione" possono pensare che il progetto sia disorganizzato quando non lo è. Ovviamente non sono d'accordo con questo, quindi sto seriamente pensando di dimettermi dal progetto.

AGGIORNAMENTO 2 : Lo sviluppatore principale ha iniziato a lamentarsi del fatto che uno dei miei commit presumibilmente ha eliminato tre nuove righe nel codice (il commit di ripristino è apparso subito dopo aver pubblicato la discussione e non fa nemmeno riferimento al mio "commit"), quindi i due hanno iniziato a discutere se revocare il mio accesso al commit. Quindi, ho fatto la cosa logica e ho lasciato il progetto. Grazie per l'aiuto a tutti!

1. Puoi smettere. Non è la cosa più costruttiva da fare, ma a volte è l'unica opzione. Se lo fai, non sederti e lamentarti di come hai dovuto rinunciare, prendi quell'energia e mettila direttamente in qualcos'altro - "vai avanti" in altre parole.

2. Puoi rovinarlo. Non c'è motivo per cui devi lavorare con nessuno. Fork, migliora il codice e lascia che gli altri continuino ad avere un piccolo ego-fest. Il tuo nuovo progetto competerà semplicemente con il vecchio e dipende da te se riesci a riuscirci, o il vecchio ti batte in termini di utenti e funzionalità.

3. Puoi impegnarti con il resto del team di sviluppo del progetto per esprimere le tue preoccupazioni. Non renderlo personale, ma rendi conto che sei insoddisfatto della varianza del codice, della mancanza di processi di qualità stabiliti o insoddisfatto del fatto che le nuove decisioni vengano semplicemente respinte senza il consenso di tutti. Ti verrà detto che nulla è abbastanza sbagliato da cambiare, o alcuni altri saranno d'accordo con te sul fatto che il team ha bisogno di sistemare le cose. Ciò potrebbe finire con il ragazzo dirompente che perde l'accesso al commit. Forse sarete tutti d'accordo sul fatto che alcune delle modifiche non sono miglioramenti e il progetto deve essere ripristinato. (Quest'ultima opzione è il risultato più probabile, a meno che non si trasformi in una massiccia discussione di opinioni radicate).

Può essere difficile quando qualcuno arriva e cambia le routine sicure e comode a cui ti sei abituato, ma si potrebbe dire che avere qualcuno che si avvicina e scuote le vecchie e accoglienti pratiche sono cose buone in sé.

Hai reso poco chiaro esattamente quale sia il tuo ruolo qui. La risposta dipende da come ci si adatta.

Se stai guidando il progetto e controlli il repository git

Riprendi il controllo. Se questo ragazzo sta eseguendo commit che non ti piacciono senza consultarti, rimuovi il suo accesso diretto al commit. Può rovesciare il progetto e fare richieste pull per unire i suoi commit. Ecco come dovrebbe funzionare l'open source fino a quando un utente non crea fiducia. Non è necessario e non si dovrebbe dare l'accesso completo immediatamente.

Se qualcun altro controlla il repository

Esprimi le tue preoccupazioni alla persona che lo fa e incoraggia un processo più disciplinato per pianificare e approvare le modifiche. Se la leadership non è suscettibile di un processo, puoi scegliere di accettare lo status quo e continuare a contribuire, puoi forkare il progetto e lavorare sulla tua versione (portando con te chiunque sia d'accordo), oppure puoi scegliere di andartene e lavorare su altre cose. In ogni caso non ti viene richiesto di continuare a occupartene.

Per favore, perdona la mia franchezza, ma il tuo post sembra un rant.

Dici che è l'altro che vuole cambiamenti insensati, ma poi ti contraddici quando parli di questo tuo nuovo brillante programma Java.

Fare una pausa; non è una strada a senso unico, per favore cerca di trovare dei compromessi (se vuoi continuare a lavorare sul progetto - il fork è la decisione più semplice ma non ti porterà in alcun luogo utile, sebbene possa accarezzare il tuo ego).

Per favore, rifletti attentamente sulla divisione del lavoro nel progetto: le guerre per il territorio sono inevitabili se non hai confini chiari che ti dicono chi è competente in cosa . Sì, a volte devi fidarti del giudizio degli altri.

In diverse risposte è già menzionato che la divisione del lavoro è un modo per ridurre i conflitti. Ecco alcuni esempi concreti:

1. Equilibrare produttività e stabilità. Per prendere in prestito un'analogia dai giochi di strategia, una squadra deve essere composta da un mix di Boom, Turtle e Rush e i compagni di squadra devono essere pronti a cambiare ruolo in risposta alla situazione.
   • Quando uno è in una mania della produttività, altri possono lavorare su:
   • Altre caratteristiche
   • Correzione di bug
   • Specifiche (gestione di nuove richieste di funzionalità e verifica che il software soddisfi i criteri concordati)
   • Garanzia di qualità
     • Test manuali (esplorativi)
     • Test automatizzati
   • Documentazione
   • Refactoring e pulizia del codice
   • Condurre studi sugli utenti per raccogliere idee per miglioramenti
   • eccetera.
2. Un progetto può essere modulare (come nell'architettura software) o anche compartimentato (come nella gestione del progetto) in modo che ciascun modulo possa essere lavorato in modo indipendente.
   • In generale, la maggior parte dei software che contengono sia un front-end che un back-end dovrebbero essere modularizzati, poiché hanno una diversa velocità di sviluppo.
   • Il software ricco di UX può essere difficile da modulare a causa del loro uso intenso del routing di eventi tra moduli.
   • Il manutentore di un progetto potrebbe voler semplificare il progetto evitando la modularizzazione.
3. Ramo delle caratteristiche . Ogni sviluppatore può eseguire il fork del progetto, lavorare sulla sua funzione preferita per gli animali domestici e richiedere l'unione al termine dell'implementazione. Lo sviluppatore principale può avere l'ultima parola sull'accettazione della fusione.

A parte l'aspetto di prevenzione dei conflitti, è evidente che il progetto potrebbe avere una governance insufficiente .

Perché la governance è importante? Immagina un giorno che un ex compagno di squadra abbia preso un pezzo del software e abbia fatto causa alla squadra per violazione. O la squadra citata in giudizio dal troll di brevetti. O nessuno lo sa, che ha deciso di inviare avvisi DMCA al sito di hosting del progetto e richiedere la cancellazione del codice sorgente del progetto.

Come minimo:

• La licenza deve essere utilizzata da tutto il codice sorgente fornito
• Le licenze con cui è possibile pubblicare il codice sorgente del progetto
  • Nel caso in cui venga richiesta una nuova licenza pubblica, come ottenere il consenso di ogni collaboratore
• Chi può avere accesso amministrativo al progetto
• Chi sarà designato per rispondere alle richieste legali (come gli avvisi DMCA o i troll di brevetti)
• Chi gestirà i finanziamenti per il progetto (pagando le spese del server e registrando le entrate pubblicitarie o le donazioni)
• Chi avrà diritto di voto per includere nuovi membri ed espellere i membri.
• eccetera.

La maggior parte dei siti di progetto open source può fornire carte di governance del progetto già pronte.

Ho visto il problema prima. Ma dopo pochi anni ti sei davvero stancato del progetto, quindi la mia soluzione è stata quella di abbandonare il progetto . Potrebbe non funzionare per te, ma il problema è fondamentalmente che persone diverse pensano in modi diversi. Le funzionalità che ritieni molto importanti non sono affatto importanti per le altre persone.

Un buon piano sarebbe quello di dividere i compiti di persone diverse. Se riesci a concordare con le persone quale parte del progetto è sotto la responsabilità di ciascuna persona, solo una persona sta prendendo decisioni su una determinata parte del progetto. Ma il lavoro di squadra è sempre difficile. Non ti piaceranno mai le decisioni prese da altri programmatori. La migliore soluzione è non guardare mai ciò che hanno deciso gli altri programmatori. Basta fidarsi di loro per fare la cosa giusta è abbastanza.

L'obiettivo comune focalizzerà i tuoi sforzi sulle cose importanti. Tutti coloro che lavorano nella stessa direzione sono difficili da ottenere e si verificheranno comunque conflitti. Per decidere l'obiettivo comune è necessario conoscere lo stato corrente del progetto e quindi decidere dove deve trovarsi dopo un po 'di tempo.

Ecco un esempio di cose da evitare: ad esempio, un gran numero di programmatori c ++ pensa che il codice che non utilizza la libreria STL sia rotto. Altri programmatori ritengono che ogni dipendenza da librerie esterne sia interrotta, incluso STL. Tali conflitti non possono essere risolti correttamente - entrambe le situazioni non possono essere colmate simultaneamente - e le persone più problematiche spingeranno la loro opinione indipendentemente dall'opposizione che incontreranno.

Quattro scelte, credo.

1. Buttalo fuori. Sei (presumibilmente) ancora il principale amico di questo progetto; revoca i suoi privilegi push e chiamalo un giorno. Il risultato più probabile è che lui biforcasse il progetto, dividendo la sua comunità, e poi scoppiò una guerra, e quando la polvere si depositerà, una delle forcelle sarà quella popolare.
2. Biforcalo e continua altrove. Meno aggressivo di 1., ma le conseguenze sono comunque le stesse. Dovrai essere attivo nella comunità per attirare le persone dalla tua parte.
3. Lascia stare: lascia che faccia quello che sta facendo, calmati e spera per il meglio.
4. Discutere con la comunità, scendere a compromessi se necessario e risolvere la situazione.

Personalmente, preferirei l'opzione 4.

Google ne ha parlato un paio di volte alcuni anni fa. Guardali:1 ,2 . In breve:

1. Comprendere : Capire la motivazione della vostra comunità per lavorare al vostro progetto vs tutti gli altri costi di opportunità, e conservare tali motivi.
2. Fortifica : costruisci una comunità sana con norme sociali di educazione, rispetto, fiducia e umiltà.
3. Identifica : cerca segni rivelatori di persone velenose (troppe da elencare, ma se stai ponendo questa domanda probabilmente ne conosci già molte).
4. Disinfetta : sii calmo e difendi la tua posizione, non reagire a insulti, insulti, sfide, mancanza di rispetto, ecc. E persevera nel rafforzare le norme della tua comunità.

È disponibile anche una descrizione scritta completa se si preferisce leggere invece di guardare.

Non puoi semplicemente smettere senza fare uno sforzo per esprimere le tue preoccupazioni e difficoltà. So che può essere difficile. Infatti, se tu e i membri del tuo team siete abbastanza giovani da non sperimentare in prima persona molti problemi sociali che si verificano in qualsiasi team di sviluppo, può essere davvero difficile.

Detto questo, credo fermamente che dovresti esprimere le tue preoccupazioni. Puoi scriverli nell'e-mail e mostrarlo ai tuoi amici fidati che non fanno parte del team e non hanno o poco interesse per quello che fai. In questo caso potresti ricevere un buon feedback in modo che il testo della tua email non sia troppo duro. Attenersi ai fatti però. Non accusare o incolpare. Solo fatti che è difficile fare qualcosa per te perché manca "blah". Perché manchi "blah" dovrebbe essere chiaro a tutti i membri del team, vale a dire "il nuovo programmatore" cancellato o non ha ottenuto risultati.

Ancora una volta, l'invio di questa e-mail è difficile ma è di per sé un'ottima esperienza che può essere molto utile per il tuo futuro. Ottima lezione da imparare.

PS: non intendevo sembrare troppo genitoriale. Tuttavia è davvero qualcosa che direi a chiunque, compresi i miei figli.