De quelles façons puis-je contribuer au projet One Hundred Paper Cuts?
Je veux m'impliquer dans le projet One Hundred Paper Cuts , mais je ne sais pas quoi faire. Je ne suis pas programmeur donc je ne sais pas si je peux même contribuer. Quelqu'un peut-il expliquer ce qu'il y a à faire sur le projet One Hundred Paper Cuts?
Il existe de nombreuses façons de participer au projet One Hundred Paper Cuts. Il est important de noter que vous n'avez pas besoin d'être programmeur pour apporter une contribution significative. Il existe de nombreux rôles à remplir, et l'écriture de code n'est qu'une petite partie de la fixation d'une coupe de papier.
Si vous trouvez quelque chose ci-dessous que vous trouvez intéressant, alors rejoignez l'équipe Paper Cut Ninja sur Launchpad , abonnez-vous à la liste de diffusion, présentez-vous et laissez-nous savoir ce que vous êtes intéressé à faire. Si vous avez des questions, nous serons heureux de vous aider.
Reporter - Signaler un problème
Signaler un problème est quelque chose que tout le monde peut faire. S'il y a quelque chose dans votre application préférée qui vous passe sous la peau, signalez-le (tant que l'application est incluse sur le bureau). Si vous voulez vraiment vous impliquer, choisissez une application sur le bureau et asseyez-vous pendant une heure ou deux et recherchez les coupures de papier à signaler.
Analyste - identifie ce qui ne va pas
Confirmez nouveaux bogues - quelqu'un doit venir et voir si l'arriéré des bogues nouvellement signalés sont réellement des coupures de papier valides. Asseyez-vous avec l'application en question et regardez ce qui se passe. Si le signalement n'a pas fourni suffisamment d'informations, demandez les informations manquantes et marquez le rapport comme Incomplet .
Triage bugs confirmés - une fois qu'un bug a été confirmé pour exister, quelqu'un doit venir et comprendre ce qui ne va pas. Par exemple, est le problème avec l'application elle-même ou dans la boîte à outils graphique avec laquelle elle est construite, comme Gtk. Cela impliquera généralement de parler à quelqu'un des équipes Paper Cuts ou Desktop pour obtenir des conseils jusqu'à ce que vous ayez suffisamment d'expérience pour prendre la décision vous-même.
Une fois que le package concerné a été identifié, quelqu'un peut déterminer ce qui ne va pas. Si vous n'êtes pas familier avec la base de code du package lui-même, contactez le développeur du package pour obtenir des conseils. Une fois qu'ils vous ont dit ce qui se passait, vous devriez poster cette réponse en tant que commentaire sur le rapport de bogue.
Designer - Décide comment cela devrait fonctionner
Une fois qu'un problème a été identifié, un correctif doit être conçu. Cela ne sera pas nécessaire pour chaque coupe de papier (certains d'entre eux n'auront qu'une seule façon d'être réparé). Dans les autres cas, vous devriez vous asseoir avec l'application et réfléchir au fonctionnement du correctif. Une fois que vous avez proposé une idée, vous devriez obtenir approbation de votre conception avant sa mise en œuvre.
Développeur - implémente le correctif dans le code
Si vous savez exactement ce qui se passe, vous pouvez rester coincé dans le code et commencer à réparer le papier coupé. La façon dont vous procédez dépend de l'application sur laquelle vous travaillez et de l'endroit où cette application a été développée à l'origine.
S'il s'agit d'une application Gnome, alors votre meilleur pari serait de retirer le code source de git.gnome.org , de travailler sur votre patch et d'exporter le correctif en tant que .patch fichier que vous pouvez joindre au rapport de bogue dans Gnome Bugzilla.
De nombreux autres projets sont hébergés dans les référentiels Git et suivent leurs problèmes dans Bugzilla. Si vous ne savez même pas où aller, alors allez dans # ubuntu-desktop et demandez. Quelqu'un sera plus qu'heureux de vous orienter dans la bonne direction.
S'il s'agit d'un bogue dans un package Ubuntu, tel que Unity ou Ubuntu Software Center, alors il y a un grand guide pour corriger les bogues Ubunt sur le site Web du développeur Ubuntu.
Testeur - vérifie que le correctif fonctionne correctement
Une fois qu'un chemin a été développé et soumis pour approbation, quelqu'un doit le tester. Cela pourrait être laissé au développeur/mainteneur du package, mais ils ont beaucoup d'autres tâches à accomplir, et tout ce qui peut être fait pour alléger leur charge de travail dans un domaine signifie qu'ils peuvent en faire plus. chez les autres. À cet égard, si un correctif ou une branche est assis sur une coupe de papier, soit sur Launchpad ou en amont, le téléchargement et l'application de ce correctif avant de lui donner un essai routier seront d'une grande aide.
Une fois que vous l'avez mis à l'épreuve, laissez un message sur le rapport de bogue, en amont et dans Ubuntu, détaillant vos résultats. Au début, le développeur ou le responsable ne sera pas en mesure de simplement prendre votre Word que le correctif est prêt, mais si vous travaillez beaucoup sur un package et que le développeur vous connaît, votre Word aura plus de poids et vous pourrez même être donné des droits de téléchargement sur cette archive source de packages.
Liaison - garantit que le correctif est acceptable en amont
Liason et Tester peuvent, mais ne doivent pas, se chevaucher. Une fois qu'il a été vérifié qu'un correctif a résolu le problème, il doit obtenir l'approbation du développeur en amont du package. Les commentaires du traqueur de bogues en amont ne sont pas toujours publiés dans Launchpad, donc quelqu'un doit agir comme le coureur entre les deux, copier et coller les questions et leurs réponses entre les deux. N'oubliez pas qu'Ubuntu n'est pas la seule distribution dans laquelle ces applications apparaissent et que les développeurs ne peuvent pas être tenus de garder une trace de tous ceux qui utilisent leur logiciel, vous devez donc vous assurer que tous ceux qui travaillent sur un bogue sont tenus au courant.
Packager - intègre un patch ou une branche dans la distribution
Une fois qu'un correctif a été écrit, il doit être intégré dans le package d'application existant. Cela impliquera de télécharger et d'installer la version d'Ubuntu sur laquelle vous prévoyez de publier le correctif, de télécharger la source du package, d'appliquer le correctif et d'empaqueter le résultat. Le buntu Packaging Guide explique comment procéder.
Selon la nature du correctif, vous devrez peut-être effectuer cette opération jusqu'à trois fois: la version stable actuelle, le LTS actuel et la version de développement actuelle sont tous des cibles viables pour les correctifs.
Updater - gère SRU pour obtenir le correctif dans la version stable
Ce n'est pas tout le monde sera en mesure de le faire, car il nécessite un droit de téléchargement vers les archives du package Ubuntu. Une fois qu'un correctif a été conditionné, il peut être nécessaire de le rétroporter vers les besoins de la version stable actuelle, du LTS actuel ou des deux. Si vous souhaitez obtenir ces droits de téléchargement, la meilleure façon de procéder consiste à empaqueter les correctifs et à les proposer pour SRU. Une fois que vous avez proposé un nombre parfait pour la première fois, vous pouvez demander des droits de téléchargement.