Quels sont les plus grands obstacles à la marche sur le chemin MOTU / développeur? [fermé]


26

Pour ceux qui ne sont pas MOTU (personnes qui maintiennent les référentiels de logiciels Universe et Multiverse ) et qui n'ont pas de plans de la variété "Je vais postuler à MOTU d'ici $ date":

Qu'est-ce qui vous empêche, vous et d'autres comme vous, d'essayer de devenir MOTU? Qu'est-ce qui vous fait penser que vous ne pouvez pas en devenir un?

Je parle des barrières sociales et technologiques.

EDIT: Je ne dis que MOTU parce que c'est un groupe assez générique, mais "pourquoi n'emballez-vous pas / corrigez-vous et n'avez-vous pas l'intention d'essayer éventuellement des droits de téléchargement?" est une version encore plus générale.


7
Veuillez faire de MOTU un lien vers wiki.ubuntu.com/MOTU pour les personnes qui ne savent pas ce que c'est (comme moi)
Steve Armstrong

1
Je suis d'accord qu'un lien serait utile. Cependant, étant donné que cette question porte sur la raison pour laquelle les gens ne font pas partie d'une chose particulière, il serait préférable d'expliquer le jargon dans la question.
moberley

@moberley: les MOTU sont des développeurs qui peuvent télécharger des packages dans la section univers (et multivers) des archives Ubuntu.
txwikinger

Oublier de renouveler mon adhésion à ubuntu-dev et ubuntu-coredev et ne pas avoir le temps de recommencer le processus est la raison pour laquelle je ne suis plus MOTU / coredev ;-)
ℝaphink

1
Converti en Wiki communautaire en raison du style de question.
Marco Ceppi

Réponses:


11

Fournissez une meilleure documentation.

J'ai participé aux sessions IRC de la semaine des développeurs liées à l'emballage et aux trucs MOTU (deux fois déjà) et j'ai constaté que pendant ces sessions, vous avez généralement une vague compréhension du processus. Mais si vous regardez les pages wiki d'Ubuntu deux semaines plus tard, vous ne pouvez plus rassembler toutes les pièces. Ces pages sont souvent une sorte de listes à puces de personnes qui comprennent déjà le processus en détail. Mais cela ne suffit pas pour rendre le contenu compréhensible pour les débutants.

Alors peut-être que vous devriez essayer d'obtenir des pages wiki de documentation expliquant le processus, les outils et les personnes impliquées plus en détail. Ou même avec des exemples complets. Pendant les sessions IRC, il y a toujours des exemples reproductibles, peut-être ceux qui font la différence pour les pages wiki.


2
Je suis d'accord que les pages wiki ne sont pas très utiles. J'ai trouvé les vidéos de Daniel Holbach sur YouTube les plus utiles lorsque je débutais. Les journaux des sessions IRC sont-ils publiés sur le wiki?
maco

14

Je pense que le plus grand obstacle technique est de savoir comment créer des paquets Debian. Bien qu'il soit relativement simple de créer un package de travail, il est beaucoup plus difficile de créer des packages conformes aux normes Debian et Ubuntu. De plus, les guides sur la façon de créer des packages traitent normalement d'une situation dans laquelle vous avez le code source qui nécessite une compilation. Cela peut être déroutant pour les applications écrites dans des langages interprétés.

Le plus grand obstacle social est probablement de savoir comment télécharger des packages dans les référentiels univers / multivers. Il est beaucoup plus simple de simplement créer votre propre ppa et d'y télécharger des packages.


11

De nos jours, les gens aiment les contributions en voiture .

Il y a 20 ans, vous consacriez généralement une grande partie de votre énergie à un projet pour animaux de compagnie, si vous en aviez un. Aujourd'hui, vous visitez des dizaines de pages Internet par jour, et il existe de nombreux réseaux sociaux ou autres communautés, où vous pouvez contribuer à des wikis, des forums et d'autres choses. Bien que cela ait conduit à plus de personnes contribuant, il a également conduit à des personnes s'attendant à des entrées à faible barrière (à la "cliquez simplement sur le site Web pour le modifier). Sinon, elles peuvent simplement se tourner vers d'autres communautés.

