I want to get involved with the One Hundred Paper Cuts project, but I don't know what there is to do. I'm not a programmer so I'm not sure if I can even contribute anything. Can someone please explain what there is to do on the One Hundred Paper Cuts project?
There are a lot of ways to get involved in the One Hundred Paper Cuts project. It's important to note that you do not have to be a programmer to make a significant contribution. There are many roles that need to be filled, and writing code is only a small part of fixing a paper cut.
If you find something below that you find interesting, then join the Paper Cut Ninja team on Launchpad, subscribe to the mailing list, introduce yourself and left us know what you're interested in doing. If you've got any questions at all, we'll be happy to help you out.
Reporter - Reports an issue
Reporting an issue is something everyone can do. If there's something in your favourite app that gets under your skin, then report it (as long as the app is included on the desktop). If you really want to get involved, then pick an app from the desktop and sit down with it for an hour or two and look for paper cuts to report.
Analyst - identifies what's actually wrong
Confirm new bugs - someone needs to come along and see if the backlog of newly reported bugs are actually valid paper cuts. Sit down with the app in question and have a look at what's happening. If the reported did not provide enough information, then request the missing information and mark the report as Incomplete.
Triage confirmed bugs - once a bug has been confirmed to exist, someone has to come along and figure out what's actually wrong. For example, is the problem with the app itself or in the graphical toolkit it's built with, such as Gtk. This will usually involve talking with someone on the Paper Cuts or Desktop teams for advice until you get enough experience to make the decision yourself.
Once the affected package has been identified, then someone can figure out what's actually wrong. If you're not familiar with the codebase of the package itself, then get in contact with the package developer for advice. Once they tell you what's up, you should post that response as a comment on the bug report.
Designer - Decides how it should work
Once a problem has been identified, a fix needs to be designed. This won't be necessary for every paper cut (some of them will only have a single way to be fixed). In the other cases, you should sit down with the app and think about how the fix should work. Once you've come up with an idea, you should get approval for your design before it is implemented.
Developer - implements fix in code
If you know exactly what's going on then you can get stuck right into the code and start fixing the paper cut. How you go about this depends on which app your working on and where that app was originally developed.
If it's a Gnome app, then your best bet would be to pull the source code down from git.gnome.org, work on your patch and export the fix as a
Many other project are hosted in Git repositories and track their issues in Bugzilla. If you're even unsure of where to go, then here into #ubuntu-desktop and ask. Someone there will be more than happy to point you in the right direction.
If it's a bug in an Ubuntu package, such as Unity or the Ubuntu Software Centre, then there's a great guide to fixing Ubuntu bugs on the Ubuntu developer website.
Tester - verifies the fix works properly
Once a path has been developed and submitted for approval, someone needs to test it. This could be left to the package developer/maintainer, but they have a lot of other work to do, and everything that can be done to lighten their workload in one area means they can get more done in others. In that regard, if a patch or branch is sitting on a paper cut, either on Launchpad or upstream, then downloading and applying that patch before giving it a test drive will be a great help.
Once you're put it through it's paces, leave a message on the bug report, both upstream and in Ubuntu, detailing your results. In the beginning, the developer or maintainer won't be able to simply take your word that the patch is ready, but if you work on one package a lot and the developer gets to know you, your word will carry more weight and you may even be given upload rights to that packages source archive.
Liaison - ensures fix is acceptable upstream
Liason and Tester can, but don't have to, overlap. Once it has been verified that a patch has solved the problem, it needs to gain approval from the upstream developer of the package. Comments from the upstream bug tracker don't always get posted in Launchpad, so someone has to act as the runner between the two, copying and pasting questions and their answers between the two. Remember, Ubuntu isn't the only distro these apps are appearing in, and the developers can't be expected to keep track of everyone that's using their software, so you have to make sure everyone working on a bug is kept in the loop.
Packager - integrates patch or branch into the distro
Once a patch has been written, it needs to be integrated into the existing app package. This will involve downloading and installing the version of Ubuntu you intend the patch to be released on, download the source for the package, applying the patch, and packaging the result. The Ubuntu Packaging Guide covers how to go about doing this.
Depending on the nature of the patch, you may need to do this up to three times - the current stable release, the current LTS and the current development release are all viable targets for patches.
Updater - handles SRU to get patch into the stable release
This is one that not everyone will be able to do, as it requires upload right to the Ubuntu package archives. Once a patch has been packaged, it may need to be backported to needs to either the current stable release, the current LTS, or both. If you want to earn those upload right, the best way to go about doing it is to package patches and propose them for SRU. Once you've proposed a number that are perfect first time round, you can apply for upload rights.