Ciao! Mi chiamo Dmitry Pavlov e lavoro presso , e sono anche un committer e un partecipante PMC ad Apache Ignite e un collaboratore ad Apache Training. Recentemente ho tenuto una presentazione sul lavoro di un committer al meetup open source di Sberbank. Con lo sviluppo della comunità opensource, molte persone hanno cominciato sempre più ad avere domande: come diventare un committer, quali compiti svolgere e quante righe di codice devono essere scritte per ottenere questo ruolo. Quando pensiamo ai committer, immaginiamo subito persone onnipotenti e onniscienti con una corona in testa e un volume di “Clean Code” al posto dello scettro. È così? Nel mio post cercherò di rispondere a tutte le domande importanti sui committer in modo che tu possa capire se ne hai davvero bisogno.
Tutti i nuovi arrivati nella comunità opensource pensano che non diventeranno mai dei committer. Dopotutto, per molti, questo è un ruolo prestigioso che può essere ottenuto solo per meriti speciali scrivendo una tonnellata di codice. Ma non è così semplice. Diamo uno sguardo al committer dal punto di vista della comunità.
Chi è un committer e perché è necessario?
Quando creiamo un nuovo prodotto open source, consentiamo sempre agli utenti di utilizzarlo ed esplorarlo, nonché di modificare e distribuire copie modificate. Ma quando si verifica una distribuzione incontrollata di copie del software con modifiche, non riceviamo contributi alla base di codice principale e il progetto non si sviluppa. È qui che serve il committer, che ha il diritto di raccogliere i contributi degli utenti al progetto.
Perchè diventare un committer?
Partiamo dal fatto che impegnarsi è un vantaggio per un curriculum, e per i principianti nel campo della programmazione è un vantaggio ancora maggiore, perché spesso quando fanno domanda per un lavoro chiedono esempi di codice.
Il secondo indubbio vantaggio dell'impegno è l'opportunità di comunicare con i migliori specialisti e inserire alcune idee interessanti dall'open source nel tuo progetto. Inoltre, se conosci bene un determinato prodotto open source, puoi trovare lavoro presso un'azienda che lo supporta o lo utilizza. C'è persino un'opinione secondo cui se non partecipi all'open source, non otterrai posizioni di carriera elevate.
Oltre ai benefici in termini di carriera e occupazione, impegnarsi di per sé è piacevole. Sei riconosciuto dalla comunità professionale, vedi chiaramente il risultato del tuo lavoro. Non come in alcuni sviluppi aziendali, dove a volte non capisci nemmeno perché stai spostando i campi avanti e indietro in XML.
Nelle comunità opensource puoi incontrare i migliori specialisti come Linus Torvalds. Ma se non sei così, non dovresti pensare che non ci sia niente da fare lì: ci sono compiti di diversi livelli.
Ebbene, ci sono anche dei bonus aggiuntivi: i committer di Apache, ad esempio, ricevono una licenza IntelliJ Idea Ultimate gratuita (anche se con alcune restrizioni).
Cosa fare per diventare committer?
È semplice: devi solo impegnarti.
Se pensi che non ci siano compiti per te nei progetti, ti sbagli. Unisciti alla community che ti interessa e fai ciò di cui ha bisogno. L'Apache Software Foundation ha un'organizzazione separata con i requisiti per i committenti.
Quali problemi dovrai risolvere?
Il più vario: dallo sviluppo alla scrittura di test e documentazione. Sì, sì, il contributo dei tester e dei documentatori nella comunità è valutato allo stesso modo del contributo degli sviluppatori. Esistono attività non standard, ad esempio gestire un canale YouTube e spiegare ad altri utenti come utilizzi un prodotto open source. Ad esempio, la Apache Software Foundation ha un'organizzazione separata , dove è indicato quale assistenza è richiesta.
Devo scrivere una grande funzionalità per diventare un committer?
NO. Questo non è affatto necessario. Il committer non deve scrivere tonnellate di codice. Ma se hai scritto un lungometraggio importante, sarà più facile per il comitato di gestione del progetto valutarti. Contribuire alla comunità non significa solo funzionalità, programmazione e test. Se scrivi una lettera e parli di un problema, offri una soluzione ragionata: anche questo è un contributo.
È importante capire che impegnarsi è una questione di fiducia. Se renderti un committer o meno viene deciso da persone come te in base al loro punto di vista su di te come persona che apporta benefici al prodotto. Pertanto, tu, attraverso le tue azioni e azioni nella comunità, devi conquistare proprio questa fiducia.
Come comportarsi?
Sii costruttivo, positivo, educato e paziente. Ricorda che nell'open source tutti sono volontari e nessuno deve nulla a nessuno. Non ti rispondono: aspetta e ti ricordano la tua domanda entro 3-4 giorni. Non sempre ti rispondono: beh, l'open source è volontario.
Non chiedere a qualcuno di fare qualcosa per te o per te. I membri esperti della comunità hanno un istinto per questi “mendicanti” e diventano immediatamente allergici a coloro che vogliono imporre loro il loro lavoro.
Se ricevi aiuto, è fantastico, ma non abusarne. Non dovresti scrivere: "Ragazzi, sistemate questa cosa, altrimenti perdo il mio bonus annuale". È meglio chiedere dove dovresti andare dopo e dirci cosa hai già scoperto riguardo a questo bug. E se prometti di aggiornare la wiki in base ai risultati della risoluzione del problema, la probabilità che ti rispondano aumenterà in modo significativo.
Infine, leggi e imparare .
Come contribuire se non sei un committer?
I progetti spesso utilizzano uno schema RTC, in cui prima tutto viene sottoposto a revisione e quindi le modifiche vengono integrate nel master. Con questo schema, assolutamente tutti vengono sottoposti a revisione, anche i committenti. Pertanto, puoi contribuire con successo a un progetto senza essere un committer. E per rendere più semplice la selezione come nuovi committenti, puoi fare da mentore ai nuovi partecipanti, condividere conoscenze e creare nuovi materiali.
Diversità: vantaggio o danno?
Diversità: secondo l'Apache Software Foundation, questa è, tra le altre cose, l'affiliazione dei partecipanti ad un progetto opensource da parte di diverse aziende. Se tutti sono affiliati a una sola organizzazione, con la perdita di interesse per il progetto tutti i partecipanti scappano rapidamente da esso. La diversità offre progetti stabili e a lungo termine, esperienze diversificate e un’ampia gamma di opinioni dei partecipanti.
Per amore o per comodità?
Nei progetti opensource ci sono due tipi di persone: quelli che lavorano in un'organizzazione che contribuisce a questo prodotto, e quelli che lavorano qui per amore, cioè i volontari. Quale è più produttivo? In genere, i partecipanti che supportano il prodotto provengono dall'organizzazione contribuente. Hanno semplicemente più tempo e una chiara motivazione per andare a fondo della verità, sono concentrati sul compito e più vicini all'utente.
Anche chi lo fa “per amore” è motivato, ma in modo diverso: è desideroso di studiare il progetto, di rendere il mondo un posto migliore. E sono proprio questi partecipanti ad essere più stabili e orientati a lungo termine, perché coloro che sono venuti nella comunità di propria iniziativa difficilmente la lasceranno in un giorno.
Come trovare un equilibrio tra produttività e stabilità? Ci sono due opzioni. La prima opzione: quando il partecipante lavora in un'azienda ufficialmente coinvolta in questo progetto opensource e vi fa qualcosa in più, per proprio interesse, ad esempio supportando i nuovi arrivati. La seconda opzione è un'azienda che ha subito una trasformazione opensource. Ad esempio, quando i dipendenti lavorano al progetto aziendale principale quattro giorni alla settimana e il resto del tempo lavorano su open source.
Committente: essere o non essere?
Impegnarsi è un argomento buono e utile, ma non dovresti sforzarti specificatamente di diventare un committer. Questo ruolo non è un ruolo basato su codice e non dimostra le tue conoscenze. L'unica cosa che conta è la competenza, cioè la conoscenza e l'esperienza che acquisisci studiando il progetto, approfondendolo e aiutando gli altri a risolvere i problemi.
Fonte: habr.com