So che il consiglio predefinito per i progetti open source, e per iniziare, è quello di iniziare a correggere i bug. Ma ho la sensazione che sia il percorso che si vorrebbe fare se volessero essere un tester / fixer di bug nel progetto. Come si diventa collaboratori attivi di un progetto opensource? [Vale a dire a livello di architettura]
Probabilmente sembrerà un po 'una tautologia, ma se vuoi diventare un importante contributore di nuove funzionalità, usa il prodotto per un po', trova una nuova funzionalità che lo migliori, scrivi il codice per implementare la funzione e contribuirla.
Il motivo per cui alla gente si consiglia di iniziare con correzioni di errori è quello che li fa scavare nella base di codice e familiarizzare con il modo in cui funzionano le cose. Ciò ti porterà anche a partecipare alla comunità di discussione del progetto, qualunque essa sia, (di solito una mailing list o forum), così avrai un'idea della direzione del progetto. Ti sentiresti un po 'sciocco se ottieni l'80% del modo con la tua nuova funzione solo per scoprire che qualcun altro ci ha lavorato da sempre e l'hanno appena finito!
Non ci sono scorciatoie. I progetti open source sono estremamente basati sul merito. Quando avrai dimostrato di essere in grado di gestire attività più piccole, alla fine ti sarai fidato di compiti sempre più grandi. I progetti open source hanno anche molta spinta da parte dei contributori che contribuiscono con una o due patch per poi andare avanti, e anche altre persone che "contribuiscono" con una o due idee grandiose, ma non implementate, proseguono. Se vuoi contribuire in modo più ampio, devi mostrare che ci sei dentro per il lungo periodo.
Detto questo, i miglioramenti architettonici incrementali sono spesso benvenuti, specialmente se risolvono un bug o un problema di prestazioni. Ad esempio, diversi anni fa una delle poche patch che ho contribuito al progetto Cinelerra è stata una modifica architettonica allo stack di annullamento che ha ridotto significativamente consumo di memoria e latenza per operazioni annullabili.
Troverai il maggior successo se stai risolvendo un problema che stai affrontando personalmente, piuttosto che limitarti a "diventare un collaboratore di un progetto open source". Quando ho inviato quella patch a Cinelerra, non stavo cercando di contribuire con una modifica architettonica a un progetto open source scelto a caso, stavo cercando di capire perché ci fosse voluto così tanto tempo per spostare un punto di entrata / uscita quando si modificavano i miei video.
Puoi farlo conoscendo quelli che già si trovano in quella posizione e dimostrando interesse a unirsi a loro, il che è meglio farlo risolvendo bug, individuando bug e partecipando allo sviluppo.
Leggi altre domande sui tag teamwork open-source contribution