Quali sono le maggiori barriere per percorrere il percorso MOTU / sviluppatore? [chiuso]

Per coloro che non sono MOTU (persone che mantengono i repository di software Universo e Multiverso ) e non hanno piani per la varietà "Applicherò a MOTU entro $ date":

Cosa impedisce a te e agli altri come te di provare a diventare MOTU? Cosa ti fa pensare di non poterlo diventare?

Mi riferisco a barriere sociali e tecnologiche.

EDIT: Sto solo dicendo MOTU perché è un gruppo piuttosto generico, ma "perché non stai confezionando / patch e intendi eventualmente provare per i diritti di upload?" è una versione ancora più generale.

Fornire una migliore documentazione.

Ho preso parte alle settimane degli sviluppatori delle sessioni IRC relative al packaging e alle cose MOTU (già due volte) e ho scoperto che durante quelle sessioni in genere hai una vaga comprensione del processo. Ma se guardi le pagine della wiki di Ubuntu due settimane dopo, non puoi più mettere insieme tutti i pezzi. Quelle pagine sono spesso una specie di elenco di punti elenco di persone che già comprendono il processo in dettaglio. Ma questo non è abbastanza per rendere comprensibile il contenuto per i neofiti.

Quindi forse dovresti provare a ottenere la documentazione che le pagine wiki spiegano il processo, gli strumenti e le persone coinvolte in modo più dettagliato. O anche con esempi completi. Durante le sessioni IRC ci sono sempre esempi ripetibili, forse quelli fanno la differenza per le pagine wiki.

Penso che il più grande ostacolo tecnico sia sapere come creare pacchetti Debian. Sebbene sia relativamente semplice creare un pacchetto funzionante, è molto più difficile creare pacchetti fino allo standard di Debian e Ubuntu. Inoltre, le guide su come creare pacchetti normalmente affrontano una situazione in cui si dispone del codice sorgente che richiede la compilazione. Questo può essere fonte di confusione per le applicazioni scritte in lingue interpretate.

La più grande barriera sociale è probabilmente quella di ottenere i pacchetti caricati nei repository universo / multiverso. È molto più semplice creare il tuo ppa e caricare pacchetti lì.

Oggi alle persone piacciono i contributi drive-by .

