There are dozens of ways that the rest of the community can participate in the Nexus7 project, but I’d like to call out one facet that I’ve been working hard on since I got back from Copenhagen. Chris Wayne and I spend a large portion of our day going through the Nexus7 bug list doing bug triage. In brief, what we do is:
- If the bug is unclear, ask the submitter for more info in a comment
- Checking for duplicate bug reports inside the Nexus7 project
- Confirm that the bug really happens on the Nexus7 device
- See if the bug occurs on our laptops/dev boxes (x86 running Quantal)
- Search the upstream launchpad projects to see if the bug is known already, and mark the Nexus7 one as a duplicate if so
- Search gnome bug reports to see if we can link to one
- File upstream LP and gnome bug reports if none exist
- Testing fixes from upstream
- Set bug priority
So today, I’m officially asking the community to help, if you’re interested in helping with the Nexus7 work and don’t know where to start, bug triage is a great place and we could use your help.
So how do you start? A good place to start is by reviewing the New bug queue and then following the Triaging guide and try to get enough information so that a developer can get started on it. You should also join the #ubuntu-arm channel on freenode, where we can discuss bug status and priority. Feel free to ping me (mfisch) or Chris (cwayne) if you have questions about a bug or how to help.
On a personal note: when I first started working on Ubuntu, I joined the Ubuntu Bug Squad because there’s really no better way to learn about the components of Ubuntu than to dive into a bunch of bug reports. After a while doing Bug triage work, I was very comfortable with launchpad and bug triage procedures. I also had a better feel for how the components of the system worked together, it’s amazing how much you can learn from digging into bug reports!