Also successfully checked for Ubuntu 18.04 and R version 4.0.3.

Changes:

• Revision of the underlying data structure
• Roxygen documentation for main functionality
• Vignettes for quickstart and overview of available plots demonstrating the use of their corresponding plot functions
• Introduction of unit tests (package coverage >70%)
• Troubleshooting section covering potential issues during setup
• Finally: Extensive bug fixes and improvements (for a complete overview please check the Phabricator tasks)

After investing several hour trying different encodings, e.g. using raw strings, I still don't find a way to make this work. I also don't see a way of changing the source message, because it's originating from another package.

We should definitely keep it in the README.

Is the order of the rows relevant in any processing step? If not, the tests can be removed. Currently, I don't see a way making it work for both systems I have available for testing (Win10, R 3.6.3 and Ubuntu 18.04, R 4.0.3).

The platform might not be the (only) reason.
@wiesenfa: Which version of R and testthat are you using?

Ok, we can keep them in this release.

Discussed with @wiesenfa that this issue is not critical for release v1.0.

Recap: The initially chosen license (GPLv3) is not compatible with GPLv2 only licenses of dependencies (e.g. ggplot2, relations)

The idea of the web app is to lower the entry level for users that are not familiar with and/or don't want to install R (as this is already a hurdle for some of them).

It works for me on the latest develop branch (#921705).

I don't see that 1. is an issue. Further improvements were done in the scope of T27996 and T27420.

Compensated for 2. Text was revised in T27677.

It sounds nice, but I also think that we can run into cumbersome situations w.r.t. package management and version control with this approach: If the web app is located within the package, for each change to the package itself, it has to be investigated how the change affects the web app. The developer also has to adapt and test the web app then. This also means that for each package release, a corresponding web app has to be provided. In my opinion it makes more sense to focus either on the package or the web app during the development. Probably, we want to improve the web app that is based on a fixed package version x most frequently. This use case is then hampered by this approach as the package itself also evolves.