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

Question

Para aqueles que não são MOTU (pessoas que mantêm o software Universe e Multiverse repositórios ) e não possuem planos da variedade" Eu aplicarei a MOTU by $ date ":

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

Estou me referindo às barreiras sociais e tecnológicas.

EDITAR: Eu só estou dizendo MOTU porque é um grupo bastante genérico, mas "por que você não está empacotando / remendando e pretendendo tentar por direitos de upload?" é uma versão ainda mais geral.

    

Answer 1

Forneça documentação melhor.

Eu participei das semanas de desenvolvedor de sessões de IRC relacionadas ao material de embalagem e 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 conseguirá mais reunir todas as partes. Essas páginas geralmente são 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.

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

    

Answer 2

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 até o padrão do Debian e do Ubuntu. Além disso, os guias sobre como criar pacotes normalmente lidam com uma situação na qual você possui o código-fonte que requer compilação. Isso pode ser confuso para aplicativos escritos em linguagens interpretadas.

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

    

Answer 3

Hoje em dia, pessoas gostam de contribuições de drive-by .

20 anos atrás, você normalmente concentraria grande parte de sua energia em um projeto de animal de estimação, se tivesse um. Hoje você visita dezenas de páginas da Internet por dia, e há muitas redes sociais ou outras comunidades, onde você pode contribuir com wikis, fóruns e outras coisas. Embora isso tenha contribuído para que mais pessoas contribuíssem, isso também levou as pessoas a esperarem baixas entradas de barreira (a la "basta clicar no site para editá-lo). Caso contrário, elas podem se voltar para outras comunidades.

Portanto, você deve procurar barreiras no processo MOTU. Eu me lembro do projeto GroundControl para diminuir a barreira para contribuições de patch nos projetos hospedados no launchpad. Talvez você precise de novas ferramentas semelhantes, então novos candidatos a MOTU não precisam 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.

    

Answer 4

A maior barreira que encontrei é a página do desenvolvedor do Ubuntu: link

Tantas vezes, eu fiquei determinado a contribuir com pelo menos um patch para o Ubuntu ... então eu vou para o lugar natural no site ... e acabo perdido em um mar de documentação. Horas depois, ainda não tenho ideia do que devo escrever para o patch. Quando eu olho através de bugs do Ubuntu, muitas vezes eu encontro patches ... muitos que apenas ficam lá sem uso.

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

    

Answer 5

Ser um MOTU é uma responsabilidade .

Bem, obviamente, a razão # 1 não é tecnicamente bem informada, e a razão # 2 é ter um zilhão de coisas que você preferiria 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 importa se eu segui as políticas técnicas e legais. Ninguém virá a mim esperando que eu empacote uma nova versão. Ninguém vai me pedir para consertar bugs.

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

Se eu me tornar um MOTU, de repente eu tenho uma grande responsabilidade. Os usuários virão até mim com relatórios de bugs e reclamarão se eu não resolvê-los ontem. Os usuários esperam que eu faça o upload da nova versão do pacote assim que estiver disponível para o envio. Vou ter que explicar para usuários não técnicos como descobrir o que eles fizeram de errado. Ao contrário de postar em um fórum, eu não deveria ignorar as perguntas que não tenho vontade de responder. E outros desenvolvedores podem ir atrás de mim porque eu estraguei alguma coisa - isso pode ser intimidante.

E o que ganho?

• Uma sensação confusa de que ajudei pessoas. Isso pode importar. Mas se essa é a minha principal motivação, como o software de embalagem pode comparar-se com a ajuda em uma cozinha de sopa ou com a ajuda de seus filhos de vizinhos imigrantes desempregados?

• Um ponto no meu currículo? Meh, participando de um software livre como programador será muito mais apreciado. (Isso lhe dá experiência com coisas como gerenciamento de projetos e manutenção de longo prazo que são difíceis de ensinar em cursos universitários.) Na verdade, ser um DD / MOTU parece suspeito para muitos empregadores que desaprovam empregados politicamente envolvidos (você está dando abertamente apoio político ao software livre).

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

(Essa é uma terceira pessoa "eu" acima. Acho que as razões que aplicoi aplicam-se à maioria das pessoas, mas em graus variados. Pessoalmente, é principalmente ter um bilhão de coisas que prefiro fazer, e embalagem sem sentido de realização criativa .)

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

    

Answer 6

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

    

Answer 7

O que me impede de me tornar um MOTU?

Embora o Ubuntu seja uma comunidade muito boa (eu não fui criticado por questões nobre, ainda) eu acho que há poucas / incompletas documentações sobre o processo de empacotamento (mesmo o Novo Guia do Mantenedor do Debian está cheio de do escopo deste documento "linhas". Se você pegar esse fato e pensar em pessoas cuja primeira língua não é o inglês (como eu), o processo é ainda mais difícil e caótico.

Com um simples, direto ao ponto, a documentação de cada coisa 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.

    

Answer 8

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

Um dos problemas neste momento é a mudança em todo o sistema MOTU. Eu acredito, as mudanças podem ser confusas, e foram implementadas mais em linhas tecnológicas e, infelizmente, não trouxeram a comunidade totalmente a bordo (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, sendo um MOTU é uma responsabilidade, não um privilégio. Não é sobre o título, mas sobre a capacidade de ajudar a comunidade Ubuntu pelos direitos de acesso que vêm com ela. Devido a isso, pode ser que todo o processo de aprovação possa ser modificado (ou estendido). MOTUs geralmente se nomeiam, e então a diretoria olha se eles estão prontos para serem MOTUs. Talvez devesse ser possível, que pares que acreditam que alguém esteja pronto para ser um MOTU, possam nomear essa pessoa. Isso representaria mais IMHO o fato de que a nomeação é feita para ajudar o processo, não para obter um título. Eu entendo que fazer isso da maneira única tem seus problemas também, portanto, eu prefiro vê-lo como uma alternativa, então o único caminho.

Eu também sei que houve alguns problemas no passado com pessoas focando mais no KDE. Espera-se que esses problemas sejam resolvidos, mas talvez seja bom que isso também seja mais amplamente conhecido.

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

    

Answer 9

Para mim, é provavelmente 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 seus dentes nisso.

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

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

Então, basicamente, para mim, é apenas o momento, eu quero ajudar, mas eu só tenho um par de horas (2 ou algo assim) a cada semana ou mais. E nessa pequena quantidade de tempo eu pareço incapaz de começar isso.

    

Answer 10

Postei algumas ideias aqui: link

Uma coisa que eu realmente quero destacar é, eu me pergunto quantos desenvolvedores não usam sistemas de compilação que se encaixam facilmente nas ferramentas de empacotamento. Eu estou fazendo desenvolvimento de python. Meu mundo gira em torno de setuptools e distribuir, e sim, posso pegar algo que construo com eles e exportá-lo, mas para que fim? Eu já tenho algo que é distribuível. Eu me pergunto se o surgimento de linguagens de script com suas próprias ferramentas de construção / métodos de distribuição causam uma falta de experiência e desejo em colocar as coisas em conjunto com as ferramentas de empacotamento da Debian e, portanto, com os níveis de MOTU.

    

Answer 11

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

Então, acho que, mesmo que o empacotamento para distribuição seja fácil, ainda há muito mais trabalho além do empacotamento para você mesmo.