How to report issues, raise suggestions and feedback

library(duflor.gui)

This article mostly deals with using

When issues arise, they must be tracked on the package’s GitHub page, under “https://github.com/Claudius-Appel/duflor.gui/issues”.

General etiquette and different types of ‘issues’

Although they are all conglomerated under the same name “issues”, generally reports are differentiated into two categories:

• Bug Reports
• Feature Requests/Suggestions

Bug Reports

Bug reports… are somewhat obvious at first. However, there is a great difference between what constitutes a good, a bad, and a useless bug-report.

To be useful, there is a bare-minimum amount of information that must be provided, including

• The package-versions of duflor and duflor.gui which are used.
  • If the package is run from source and is under version-control via git on the local machine (instead of being an installed package within R), the SHA of the currently checked-out commit must be provided.
• Detailed, clear instructions required to reproduce the issue.
• An example-data set which exhibits the problem. In the case duflor.gui and duflor, this would often include example-images.
• Information on the system’s specifications (OS, hardware configuration, etc. pp.)
• The R-Version in use
• Notes on all warnings/errors emitted to the console before/when encountering the bug.
• If generated, the error_state.rds-file. This file is generated when errors occur in certain sections of the code, but not in all. It bundles the state of the app’s data structure at the point at which the error occurred, including its configuration. However, it does not include the raw image-files as input, which must be supplied separately. For more details, see vignette("saving-and-restoring-application-states", package = "duflor.gui"). When reporting bugs, it is heavily suggested to supply this file.

The more information is available, the easier it becomes to identify the actual issue.

Feature Requests

To keep development efficient and reasonable, there are a certain number of requirements for reporting problems or requesting features. A feature request should clearly define what additional feature should be implemented. As with bug-reports, the more information provided, the easier it’s viability and ease of implementation can be assessed.

It should clearly describe what should be implemented, as well as why (and in broad strokes how) it should be implemented.