20 anni fa in genere concentreresti molta energia su un progetto per animali domestici, se ne avessi uno. Oggi visiti dozzine di pagine Internet al giorno e ci sono molti social network o altre comunità, dove puoi contribuire a wiki, forum e altre cose. Mentre questo ha portato a un maggior numero di persone che hanno contribuito, ha anche portato le persone ad aspettarsi iscrizioni a bassa barriera (a la "basta fare clic sul sito Web per modificarlo). Altrimenti potrebbero semplicemente rivolgersi ad altre comunità.

Pertanto, dovresti cercare barriere nel processo MOTU. Ricordo il progetto GroundControl per abbassare la barriera per i contributi patch nei progetti ospitati da launchpad. Forse hai bisogno di nuovi strumenti simili, quindi i nuovi candidati MOTU non devono giocherellare con molti strumenti da riga di comando. Sebbene questi strumenti attuali possano essere potenti, probabilmente ci vuole molta energia per imparare a usarli correttamente.

La più grande barriera che ho trovato è la pagina degli sviluppatori Ubuntu: http://www.ubuntu.com/community/get-involved/developers

Tante volte, sono stato entusiasta di contribuire con almeno 1 patch a Ubuntu ... quindi vado nel luogo naturale sul sito Web ... e finisco per perdersi in un mare di documentazione. Ore dopo, non ho ancora idea di cosa dovrei scrivere una patch. Quando guardo attraverso i bug di Ubuntu, trovo spesso patch ... molti che rimangono semplicemente inutilizzati.

Per quanto riguarda i pacchetti, ho cercato di capire come realizzarli, è davvero confuso. Ho anche cercato di essere coinvolto in Launch Pad, ma l'interfaccia è molto più complessa di Source Forge, non ho potuto ottenere il mio codice su LP. È molto difficile per un nuovo utente.

Essere un MOTU è una responsabilità .

Bene, ovviamente il motivo n. 1 non è abbastanza ben informato dal punto di vista tecnico e il motivo n. 2 sta avendo un miliardo di cose che preferiresti fare. Ma tra il tuo pubblico target, penso che il motivo principale sia che sia una responsabilità.

Se compilo un pacchetto per me stesso, a nessuno importa se ho seguito le politiche tecniche e legali. Nessuno verrà da me aspettandomi di creare una nuova versione del pacchetto. Nessuno mi chiederà di correggere i bug.

Se carico il mio pacchetto su un ppa, ad alcune persone potrebbe interessare. Ma le aspettative non sono così alte. Posso semplicemente svanire e lasciare che le persone si lamentino sul loro blog quanto sia triste che il pacchetto non sia disponibile per natty narwhal.

Se divento un MOTU, improvvisamente ho una grande responsabilità. Gli utenti verranno da me con segnalazioni di bug e si lamentano se non li risolvo ieri. Gli utenti si aspettano che io carichi la nuova versione del pacchetto non appena sarà disponibile a monte. Dovrò spiegare agli utenti non tecnici come capire cosa hanno fatto di sbagliato. A differenza della pubblicazione su un forum, non dovrei ignorare le domande a cui non ho voglia di rispondere. E altri sviluppatori potrebbero seguirmi perché ho incasinato qualcosa - questo può essere intimidatorio.

E cosa ottengo?

• Una sensazione confusa di aver aiutato le persone. Questo può importare. Ma se questa è la mia motivazione principale, in che modo il software di packaging può essere paragonato all'aiuto in una mensa o al tutoraggio dei figli del vicino immigrato senza lavoro?

• Un punto elenco sul mio curriculum? Meh, partecipare a un FOSS come programmatore sarà molto più apprezzato. (Ti dà esperienza con cose come la gestione dei progetti e la manutenzione a lungo termine che sono difficili da insegnare nei corsi universitari.) In effetti, essere un DD / MOTU sembra sospetto per i molti datori di lavoro che aggrottano le sopracciglia sui dipendenti coinvolti politicamente (sei dare apertamente sostegno politico a FOSS).

• Una sensazione di soddisfazione? Molto meno che scrivere il mio programma da zero sarebbe. La programmazione è molto più creativa del packaging. C'è un grande senso di successo in esso. Ci sono diritti di vantarsi. Ma nella confezione? È un lavoro ingrato. Non è glamour.

(Questa è una "I" di terza persona sopra. Penso che i motivi che do valgano per la maggior parte delle persone, ma in misura diversa. Personalmente ha principalmente un miliardo di cose che preferirei fare, e il packaging manca di un senso di realizzazione creativa.)

(Per curiosità, Ubuntu non ha manodopera?)

Lingua , il mio problema principale è che non sono ancora abbastanza sicuro dell'inglese, essendo così, non riesco a capire facilmente cosa gli altri sviluppatori stanno cercando di dirmi

Cosa mi impedisce di diventare un MOTU?

Anche se Ubuntu è una comunità molto bella (non sono ancora stato criticato per le domande su n00bie) Penso che ci sia poca / documentazione incompleta sul processo di packaging (anche la nuova guida per i manutentori di Debian è piena di "questo argomento non rientra nell'ambito di applicazione di questo documento "righe). Se prendi questo fatto e pensi alle persone che la prima lingua non è l'inglese (come me) il processo è ancora più difficile e caotico.

Con una documentazione semplice e precisa, ogni cosa sarebbe più semplice per tutti noi, ma le persone che hanno le competenze tecniche per scrivere quella documentazione sono troppo impegnate per farlo.

Penso che ci siano diverse ragioni per questo. Penso anche che le ragioni siano spesso individuali.

Uno dei problemi in questo momento, è il cambiamento nell'intero sistema MOTU. Credo che i cambiamenti possano essere fonte di confusione, e sono stati implementati maggiormente sulle linee tecnologiche e sfortunatamente non hanno portato la comunità pienamente a bordo (forse solo perché è confusa).

Penso anche che, in alcuni casi, la motivazione per diventare un MOTU non sia così chiara come potrebbe essere. IMHO, essere un MOTU è una responsabilità, non un privilegio. Non si tratta del titolo, ma della capacità di aiutare la comunità Ubuntu con i diritti di accesso che ne derivano. Per questo motivo, potrebbe essere possibile modificare (o estendere) l'intero processo di approvazione. I MOTU di solito si nominano, e quindi la scheda cerca se sono pronti per essere MOTU. Forse dovrebbe essere possibile che i colleghi che credono che qualcuno sia pronto a diventare un MOTU possano nominare quella persona. Ciò significherebbe che l'IMHO rappresenta più il fatto che la nomina viene fatta per aiutare il processo, non per ottenere un titolo. Capisco che rendere questo l'unico modo abbia anche i suoi problemi, quindi, preferisco vederlo come un'alternativa, quindi l'unico modo.

So anche che ci sono stati alcuni problemi in passato con persone che si concentravano maggiormente su KDE. Si spera che questi problemi siano stati affrontati, ma forse sarebbe positivo se ciò fosse anche più ampiamente conosciuto.

Ovviamente, questi sono solo un paio di problemi che ho notato. Le persone sono diverse e vedranno cose diverse o saranno influenzate in modo diverso dalla stessa cosa. Quindi, questi problemi potrebbero non fermare tutti, né sono gli unici motivi di questo problema.

Ho pubblicato alcune idee qui: http://blog.mitechie.com/2010/08/24/ubuntu-help-wanted/

Una cosa che voglio davvero far emergere è che mi chiedo quanti sviluppatori non usano sistemi di compilazione che si collegano facilmente agli strumenti di packaging. Sto facendo lo sviluppo di Python. Il mio mondo è incentrato su setuptools e distribuire, e sì, posso prendere qualcosa che costruisco con quelli ed esportarlo, ma a che scopo? Ho già qualcosa che è distribuibile. Mi chiedo se l'ascesa dei linguaggi di scripting con i propri strumenti di costruzione / metodi di distribuzione causi una mancanza di esperienza e desiderio nel mettere insieme le cose con gli strumenti di packaging debian e quindi i livelli MOTU.

Per me è probabilmente legato al tempo. Al momento non ho molto tempo da investire. E ho iniziato con il bug triaging, ma presto ho scoperto che le cose erano un po 'più complicate. E devi davvero affondarci i denti.

Poi c'è la correzione dei bug, che so che mi piacerebbe. Ciò che mi impedisce di dare una mano, è che devi gestire un ramo di sviluppo o qualcosa del genere. Una volta ho iniziato a lavorare su un mio papercut nel Monitor di sistema (https://bugzilla.gnome.org/show_bug.cgi?id=611738) Quindi ho iniziato a usare Ground Control, per recuperare la fonte richiesta ed entrare una correzione del bug. Tuttavia, si è rivelato non essere così facile, a causa delle dipendenze. So che dovrei lavorare solo sulla versione di sviluppo e testare se è stato risolto lì. Tuttavia, solo per provare che avevo bisogno di scaricare la fonte di molti altri pacchetti gnome. Che non è così facile con groundcontrol. E probabilmente dovresti farlo su una macchina da lavoro. Quindi mi sono fermato lì. (Ancora una volta mi ci vorrebbe troppo tempo, solo per iniziare per questo)

Per quanto riguarda gli imballaggi, non sono a conoscenza di nulla che abbia bisogno di imballaggi. Una volta ho fatto un tutorial sull'imballaggio e non l'ho trovato troppo difficile per le piccole applicazioni. Tuttavia non sono mai uscito alla ricerca di un elenco di cose che necessitano di imballaggio, perché so che probabilmente ce n'è uno ... :)

Quindi in pratica per me è solo il momento, voglio dare una mano, ma ho solo un paio d'ore (2 o qualcosa del genere) ogni settimana o due. E in quel lasso di tempo mi sembra di non essere in grado di iniziare con questo.

Quando creo un pacchetto, di solito è per grattarmi un prurito, non perché qualcun altro vuole il pacchetto. Checkinstall è abbastanza buono da creare un pacchetto per me, quindi il mio prurito è graffiato e non ho alcun incentivo personale per andare oltre la distanza per impacchettarlo manualmente e capire tutte le dipendenze e le cose.

Quindi immagino che anche se l'imballaggio per la distribuzione è facile, è ancora molto più lavoro oltre l'imballaggio per te stesso.