Come faccio a gestire un programmatore difficile che si unisce a un progetto open source?

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

2. Puoi cambiarlo. Non c'è motivo per cui devi lavorare con nessuno. Forchetta, migliora il codice e lascia che gli altri continuino ad avere un piccolo ego-fest per conto proprio. Il tuo nuovo progetto sarà semplicemente in competizione con il vecchio e sta a te decidere se ci riesci o se il vecchio ti batte in termini di utenti e funzionalità.

3. Puoi coinvolgere con il resto del team di sviluppo sul progetto per esprimere le tue preoccupazioni. Non renderlo personale, ma fai finta di non essere soddisfatto del code churn, o della mancanza di processi di qualità consolidati, o di essere infelice che le nuove decisioni vengano semplicemente eliminate senza l'accordo di tutti. Ti verrà detto che non c'è niente che non va abbastanza da cambiare, o che alcuni altri saranno d'accordo con te sul fatto che il team ha bisogno di sistemare le cose. Ciò potrebbe finire con il ragazzo distruttivo perdere il suo accesso di 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 trincerate.)

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

Hai reso poco chiaro esattamente quale sia il tuo ruolo qui. La risposta dipende da come ti adatti.

Se guidi il progetto e controlli il repository git

Riprendi il controllo. Se questo tizio commette dei commit che non ti piacciono senza consultarti, rimuovi il suo accesso diretto al commit. Può biforcare il progetto e fare richieste di pull per unire i suoi commit. Ecco come l'open source dovrebbe funzionare finché un utente non crea fiducia. Non è necessario, e non dovrebbe, concedere 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 è adatta a un processo, allora puoi scegliere di accettare lo status quo e continuare a contribuire, puoi biforcare il progetto e lavorare sulla tua versione (portando con te chiunque sia d'accordo con te), oppure puoi scegliere di andartene e lavorare su altre cose. In ogni caso non sei obbligato a continuare ad occupartene.

Per favore perdona la mia schiettezza, ma il tuo post si legge come uno sballo.

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

Fai una pausa; non è una strada a senso unico, prova a trovare compromessi (se vuoi continuare a lavorare sul progetto - la forking è la decisione più semplice ma non ti porterà in nessun posto utile, anche se potrebbe essere un ictus il tuo ego).

Per favore, pensa anche alla divisione del lavoro nel progetto - Le guerre di torba sono inevitabili se non hai confini chiari che ti dicono chi è competente in ciò che . Sì, devi fidarti del giudizio altrui a volte.

È già stato menzionato in diverse risposte che la divisione del lavoro è un modo per ridurre il conflitto. Ecco alcuni esempi concreti:

1. Equilibrio tra produttività e stabilità. Per prendere in prestito un'analogia dai giochi di strategia, una squadra deve consistere in un mix di Boom, Turtle and Rush e i compagni di squadra devono essere pronti a cambiare ruolo in risposta alla situazione.
   • Quando si è in una mania di produttività, altri possono lavorare su:
   • Altre funzionalità
   • Correzione di bug
   • Specifiche (gestire nuove richieste di funzionalità e verificare che il software soddisfi i criteri concordati)
   • Garanzia della qualità
     • Test manuale (esplorativo)
     • Test automatici
   • Documentazione
   • Rifacimento e pulizia del codice
   • Conduci studi sugli utenti per raccogliere idee per miglioramenti
   • ecc.
