v1 UAT

[dan-knight]

Welcome to UAT for the initial v1 release of CEV! You can find the built package here, including full documentation and a comprehensive user guide (found in the "Assets" section).

Please create a new comment for each suggestion or problem. This will help keep discussions and replies organized. We can also link comments to specific issues/PRs.

Thank you for your feedback!

[tyamaguchi-ucla]

Great news! I might've missed it but it would be helpful to update README.md like https://github.com/uclahs-cds/public-R-ASBiomarkerStratification and add some quick examples. I found this UserGuide.Rmd but it looks like GitHub doesn't recognize .Rmd file.. Would it make sense to have a .md version as well (example - https://stackoverflow.com/questions/31914161/how-to-convert-rmd-into-md-in-r-studio)?

[dan-knight]

@yashpatel6 brought up some errors that should be handled and produce more informative error messages.

• Circular node references #42
• Improper CP values silently rearranged #43
• Bug in y-axis inference #44
• Check for missing root node #45

[dan-knight]

@yashpatel6 had some thoughts on the input format, the column names in particular. Requiring specific column names has certain pros and cons, which we tried to weigh during development and design. I'll outline them here for us to discuss.

Pros

• Requiring a dataframe for the tree structure instead of separate parameters ensures that all data has the same number of elements. Separating each of these into separate lists, for example, would require validation and specific element names to connect values from one parameter to another. A dataframe makes this trivial, as they are all grouped in a row.
• The function does allow custom names for the branch length columns. These are probably the most tightly linked to the data anyway, as they're intended to express variables relating to each subclone (SNVs, etc.).
• Requiring specific columns reduces the number of parameters to the function. Plotting functions tend to require many parameters anyway, so I think that any reasonable way to reduce them is beneficial.
• This is generally the same as the way that @asalcedo-bl originally designed and used the package. I tried to avoid a complete change in philosophy during development. This helps the package stay more stable in development and as it's maintained/extended after release.

Cons

• This format requires specific data preparation, which is extra work for the user. Their data probably won't use the exact column names that CEV requires, so it's not quite plug and play.
• This may not be the standard format for R plotting packages, so there could be a bit of a learning curve for first time users of the package. However, I wonder if this is unavoidable with visualization packages. I tried to put extra effort into the documentation (especially the User Guide vignette) to make up for these issues.

Overall, I thought the pros outweighed the cons - certainly during development. I thought it was reasonable to expect a user to do some data preparation for visualization. As well, the specific column names are the more closely related to the tree visualization itself, not the source data. The hope is that users will be formatting their data for visualization anyway, so it isn't necessarily extra work. Definitely open to specific suggestions and tweaks.