A brief guide to bug smashing in OpenStack Horizon

Five years ago OpenStack released its official Dashboard Horizon.

Horizon offers a web-based user interface to OpenStack services including Nova, Swift, Keystone, etc along with an extensible framework for building new dashboards from reusable components.

Because half a decade is like dog years in software development, bugs that have grown up with the dashboard sometimes prevent Horizon from providing the best user interface possible.

Rob Cresswell, Horizon OpenStack Project Team Lead (PTL), wanted to bring more attention to the growing list of bugs in Horizon’s code. He wrote an introduction to Horizon’s bug list and how users and developers can find and contribute solutions to problems the OpenStack community may face when using the Dashboard.

"I wrote about the bug list because I believe upstream development has a fixation on adding new code at the expense of all other project contribution," he told Superuser in an email.

Cresswell says that short-sighted fixation on the new has sometimes curbed Horizon’s usefulness.

"Adding new code is probably the least useful thing a new contributor can actually do. Every large project – Neutron, Nova, Horizon etc. needs more organization, bug triage, review work and documentation, as well as user data and feedback; from these, they should be able to quickly focus on the important aspects to move forward on and write code for," he says.

Cresswell believes it’s "absolutely key" for "new and existing contributors to have a greater understanding of how to extract value from the bug lists."

So Cresswell wrote this brief guide to exterminating bugs on the mailing list that we’re republishing below.

bdpfyfw5toodiq2rekbj

Using the bug list:

The "Tags" section on the right hand side is your friend. We have a whole bunch of tags related to language (like "angularjs"), the bug content ("integration-tests" or "ux") or the type of service knowledge that may be useful in solving the bug ("nova", "neutron" etc). If you’re just starting out, checking out the "low-hanging-fruit" tag, which is used to indicate straightforward bugs for your first couple of contributions.
If you’re looking for code to review, try using the Advanced Search to filter for Critical/High priority bugs that are In Progress. This means they are important to us, and have a patch up on Gerrit. Alternatively, scroll down and select the next milestone ("newton-2" in this case) from the "Milestone-targeted bugs" on the right hand side. These are bugs that have been triaged and we’d like to have complete for this milestone.
Don’t be intimidated by bugs marked High/Critical. Priority is often not linked to complexity, so its worth looking into.
If you assign yourself to a bug, but are unable to complete it, remember to remove yourself as an assignee and set the status back to "Confirmed" or "New"; this makes it much easier for us to track which bugs are being actively worked on.

Triaging the bug list:

This is a great step by step piece of documentation on triage, and definitely worth reading through to understand the prioritization system.
Target bugs to the "Next" milestone by default. This makes it easy to see whether bugs have been triaged or not. If a bug is important for this milestone, or looks close to completion, just target it to the next milestone right away.
Remember to use tags, but be careful how you use them. Generally, we use the service name tags, like "Nova," "Swift" etc. to indicate that specific knowledge of the service may be useful for this bug. Just because a bug is on the Instances panel, does not mean it should immediately be tagged with "nova"; consider whether it is actually service specific, or is really a UI or other code issue.
You don’t need to be on the bug team to triage; if there’s something you’re unable to do, just ping a member of the bug team.

You can find out more about Horizon and how to get involved on the project Wiki page.