2. Un progetto può essere modularizzato (come nell'architettura software), o anche compartimentato (come nella gestione del progetto) in modo che ogni modulo possa essere lavorato indipendentemente.
   • In generale, la maggior parte del software che contiene sia un front-end che un back-end dovrebbe essere modularizzata, perché hanno una velocità di sviluppo diversa.
   • Il software ricco di UX potrebbe essere difficile da modulare a causa del loro uso intensivo del routing di eventi tra moduli.
   • Il manutentore di un progetto potrebbe voler mantenere il progetto semplice evitando la modularizzazione.
3. Ramo di funzionalità . Ogni sviluppatore può biforcare il progetto, lavorare sulla sua caratteristica animale preferita e richiedere l'unione quando l'implementazione è completa. Lo sviluppatore principale può avere l'ultima parola sull'accettazione dell'unione.

Oltre all'aspetto di evitare i conflitti, è evidente che il progetto potrebbe non avere governance .

Perché la governance è importante? Immagina un giorno che un ex compagno di squadra abbia preso un pezzo del software e abbia citato in giudizio la squadra per violazione. O il team ha fatto causa al brevetto Troll. O chi non sa chi ha deciso di inviare notifiche DMCA al sito di hosting del progetto e richiedere la cancellazione del codice sorgente del progetto.

Al minimo:

• La licenza da utilizzare per tutti i codici sorgente contribuiti
• 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 da ogni contributore
• Chi può avere accesso amministrativo al progetto
• Chi sarà designato per rispondere alle richieste legali (come le comunicazioni DMCA oi troll dei brevetti)
• Chi gestirà la finanza per il progetto (pagando per le spese del server e la contabilità le entrate o le donazioni della pubblicità)
• Chi avrà i diritti di voto per includere nuovi membri ed espellere i membri.
• ecc.

La maggior parte dei siti di progetti open source è in grado di fornire carte di governance del progetto già pronte.

Ho già visto il problema prima. Ma dopo pochi anni sei davvero stanco del progetto, quindi la mia soluzione era quella di lasciare il progetto . Potrebbe non funzionare per te, ma il problema è fondamentalmente che persone diverse pensano in modi diversi. Le funzioni che ritieni siano molto importanti non sono affatto importanti per gli altri.

Un buon piano sarebbe quello di dividere i compiti di persone diverse. Se puoi essere d'accordo con le persone su quale parte del progetto è responsabilità di ciascuno, allora solo una persona sta prendendo decisioni su una certa parte del progetto. Ma il lavoro di squadra è sempre difficile. Non ti piaceranno mai le decisioni prese da altri programmatori. La soluzione migliore è non guardare mai a ciò che altri programmatori hanno deciso. Basta fidarsi di loro per fare la cosa giusta è sufficiente.

Obiettivo comune concentrerà i tuoi sforzi sulle cose importanti. Chiunque lavori nella stessa direzione è difficile da ottenere, e comunque i conflitti si verificano. Decidere un obiettivo comune richiede conoscere quale sia lo stato attuale del progetto e poi decidere dove deve essere 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 sta usando la libreria STL sia rotto. Altri programmatori pensano che ogni dipendenza dalle librerie esterne sia rotta, incluso STL. Tali conflitti non possono essere risolti correttamente - entrambe le situazioni non possono essere soddisfatte simultaneamente - e le persone più problematiche spingono la loro opinione indipendentemente dall'opposizione che incontreranno.

Quattro scelte, direi.

1. Buttalo fuori. Sei (presumibilmente) ancora il principale tizio di questo progetto; revocare i suoi privilegi push e chiamarlo un giorno. Il risultato più probabile è che biforca il progetto, dividendo la sua comunità, e poi una guerra si scatena, e quando la polvere si deposita, una delle forcelle sarà quella popolare.
2. Forcela e continua altrove. Meno aggressivo di 1., ma le conseguenze sono le stesse. Dovrai essere attivo nella comunità per portare le persone dalla tua parte.
3. Lascia stare: lasciagli fare quello che sta facendo, calmati e spera per il meglio.
4. Discutere con la comunità, scendere a compromessi come richiesto e risolvere la situazione.

Personalmente, preferirei l'opzione 4.

Google ha avuto un paio di discorsi tecnici su questo qualche anno fa. Guardali: 1 , 2 . In poche parole:

1. Comprendi : comprendi la motivazione della tua comunità a lavorare sul tuo progetto rispetto a tutti gli altri costi di opportunità e a preservare tali motivi.
2. Fortifica : crea una comunità sana con norme sociali di cortesia, rispetto, fiducia e umiltà.
3. Identifica : cerca i segni rivelatori di persone velenose (troppi per elencarli, ma se stai facendo questa domanda probabilmente ne conosci già molti).
4. Disinfetti : sii calmo e ferma la tua posizione, non reagire agli insulti, alle offese, alle sfide, alla mancanza di rispetto, ecc. e persistente nel rinforzare le norme della tua comunità.

Un schema scritto completo è disponibile anche se preferisci leggere anziché guardare.

Non puoi semplicemente smettere senza impegnarti a esprimere le tue preoccupazioni e le tue difficoltà. So che può essere difficile. Se, infatti, se voi e i membri del vostro team siete abbastanza giovani da non provare 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 mostrarli ai tuoi amici fidati che non fanno parte del team e che non hanno o hanno poco interesse in quello che fai. In questo caso potresti ricevere un buon feedback in modo che la formulazione della tua email non sia troppo severa. Attenersi comunque ai fatti. Non accusare o incolpare. Solo fatti che è difficile fare qualcosa per te perché manca "blah". Perché "blah" sia mancante dovrebbe essere chiaro a tutti i membri del team, ad esempio "il nuovo programmatore" cancellato o non ha realizzato qualcosa.

Ancora una volta, inviare questa e-mail è difficile ma è di per sé una grande esperienza che potrebbe essere molto utile per il futuro. Grande lezione da imparare.

PS: non volevo sembrare troppo genitoriale. Comunque è davvero qualcosa che vorrei dire a chiunque compresi i miei figli.