Something important I think is also, that all plot functions work outside of the report as intended (it is desirable that users can also create their own reports). This includes choosing the correct function and giving an error if a function does not work with single tasks, e.g.

Thanks.
In a single task situation, in practice a task will not have a name, so there should be no title and there should not be the need to set a task name I think....
I'll have a look at it, but please give me some time

I think this should be well thought through before putting into action

it's not because of missing test cases. It is because in certain situation no Kendall can be computed. Don't use treat.na for this.

I agree, it would be nice if the actual number of NAs would be reported (together with the na.treat method) and not the number after na.treat which is then obviously 0.

layouting (circle sizes, distances, font sizes, size of plot) needs to be automatically optimized which I failed so far

Did you take care that FUN="mean" and FUN=mean is handled differently (in the former case it is a name, in the latter case it is a function)?

might indeed reduce complexity, however,

• many functions need to be adapted requiring some care
• behavior is sometimes by purpose different, e.g. there are plot titles with the task name in multi-task challenges while there is none in single task challenges
• many visualizations apply only to multi-task challenges and trying to use them in single task challenges throws an error, this would be needed to be handled
• also reports for multi task challenges contain more visualizations which would be uninformative for single task challenges (could however be handled by checking the number of tasks internally)
• a workaround would be necessary adding a task column to single class challenges (with the same label in every row)

ok

@eisenman : could you please check whether there is something to be done?

can this be closed?

@eisenman: did you take over solving this task? Or should I still do something here?

This is strange. This should normally not happen only if there is a strange package interfering . It is helpful to run sessionInfo() or slightly more detailed devtools::session_info() after a bug happened and report that in the task

There should be a team section where all of you are acknowledged

in my opinion this is a desirable feature