Par conséquent, vous devez rechercher les obstacles dans le processus MOTU. Je me souviens du projet GroundControl pour abaisser la barrière pour les contributions de correctifs dans les projets hébergés sur le tableau de bord. Peut-être avez-vous besoin de nouveaux outils similaires, afin que les nouveaux candidats MOTU n'aient pas à manipuler de nombreux outils en ligne de commande. Bien que ces outils actuels puissent être puissants, il faut probablement beaucoup d'énergie pour apprendre à les utiliser correctement.


3
Je ne sais pas si j'aime l'idée de personnes qui ne peuvent pas utiliser les packages de maintenance du shell, car les scripts shell sont une partie importante de l'emballage (c'est-à-dire qu'il existe des scripts shell que vous devez écrire / modifier pour créer de nombreux packages travail).
maco

@maco: Voulez-vous ou non obtenir de nouveaux contributeurs? Si c'est le cas, vous devez accepter que les processus doivent changer (et pas seulement les personnes impliquées dans les processus). La pensée élitiste exclura une grande partie de la communauté potentielle. Et si vous voulez obtenir un effort réparti pour commencer, la ligne de commande est généralement un très mauvais outil pour prendre en charge cela.
Bananeweizen

1
C'est comme dire "vous avez besoin de connaître le C pour écrire un patch de noyau" est élitiste. Vous avez simplement besoin de savoir comment fonctionne la ligne de commande pour écrire les scripts qui vont dans un package. Même si vous aviez une interface graphique pour créer un package, il se retrouverait avec un tas de zones de texte "tapez le script shell postinst ici".
maco

1
Mon commentaire ne concernait pas les nécessités techniques. Je vais essayer de reformuler (je ne suis pas un anglophone natif): D'abord, vous demandez des contributeurs supplémentaires. Ensuite, j'ai lu dans votre commentaire: Si vous ne pouvez pas écrire de scripts shell, vous êtes stupide de participer à l'empaquetage. Cela me dérange. Je crois toujours que vos hypothèses sont fausses. Jusqu'à Ground Control, tout le monde devait connaître les systèmes de contrôle de version pour pouvoir patcher certains projets en LP. Au lieu de faciliter le contrôle de version, GC s'est opposé au cas d'utilisation unique des correctifs et a supprimé le besoin de tout savoir sur les systèmes de contrôle de version.
Bananeweizen

