Effective bug reports are the most likely to be fixed. These guidelines explain how to write such reports.
How can a developer reproduce the bug on his or her own computer?
Steps to reproduce are the most important part of any bug report. If a developer is able to reproduce the bug, the bug is very likely to be fixed. If the steps are unclear, it might not even be possible to know whether the bug has been fixed.
Describe your method of interacting with Firefox in addition to the intent of each step.
After your steps, precisely describe the observed result and the expected result. Clearly separate facts (observations) from speculations.
If the bug seems egregious, there might be something unusual about your setup that's a necessary part of the steps to reproduce the bug. See if you can reproduce the bug on a new Ushahidi deployment. If the bug only happens in your existing deployment, try to figure out what settings, plugins, or files in your deployment are needed to reproduce the bug.
How would you describe the bug using approximately 10 words? This is the first part of your bug report a triager or developer will see.
A good summary should quickly and uniquely identify a bug report. It should explain the problem, not your suggested solution.
There are several different products you can reports bugs under in github
Partially based on work by Mozilla Contributors https://developer.mozilla.org/en-US/docs/Bug_writing_guidelines (Creative Commons: Attribution-Sharealike license)