Quais são as maiores barreiras para percorrer o caminho do MOTU / desenvolvedor? [fechadas]

Para aqueles que não são MOTU (pessoas que mantêm os repositórios de software Universe e Multiverse ) e não têm planos da variedade "Eu aplicarei ao MOTU por $ date":

O que impede você e outras pessoas como você de tentar se tornar MOTU? O que faz você pensar que não poderia se tornar um?

Estou me referindo a barreiras sociais e tecnológicas.

EDIT: Estou apenas dizendo MOTU porque é um grupo bastante genérico, mas "por que você não está empacotando / corrigindo e pretendendo eventualmente tentar obter direitos de upload?" é uma versão ainda mais geral.

Forneça uma documentação melhor.

Participei das sessões de IRC da semana do desenvolvedor relacionadas a empacotamento e material do MOTU (duas vezes já) e descobri que durante essas sessões você normalmente tem uma compreensão vaga do processo. Mas se você olhar as páginas wiki do Ubuntu duas semanas depois, não poderá mais reunir todas as peças. Essas páginas costumam ser uma espécie de lista de marcadores de pessoas que já entendem o processo em detalhes. Mas isso não é suficiente para tornar o conteúdo compreensível para iniciantes.

Portanto, talvez você deva tentar fazer com que as páginas wiki da documentação expliquem o processo, as ferramentas e as pessoas envolvidas em mais detalhes. Ou mesmo com exemplos completos. Durante as sessões do IRC, sempre existem exemplos repetíveis, talvez aqueles que façam a diferença nas páginas da wiki.

Eu acho que a maior barreira técnica é saber como criar pacotes Debian. Embora seja relativamente simples criar um pacote de trabalho, é muito mais difícil criar pacotes de acordo com o padrão do Debian e Ubuntu. Além disso, os guias sobre como criar pacotes normalmente lidam com uma situação em que você tem o código fonte que requer compilação. Isso pode ser confuso para aplicativos escritos em idiomas interpretados.

A maior barreira social provavelmente é saber como fazer o upload de pacotes nos repositórios universo / multiverso. É muito mais simples criar seu próprio ppa e fazer upload de pacotes lá.

Atualmente, as pessoas gostam de contribuições direcionadas .

Há 20 anos, você normalmente concentra grande parte de sua energia em um projeto de estimação, se você o tiver. Hoje você visita dezenas de páginas da Internet por dia e existem muitas redes sociais ou outras comunidades, nas quais você pode contribuir com wikis, fóruns e outras coisas. Embora isso tenha feito com que mais pessoas contribuíssem, isso também levou as pessoas a esperar entradas com baixa barreira (apenas clique no site para editá-lo). Caso contrário, elas podem simplesmente recorrer a outras comunidades.

Portanto, você deve procurar barreiras no processo MOTU. Lembro-me do projeto GroundControl para reduzir a barreira para contribuições de patch em projetos hospedados na barra de ativação. Talvez você precise de novas ferramentas semelhantes, para que os novos candidatos do MOTU não precisem mexer em muitas ferramentas de linha de comando. Embora essas ferramentas atuais possam ser poderosas, provavelmente é preciso muita energia para aprender a usá-las corretamente.

A maior barreira que encontrei é a página de desenvolvedor do Ubuntu: http://www.ubuntu.com/community/get-involved/developers

Muitas vezes, decidi entusiasticamente contribuir com pelo menos 1 patch para o Ubuntu ... então vou para o lugar natural no site ... e acabo perdida em um mar de documentação. Horas depois, ainda não tenho idéia para o que devo escrever um patch. Quando olho para os bugs do Ubuntu, geralmente encontro patches ... muitos que ficam lá sem uso.

Quanto aos pacotes, tentei descobrir como fazê-los, é realmente confuso. Também tentei me envolver no Launch Pad, mas a interface é muito mais complexa que o Source Forge, não consegui obter meu próprio código no LP. É muito difícil para um novo usuário.

Ser um MOTU é uma responsabilidade .

