Quels sont les principaux obstacles à la progression sur le chemin MOTU / développeur?
Pour ceux qui ne le sont pas MOTU (les personnes qui gèrent les logiciels Univers et Multiverse référentiels ) et qui n'ont pas de projet "J'appliquerai à MOTU avant le $ date" variété:
Qu'est-ce qui vous empêche, ainsi que d'autres personnes comme vous, d'essayer de devenir MOTU? Qu'est-ce qui te fait penser que tu ne pourrais pas le devenir?
Je parle de 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/ne corrigez-vous pas et n'avez-vous pas l'intention d'essayer de télécharger droits?" est une version encore plus générale.
Fournir une meilleure documentation.
J'ai pris part aux semaines de développement IRC relatives au packaging et au contenu MOTU (deux fois déjà) et j'ai constaté qu'au cours de ces sessions, vous avez généralement une compréhension vague du processus. Mais si vous consultez les pages du wiki Ubuntu deux semaines plus tard, vous ne pouvez plus rassembler tous les éléments. Ces pages sont souvent des sortes 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, vous devriez peut-être essayer d’obtenir les pages wiki de la documentation qui expliquent plus en détail le processus, les outils et les personnes impliquées. Ou même avec des exemples complets. Pendant les IRC sessions, il y a toujours des exemples répétables, ils font peut-être la différence avec les pages du wiki.
Je pense que la plus grande barrière technique est de savoir comment créer des paquets Debian. Bien qu'il soit relativement simple de créer un paquet fonctionnel, il est beaucoup plus difficile de créer des paquets répondant aux normes de Debian et Ubuntu. En outre, les guides sur la création de packages traitent normalement d'une situation dans laquelle vous avez le code source à compiler. Cela peut être déroutant pour les applications écrites dans des langages interprétés.
La plus grande barrière sociale est probablement de savoir comment télécharger des paquets dans les référentiels univers/multivers. Il est beaucoup plus simple de créer votre propre ppa et de télécharger des paquets là-bas.
De nos jours les gens aiment les contributions au volant.
Il y a 20 ans, vous consacriez généralement beaucoup d'énergie à un projet pour animaux de compagnie, si vous en aviez un. Aujourd'hui, vous visitez des dizaines de pages Internet par jour et vous pouvez contribuer à des wikis, des forums, etc., sur de nombreux réseaux sociaux ou d'autres communautés. Bien que cela ait conduit à une augmentation du nombre de personnes contribuant, cela a également conduit des personnes à s'attendre à des entrées à faible barrière (cliquez simplement sur le site Web pour le modifier). Sinon, elles risquent de se tourner vers d'autres communautés.
Par conséquent, vous devez rechercher des obstacles dans le processus MOTU. Je me souviens du projet GroundControl visant à réduire l’obstacle des contributions de correctifs dans les projets hébergés dans le tableau de bord. Peut-être avez-vous besoin de nouveaux outils similaires, pour que les nouveaux candidats à MOTU n'aient pas à manipuler beaucoup d'outils en ligne de commande. Bien que ces outils actuels puissent être puissants, il faut probablement beaucoup d’énergie pour apprendre à les utiliser correctement.
La plus grande barrière que j'ai trouvée est la page de développement Ubuntu: http://www.ubuntu.com/community/get-involved/developers
Tellement de fois, j'ai été déterminé avec enthousiasme à contribuer au moins 1 patch à Ubuntu ... alors je me rends à l'endroit naturel sur le site Web ... et je me retrouve perdu dans une mer de documentation. Quelques heures plus tard, je ne sais toujours pas pour quoi écrire un patch. Lorsque je regarde à travers les bogues Ubuntu, je trouve souvent des correctifs ... beaucoup qui restent inutilisés.
En ce qui concerne les paquets, j'ai essayé de comprendre comment les fabriquer, c'est vraiment déroutant. J'ai aussi essayé de m'impliquer dans Launch Pad, mais l'interface est tellement plus complexe que Source Forge, je ne pouvais pas obtenir mon propre code sur LP. C'est très difficile pour un nouvel utilisateur.
Être une MOTU est un responsabilité.
Bien évidemment, la raison n ° 1 n’est pas assez bien informée sur le plan technique, et la raison n ° 2 est d’avoir des choses que vous préférez faire. Mais parmi votre public cible, je pense que la raison principale 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 règles techniques et juridiques. Personne ne viendra me voir dans l’espoir que je mette à jour une version plus récente. Personne ne me demandera de réparer les bugs.
Si je télécharge mon colis sur un ppa, quelques personnes peuvent s'en soucier. Mais les attentes ne sont pas aussi élevées. Je peux simplement disparaître et laisser les gens se plaindre sur leur blog de la tristesse 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ésous pas hier. Les utilisateurs s'attendent à ce que je télécharge la nouvelle version du paquet dès qu'il sera disponible en amont. Je vais devoir expliquer aux utilisateurs non techniques comment comprendre ce qu'ils ont mal fait. Contrairement à la publication 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 s’en prendre à moi parce que j’ai commis une erreur - cela peut être intimidant.
Et qu'est-ce que je gagne?
Un sentiment flou que j'ai aidé les gens. Cela peut avoir de l'importance. Mais si c'est ma principale motivation, comment un logiciel d'emballage peut-il être comparé à une aide dans une soupe populaire ou à un tutorat pour les enfants de ses voisins immigrés sans emploi?
Un point sur mon CV? Meh, participer à un logiciel libre en tant que programmeur sera beaucoup plus apprécié. (Cela vous donne une expérience avec des choses comme la gestion de projet et la maintenance à long terme qui sont difficiles à enseigner dans les cours collégiaux.) En fait, être un DD/MOTU semble suspect aux nombreux employeurs qui critiquent les employés politiquement impliqués donner ouvertement un soutien politique aux logiciels libres).
Un sentiment de satisfaction? Beaucoup moins que d'écrire mon propre programme à partir de zéro le ferait. La programmation est beaucoup plus créative que l’emballage. Il y a un grand sentiment d'accomplissement dans cela. Il y a le droit de se vanter. 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, c’est principalement parce que je préfère faire un tas de choses et que les emballages manquent de sens de la créativité.)
(Par curiosité, Ubuntu manque-t-il de main-d'œuvre?)
Langue, mon principal problème est que je ne maîtrise toujours pas suffisamment l'anglais, car je ne comprends pas bien ce que les autres développeurs essaient de me dire.
Je pense qu'il y a plusieurs raisons à cela. Je pense aussi que les raisons sont souvent individuelles.
L’un des problèmes actuels est le changement de l’ensemble du système MOTU. Je crois que les changements peuvent être déroutants et ont été mis en œuvre davantage sur des lignes technologiques et, malheureusement, n’ont pas permis à la communauté de s’impliquer pleinement (peut-être simplement parce que cela prête à confusion).
Je pense aussi que, dans certains cas, la motivation pour devenir une MOTU n’est pas aussi claire qu’elle pourrait l’être. À mon humble avis, être une MOTU est une responsabilité et non un privilège. Il ne s'agit pas du titre, mais de la possibilité d'aider la communauté Ubuntu par les droits d'accès qui l'accompagnent. Pour cette raison, il se peut que l'ensemble du processus d'approbation puisse être modifié (ou étendu). Les MOTU se désignent généralement elles-mêmes, puis le conseil vérifie si elles sont prêtes à devenir des MOTU. Peut-être devrait-il être possible que des pairs qui croient que quelqu'un est prêt à être une MOTU soient en mesure de nommer cette personne. Cela représenterait plus le fait que la nomination est faite pour faciliter le processus, pas pour obtenir un titre. Je comprends que le fait que ce soit le seul moyen a aussi ses problèmes, donc je le vois plutôt comme une alternative que comme le seul moyen.
Je sais aussi qu'il y a eu des problèmes dans le passé avec des personnes 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 là que quelques problèmes que j'ai notifiés. Les gens sont différents et verront des choses différentes ou seront affectés différemment par la même chose. Ces questions pourraient donc ne pas arrêter tout le monde et ne sont pas les seules raisons de ce problème.
Qu'est-ce qui m'empêche de devenir MOTU?
Même si Ubuntu est une très jolie communauté (je n’ai pas encore été flambée pour n00bie questions), je pense qu’il existe peu de documentation/une documentation incomplète sur le processus d’emballage (même le Guide du nouveau responsable de Debian mentionne que ce sujet est hors de propos. de ce document "lignes). Si vous prenez ce fait et pensez aux personnes dont la langue maternelle n'est pas l'anglais (comme moi), le processus est encore plus difficile et caothique.
Avec une documentation simple et pertinente, tout serait plus facile pour nous tous, mais les personnes qui possèdent les compétences techniques pour rédiger cette documentation sont trop occupées pour le faire.
Pour moi, c'est probablement lié au temps. Actuellement, je n'ai pas beaucoup de temps pour investir. Et j'ai commencé avec le tri des bogues, mais j'ai vite découvert que les choses étaient un peu plus compliquées. Et vous devez vraiment mordre à pleines dents.
Ensuite, il y a la correction des bogues, ce qui me plairait, je le sais. Ce qui m'empêche d'aider, c'est que vous devez gérer une branche de développement ou quelque chose du genre. Une fois, j'ai commencé à travailler sur l'un de mes papiers dans le Moniteur système (https://bugzilla.gnome.org/show_bug.cgi?id=611738). J'ai donc commencé à utiliser Ground Control pour rechercher la source requise et y accéder. corriger le bogue. Cependant, cela s'est avéré moins 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, je devais télécharger le code source de nombreux autres paquets gnome. Ce qui n’est pas si facile avec Groundcontrol. Et vous devriez probablement le faire sur une machine de travail. Alors je me suis arrêté là. (Encore une fois, cela me prendrait trop de temps, juste pour commencer)
En ce qui concerne les emballages, je ne suis au courant de rien. J'ai déjà fait un tutoriel sur le packaging et je ne l'ai pas trouvé trop difficile pour les petites applications. Cependant, je ne suis jamais allé à la recherche d'une liste de choses à emballer, car je sais qu'il y en a probablement une ... :)
Donc, fondamentalement, pour moi, c'est juste le temps, je veux aider, mais j'ai juste quelques heures (2 ou quelque chose) chaque semaine impaire. Et dans ce court laps de temps, il semble que je ne puisse pas commencer avec cela.
J'ai posté quelques idées ici: http://blog.mitechie.com/2010/08/24/ubuntu-help-wanted/
Une chose que je veux vraiment faire ressortir est la suivante: je me demande combien de développeurs n’utilisent pas de systèmes de construction faciles à intégrer aux outils d’emballage. Je suis en train de développer python. Mon monde est centré autour de setuptools et de distribution, et oui, je peux prendre quelque chose que je construit avec ceux-ci et l'exporter, mais dans quel but? J'ai déjà quelque chose qui est distribuable. Je me demande si la montée en puissance des langages de script dotés de leurs propres outils de génération/méthodes de distribution entraîne un manque d'expérience et de volonté pour la mise en place d'outils de packaging debian et, par conséquent, de niveaux MOTU.
Lorsque je crée un paquet, c'est généralement pour me gratter, pas parce que quelqu'un d'autre veut le paquet. Checkinstall est assez bon pour me faire un paquet, puis ma démangeaison est éraflée, et je n'ai aucune incitation personnelle à aller plus loin pour le conditionner manuellement, et comprendre toutes les dépendances et tout le reste.
Je suppose donc que même si l'emballage pour la distribution est facile, il reste encore beaucoup à faire pour vous-même.