== Where does the bug go? ==
Many of the bugs filed against ubuntu-nexus7 are valid bugs on other platforms as well. Due to this, we need to make sure that the bugs are logged to their respective upstreams. This will allow for the right people to find and fix the bugs, and for the fixes to make it into the Upstreams, meaning the fix will be available for everyone. It is sometimes obvious what the correct upstream package would be, although sometimes its not so simple. For example, if you are logging a bug against the on-screen keyboard, it should be logged against 'onboard'. A kernel bug will be logged against 'linux', a Unity bug against 'unity' and so on. If there is a case in which you are unsure of the upstream, it's okay to log the bug to the ubuntu-nexus7 project. We will do our best to find the upstream and make them aware.

If you do know the upstream, please log the bug using ubuntu-bug. This is as simple as running ubuntu-bug <package-name>. This will auotmatically grab all of the relevant logs and information, making it easier to log a good bug. One thing to make sure of is once the bug is logged in launchpad, make sure to make it 'Also Affect' the ubuntu-nexus7 project. To do this, open the bug in launchpad, and find the "(+) Also affects project" button and when prompted, input 'ubuntu-nexus7' as the project.

== What should the bug contain? ==

A good bug will contain 6 essential pieces.

 1. '''A good title.''' A good title describes the exact problem succinctly and easily. An example of a good bug title is "When in portrait mode, mouse movement glitches rightward intermittently". Notice the title goes into specifics about exactly what happens in the bug. This title is *much* more useful than a simple "Mouse doesn't work right when screen rotated".
 1. '''A brief summary.'''  It is important to keep this brief.  With a good enough title, this can be just 1 or 2 sentences long.  If the bug is complicated, this can obviously be quite important.
 1. '''Steps to reproduce.'''  Steps to reproduce make the job of a bug triager or developer *much* easier.  Instead of wasting time figuring out how to reproduce the bug, they can get right to trying to fix it.  Try to step through exactly what happened to cause the bug, something that will show the bug reliably (i.e., reproduces the bug 100% if possible).  These should be clear and concise.  A good example could be: 1) Run /usr/bin/xrotate in terminal 2) Click and hold titlebar of window 3) Try to drag the window down
 1. '''Expected Results.'''  Describe here what you would expect to happen when you follow the steps to reproduce.  In the above example, an adequate expected result could be as simple as "Expected the window to drag down smoothly"
 1. '''Actual results.''' Describe what happens instead of the expected results.  Again with the above example, this could be something along the lines of "While dragging the window down, the window seems to jump around randomly."
 1. '''Logs!''' This will usually be automatically taken care of if ubuntu-bug is used to log the bug.  If not using ubuntu-bug, it is very helpful to attach logs to the bug.  The most often needed logs are /var/log/syslog, dmesg, or /var/log/kern.log

== What if I don't have all of the needed info? ==
 If you do not have all of the info referenced above, that's okay.  A bug that requires work is still better than no bug at all.