Bem, obviamente, o motivo número 1 não é tecnicamente experiente o suficiente, e o motivo número 2 é ter um bilhão de coisas que você prefere fazer. Mas entre o seu público-alvo, acho que o principal motivo é que é uma responsabilidade.

Se eu compilar um pacote para mim, ninguém mais se importará se eu segui as políticas técnicas e legais. Ninguém virá comigo esperando que eu empacote uma versão mais recente. Ninguém vai me pedir para corrigir erros.

Se eu enviar meu pacote para um ppa, algumas pessoas podem se importar. Mas as expectativas não são tão altas. Posso simplesmente desaparecer e deixar as pessoas reclamarem em seu blog, como é triste que o pacote não esteja disponível para o natty narwhal.

Se eu me tornar um MOTU, de repente eu tenho uma grande responsabilidade. Os usuários virão até mim com relatórios de erros e reclamarão se eu não os resolver ontem. Os usuários esperam que eu carregue a nova versão do pacote assim que disponível. Vou ter que explicar aos usuários não técnicos como descobrir o que eles fizeram de errado. Ao contrário de postar em um fórum, não devo ignorar as perguntas que não tenho vontade de responder. E outros desenvolvedores podem ir atrás de mim porque eu errei alguma coisa - isso pode ser intimidador.

E o que ganho?

• Um sentimento confuso de que ajudei as pessoas. Isso pode importar. Mas se essa é minha principal motivação, como o software de embalagem pode ser comparado com a ajuda em uma cozinha de sopa ou como professor particular dos filhos de um vizinho imigrante sem emprego?

• Um ponto de bala no meu currículo? Meh, participar de um software livre como programador será muito mais apreciado. (Ele oferece experiência em coisas como gerenciamento de projetos e manutenção de longo prazo que são difíceis de ensinar nos cursos da faculdade.) De fato, ser um DD / MOTU parece suspeito para os muitos empregadores que desaprovam os funcionários envolvidos politicamente (você é abertamente dando apoio político ao FOSS).

• Um sentimento de satisfação? Muito menos do que escrever meu próprio programa a partir do zero. A programação é muito mais criativa que a embalagem. Há um grande senso de conquista nele. Há direito de se gabar. Mas na embalagem? É uma tarefa. Não é glamouroso.

(Esse é um “eu” na terceira pessoa acima. Acho que as razões que eu dou aplicam-se à maioria das pessoas, mas a extensões variadas. Pessoalmente, é principalmente ter um milhão de coisas que eu prefiro fazer e embalagens sem um senso de conquista criativa.)

(Por curiosidade, o Ubuntu não possui mão de obra?)

Idioma , meu principal problema é que ainda não estou confiante o suficiente com o inglês, sendo assim, não consigo entender facilmente o que outros desenvolvedores estão tentando me dizer

O que me impede de me tornar um MOTU?

Mesmo que o Ubuntu seja uma comunidade muito boa (ainda não fui enganado por perguntas do n00bie) eu acho que há pouca documentação / incompleta sobre o processo de empacotamento (até o Novo Guia do Mantenedor do Debian está cheio de "este tópico está fora do escopo deste documento "linhas). Se você entender esse fato e pensar em pessoas que não são a primeira língua em inglês (como eu), o processo é ainda mais difícil e caótico.

Com um simples, direto ao ponto, a documentação de tudo seria mais fácil para todos nós, mas as pessoas que têm habilidades técnicas para escrever essa documentação estão ocupadas demais para fazê-lo.

Eu acho que existem várias razões para isso. Eu também acho que as razões são frequentemente individuais.

Um dos problemas no momento é a mudança em todo o sistema MOTU. Acredito que as mudanças podem ser confusas e foram implementadas mais em linhas tecnológicas e, infelizmente, não trouxeram a comunidade totalmente a sério (talvez apenas porque é confuso).