1
Je n'ai dit "stupide" nulle part. J'ai dit que c'était une compétence nécessaire. Pour tout paquet quelque peu complexe, vous devrez écrire un script shell. L'ignorance (n'ayant pas encore appris une certaine compétence) et l'intelligence ne sont en aucun cas les mêmes.
maco

9

La plus grande barrière que j'ai trouvée est la page du développeur Ubuntu: http://www.ubuntu.com/community/get-involved/developers

Tant de fois, je me suis enthousiasmé à l'idée de contribuer au moins 1 correctif à Ubuntu ... alors je vais à l'endroit naturel sur le site Web ... et je me retrouve perdu dans une mer de documentation. Quelques heures plus tard, je n'ai toujours aucune idée de la raison pour laquelle je devrais écrire un patch. Quand je regarde à travers les bogues d'Ubuntu, je trouve souvent des correctifs ... beaucoup qui restent là inutilisés.

En ce qui concerne les packages, j'ai essayé de comprendre comment les fabriquer, c'est vraiment déroutant. J'ai également essayé de m'impliquer dans Launch Pad, mais l'interface est tellement plus complexe que Source Forge, je n'ai pas pu obtenir mon propre code sur LP. C'est très difficile pour un nouvel utilisateur.


2
Oui, la conception du tableau de bord a un problème. Les choses ne sont pas évidentes sur LP. C'est facile mais il faut le chercher beaucoup. Les nouveaux utilisateurs se perdent rapidement. Il a besoin d'une refonte pour le rendre plus évident et plus simple comme GitHub.
Owais Lone

8

Être MOTU est une responsabilité .

Eh bien, évidemment, la raison n ° 1 n'est pas assez bien informée techniquement, et la raison n ° 2 est d'avoir un milliard de choses que vous préférez faire. Mais parmi votre public cible, je pense que la principale raison est que c'est une responsabilité.

Si je compile un package pour moi-même, personne d'autre ne se soucie de savoir si j'ai suivi les politiques techniques et juridiques. Personne ne viendra m'attendre à ce que j'emballe une version plus récente. Personne ne me demandera de corriger des bugs.

Si je télécharge mon package sur un ppa, quelques personnes peuvent s'en soucier. Mais les attentes ne sont pas aussi élevées. Je peux juste disparaître et laisser les gens se plaindre sur leur blog à quel point il est triste que le paquet ne soit pas disponible pour natty narwhal.

Si je deviens MOTU, j'ai soudain une grande responsabilité. Les utilisateurs viendront me voir avec des rapports de bogues et se plaindront si je ne les résout pas hier. Les utilisateurs s'attendront à ce que je télécharge la nouvelle version du package dès qu'elle sera disponible en amont. Je vais devoir expliquer aux utilisateurs non techniques comment comprendre ce qu'ils ont fait de mal. Contrairement à l'affichage sur un forum, je ne suis pas censé ignorer les questions auxquelles je n'ai pas envie de répondre. Et d'autres développeurs pourraient me poursuivre parce que j'ai foiré quelque chose - cela peut être intimidant.

Et qu'est-ce que je gagne?

  • Un sentiment flou que j'ai aidé les gens. Cela peut être important. Mais si c'est ma principale motivation, comment un logiciel d'emballage peut-il se comparer à une aide dans une soupe populaire ou à un tutorat pour les enfants de votre voisin immigré sans emploi?

  • Une puce sur mon CV? Meh, participer à un FOSS en tant que programmeur sera beaucoup plus apprécié. (Cela vous donne de l'expérience avec des choses comme la gestion de projet et l'entretien à long terme qui sont difficiles à enseigner dans les cours collégiaux.) En fait, être un DD / MOTU semble suspect aux nombreux employeurs qui désapprouvent les employés politiquement impliqués (vous êtes ouvertement un soutien politique aux logiciels libres).

  • Un sentiment de satisfaction? Beaucoup moins que d'écrire mon propre programme à partir de zéro. La programmation est beaucoup plus créative que l'emballage. Il y a un grand sentiment d'accomplissement en elle. Il y a des droits de vantardise. Mais dans l'emballage? C'est une corvée. Ce n'est pas glamour.

(C'est un «je» à la troisième personne ci-dessus. Je pense que les raisons que je donne s'appliquent à la plupart des gens, mais à des degrés divers. Personnellement, il s'agit principalement d'un milliard de choses que je préférerais faire, et d'un emballage dépourvu d'un sentiment d'accomplissement créatif.)

(Par curiosité, Ubuntu manque-t-il de main-d'œuvre?)


1
Oui. Avez-vous vu notre bugtracker?
maco

@maco: Sur la page MOTU , je vois facilement ce qu'est un MOTU et comment je pourrais le devenir. Je ne vois rien sur "Oncle Ubuntu a besoin de VOUS!". Je ne pense pas que le bugtracker en dit long à un utilisateur occasionnel; par exemple, de nombreux bogues non fermés peuvent signifier de nombreux utilisateurs de rapports et d'exécutions qui ne publient pas suffisamment d'informations pour reproduire le bogue.
Gilles 'SO- arrête d'être méchant'

Je dois être totalement d'accord avec Gilles. Si j'avais plus de temps à consacrer à l'open source, j'ai quelques projets que j'aimerais programmer.
Javier Rivera

Il y a beaucoup de bugs comme ça, mais ils se ferment à cause de l'inactivité finalement. Il y a environ 2000 bogues avec des correctifs attachés sur Launchpad. L'opération Cleansweep a consisté à passer en revue et à réviser les correctifs et à les envoyer en amont s'ils sont bons et à les rejeter s'ils sont mauvais. S'ils sont bons et ne doivent pas attendre un cycle de version complet pour passer à travers les versions en amont, ils doivent être emballés. Bien que beaucoup aient des années. Nous n'avons pas suivi le rythme auquel ils sont soumis.
maco

4

La langue , mon principal problème est que je ne suis toujours pas assez en confiance avec l'anglais, étant donné que je ne peux pas comprendre facilement ce que les autres développeurs essaient de me dire


3

Qu'est-ce qui m'empêche de devenir MOTU?

Bien qu'Ubuntu soit une très belle communauté (je n'ai pas encore été critiqué pour les questions de n00bie), je pense qu'il y a peu de documentation / incomplète sur le processus de conditionnement (même le nouveau guide du responsable Debian est plein de "ce sujet est hors de portée de ce document "lignes). Si vous prenez ce fait et pensez aux gens dont la langue maternelle n'est pas l'anglais (comme moi), le processus est encore plus difficile et caothique.

Avec une documentation simple et directe, tout serait plus facile pour nous tous, mais les gens qui ont les compétences techniques pour écrire cette documentation sont trop occupés pour le faire.


3

Je pense qu'il y a plusieurs raisons à cela. Je pense aussi que les raisons sont souvent individuelles.

L'un des problèmes à l'heure actuelle est le changement de l'ensemble du système MOTU. Je pense que les changements peuvent être déroutants et ont été mis en œuvre davantage sur des lignes technologiques et n'ont malheureusement pas pleinement intégré la communauté (peut-être simplement parce que cela prête à confusion).

Je pense aussi que, dans certains cas, la motivation pour être un MOTU n'est pas aussi claire qu'elle pourrait l'être. À mon humble avis, être un MOTU est une responsabilité, pas un privilège. Il ne s'agit pas du titre, mais de la capacité d'aider la communauté Ubuntu par les droits d'accès qui l'accompagnent. Pour cette raison, il se pourrait que l'ensemble du processus d'approbation puisse être modifié (ou étendu). Les MOTU se désignent généralement eux-mêmes, puis le conseil d'administration vérifie s'ils sont prêts à être des MOTU. Peut-être que cela devrait être possible, que les pairs qui croient que quelqu'un est prêt à être un MOTU puissent nommer cette personne. À mon humble avis, cela représenterait davantage le fait que la nomination est faite pour aider le processus et non pour obtenir un titre. Je comprends que faire de cette voie l'unique a aussi ses problèmes, donc je la vois plutôt comme une alternative que la seule.

Je sais également qu'il y a eu des problèmes dans le passé avec des gens qui se concentraient davantage sur KDE. Nous espérons que ces problèmes ont été résolus, mais il serait peut-être bon que cela soit également plus largement connu.

De toute évidence, ce ne sont que quelques problèmes que j'ai remarqués. Les gens sont différents et verront des choses différentes, ou seront affectés différemment par la même chose. Donc, ces problèmes pourraient ne pas arrêter tout le monde, et ils ne sont pas les seules raisons de ce problème.


Les sponsors devraient dire aux personnes dont ils sponsorisent les packages lorsqu'ils pensent qu'ils sont prêts, "hé, vous devriez peut-être postuler maintenant", mais je ne sais pas à quelle fréquence cela se produit. J'ai suggéré de postuler à une personne que j'étais mentor, mais il a changé d'orientation vers d'autres domaines de développement.
maco

C'est toujours une différence quand un parrain dit à quelqu'un de postuler, ou que cette personne est désignée par un parrain.
txwikinger

Euh? Les parrains ne nomment pas de personnes, les parrains préconisent l'auto-nomination par le parrainé.
lfaraone

lfaraone: txwikinger suggère que les sponsors devraient pouvoir nommer des personnes. C'est arrivé une fois. Certaines personnes sont allés et ont créé une page wiki pour Sarah Hobbs et envoyé un e - tuberculose et témoignages ont donné et ainsi de ce moment - là quand il y avait une claire effusion de soutien, puis elle a montré à la réunion du CEI de prendre la dernière étape.
maco

2
@Ifaraone: Je suggère que certaines bonnes personnes ne se proposent pas elles-mêmes et nous les perdons donc. Au final, une bonne personne qui devient MOTU est une victoire pour Ubuntu, peut-être devrions-nous y penser.
txwikinger

2

J'ai posté quelques idées ici: http://blog.mitechie.com/2010/08/24/ubuntu-help-wanted/

Une chose que je veux vraiment souligner, c'est que je me demande combien de développeurs n'utilisent pas de systèmes de build qui se connectent facilement aux outils de packaging. Je fais du développement python. Mon monde est centré sur les setuptools et la distribution, et oui, je peux prendre quelque chose que je construis avec ceux-ci et l'exporter, mais à quelle fin? J'ai déjà quelque chose qui est distribuable. Je me demande si la montée en puissance des langages de script avec leurs propres outils de construction / méthodes de distribution entraîne un manque d'expérience et de désir de mettre les choses en place avec les outils de packaging Debian et donc les niveaux MOTU.


2

Pour moi, c'est probablement lié au temps. Actuellement, je n'ai pas beaucoup de temps à investir. Et j'ai commencé par le tri des bogues, mais j'ai vite découvert que les choses étaient un peu plus compliquées. Et vous devez vraiment y mettre vos dents.

Ensuite, il y a la correction de bugs, que je sais que j'aimerais. Ce qui m'empêche d'aider là-bas, c'est que vous devez exécuter une branche de développement ou quelque chose. Une fois, j'ai commencé à travailler sur une de mes découpes de papier dans le Moniteur système (https://bugzilla.gnome.org/show_bug.cgi?id=611738) J'ai donc commencé à utiliser Ground Control, pour récupérer la source requise et y accéder. une correction du bug. Cependant, il s'est avéré que ce n'était pas si facile, à cause des dépendances. Je sais que je ne devrais travailler que sur la version de développement et tester si elle y est corrigée. Cependant, juste pour essayer, j'avais besoin de télécharger la source de nombreux autres paquets gnome. Ce qui n'est pas si simple avec GroundControl. Et vous devriez probablement le faire sur une machine de travail. Je me suis donc arrêté là. (Encore une fois, cela me prendrait trop de temps, juste pour commencer)

En ce qui concerne l'emballage, je ne suis tout simplement pas au courant de tout ce qui nécessite un emballage. J'ai déjà fait un tutoriel sur l'emballage, et je l'ai trouvé pas trop difficile pour les petites applications. Cependant, je ne suis jamais sorti à la recherche d'une liste de choses qui doivent être emballées, car je sais qu'il y en a probablement une ... :)

Donc, pour moi, il est juste temps, je veux aider, mais j'ai juste quelques heures (2 ou quelque chose) chaque semaine impaire. Et dans ce petit laps de temps, il me semble que je ne peux pas commencer avec ça.


Vous n'avez pas besoin de la source des dépendances, juste des debs réguliers. Pourquoi ne pas configurer une VM de la version de développement pour qu'elle fonctionne? Ensuite, vous n'avez pas à vous soucier de votre configuration (bien que j'exécute des versions devel presque en continu depuis février 2007 ... plus d'un an avant de commencer à faire quoi que ce soit lié à l'empaquetage / correction des bogues Ubuntu). La correction d'un bug par semaine sur 2 heures est définitivement possible une fois que vous avez configuré votre environnement. Quant à une liste de choses à emballer: il y a une balise needs-packaging sur Launchpad. L'emballage de correctifs existants est également très utile!
maco

1

Lorsque je crée un package, c'est généralement pour gratter une démangeaison, pas parce que quelqu'un d'autre veut le package. Checkinstall est assez bon pour faire un paquet pour moi, puis ma démangeaison est rayée, et je n'ai aucune incitation personnelle à faire la distance supplémentaire pour l'empaqueter manuellement, et à comprendre toutes les dépendances et tout ça.

Je suppose donc que même si l'emballage pour la distribution est facile, il reste encore beaucoup de travail au-delà de l'emballage pour vous-même.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.