Skip to content

Issues: Quick guide to writing good bug reports

bf4 edited this page Jan 8, 2013 · 2 revisions

Issues

Did you encounter an issue with using metric_fu? This guide will help you to write a good bug report in just a few, simple steps.

First, check if your issue has already reported. Please check the list of reported issues before creating a new issue report. If you find an existing issue report, feel free to add further information to that report.

If possible, please include the following information when reporting an issue:

  • MetricFu version, versions of flay, reek, roodi/metric_fu-roodi, churn, rcov, Saikuro, and metrical, if being used.
  • Operating system type + version
  • Ruby version with patch level. And if you're using rvm, rbenv, etc.
  • Clearly-written steps to reproduce the issue (i.e. "Show me how to show myself." ), including:
    • Command line parameters used, if any
    • gem code in your Gemfile, if any. Gemfile.lock, if possible
    • Any configuration you've made
    • Nature of reported defect (e.g. no graph for Saikuro, not "It doesn't work."). Is it intermittent?
    • Any error messages (including stacktrace, i.e. ""Show me the error.")
    • Things you've tried.
    • A pull request for your fix would be great. Code should have tests.
    • Link to source code, if available

Please make sure only to include one issue per report. If you encounter multiple, unrelated issues, please report them as such.

Simon Tatham has written an excellent on article on How to Report Bugs Effectively which is well worth reading, although it is not specific to metric_fu.

Credit goes to Slic3r Quick Guide to Writing Good Bug Reports for the inspiration and some copy for this writeup