Eu também acho que, em alguns casos, a motivação para ser um MOTU não é tão clara quanto poderia ser. IMHO, ser um MOTU é uma responsabilidade, não um privilégio. Não se trata do título, mas da capacidade de ajudar a comunidade Ubuntu pelos direitos de acesso que o acompanham. Devido a isso, pode ser que todo o processo de aprovação possa ser modificado (ou estendido). As MOTUs geralmente se nomeiam e, em seguida, o conselho verifica se estão prontas para serem MOTUs. Talvez seja possível que colegas que acreditam que alguém esteja pronto para ser um MOTU possam nomear essa pessoa. Isso IMHO representaria mais o fato de que a nomeação é feita para ajudar o processo, não para obter um título. Entendo que fazer deste o único caminho também tem seus problemas; portanto, prefiro vê-lo como uma alternativa do que o único.

Eu também sei que houve alguns problemas no passado com pessoas focando mais no KDE. Esperamos que esses problemas tenham sido resolvidos, mas talvez seja bom que isso também seja amplamente conhecido.

Obviamente, esses são apenas alguns dos problemas que tenho notado. As pessoas são diferentes e verão coisas diferentes ou serão afetadas de maneira diferente pela mesma coisa. Portanto, essas questões podem não impedir a todos, nem são as únicas razões para esse problema.

Publiquei algumas idéias aqui: http://blog.mitechie.com/2010/08/24/ubuntu-help-wanted/

Uma coisa que realmente quero destacar é: imagino quantos desenvolvedores não usam sistemas de construção que se conectam facilmente às ferramentas de empacotamento. Estou fazendo desenvolvimento python. Meu mundo gira em torno de ferramentas de instalação e distribuição e, sim, posso pegar algo que construo com elas e exportá-las, mas com que finalidade? Eu já tenho algo que pode ser distribuído. Gostaria de saber se o surgimento de linguagens de script com suas próprias ferramentas de construção / métodos de distribuição causa falta de experiência e desejo de reunir as coisas com as ferramentas de empacotamento debian e, portanto, os níveis de MOTU.

Para mim, provavelmente está relacionado ao tempo. Atualmente, não tenho muito tempo para investir. E comecei com a triagem de bugs, mas logo descobri que as coisas eram um pouco mais complicadas. E você realmente precisa afundar os dentes nele.

Depois, há a correção de bugs, que eu sei que gostaria. O que está me impedindo de ajudar por aí é que você precisa executar um ramo de desenvolvimento ou algo assim. Certa vez, comecei a trabalhar em um papercut meu no System Monitor (https://bugzilla.gnome.org/show_bug.cgi?id=611738) Então comecei a usar o Ground Control, para buscar a fonte necessária e entrar lá uma correção do bug. No entanto, acabou não sendo tão fácil, por causa das dependências. Eu sei que só devo trabalhar na versão de desenvolvimento e testar se ela está corrigida lá. No entanto, apenas para tentar, eu precisava baixar o código fonte de muitos outros pacotes do gnome. O que não é tão fácil com o controle de solo. E você provavelmente deveria fazer isso em uma máquina de trabalho. Então eu parei por aí. (Mais uma vez, levaria muito tempo, apenas para começar)

No que diz respeito à embalagem, não estou ciente de nada que precise de embalagem. Certa vez, fiz um tutorial sobre empacotamento e achei difícil demais para aplicativos pequenos. No entanto, nunca saiu à procura de uma lista de coisas que precisam de embalagem, porque eu sei que provavelmente existe uma ... :)

Então, basicamente, para mim, é apenas tempo, quero ajudar, mas só tenho algumas horas (2 ou algo assim) a cada semana ímpar. E nesse pequeno período de tempo, pareço incapaz de começar com isso.

Quando crio um pacote, geralmente é para coçar uma coceira minha, não porque alguém mais queira o pacote. O Checkinstall é bom o suficiente para fazer um pacote para mim, e então minha coceira é arranhada, e não tenho incentivo pessoal para percorrer uma distância extra para empacotá-lo manualmente e descobrir todas as dependências e outras coisas.

Portanto, acho que, mesmo que a embalagem para distribuição seja fácil, ainda há muito mais trabalho além da embalagem para você.