Interviewee's often search published qPCR data sets for information on what probe sets, primer sequences, qpcr machines and prep kits to use. Perhaps adopting a file format for this data (with explanatory vignette) could simplify the process of reproducing results. RDML attempts to wrap all meta data with cq results in one large file which may be difficult for users to read? Could it also hold links to protocol.io for more explicit assay details?

tidyqpcr already supports using multiple genes for normalisation in the function normaliseqPCR, by supplying a character vector of multiple TargetIDs. However, users don't seem to know this. We need to highlight this in the README.md and in function documentation and vignettes.

Apparently the devtools::install_github("ewallace/tidyqpcr",build_vignettes = TRUE) doesn't work for (some) Windows machines. We should update README.md to describe what does work.

MIQE guidelines recommend Cq for quantification cycle, but currently tidyqpcr uses Ct (crossing time, or counts to threshold). Should we change this?

Create a logo for tidyqpcr? Perhaps in tidyverse-inspired hex format?

If you would like your package to also be submitted to Journal of Open-Source Software (JOSS), it should include a paper.md file describing the package. More detail on JOSS’s requirements can be found at their website.

https://devguide.ropensci.org/guide-for-authors.html

README and paper #44 should highlight the approach that everything is a tibble / data frame so that users only have to learn one standard kind of object. This contrasts with earlier qPCR R packages that use S4 classes and have many different kinds of objects.

Make an alias function so can call either normaliseqPCR, or normalizeqPCR, similar to summarise/summarize in dplyr.

Change tidyqpcr default column to SampleID, from Sample, to clarify that this is a unique identifier of a nucleic acid sample.

This fix could be wrapped in with #39, changing to TargetID from Probe, again to clarify that this is a unique identifier of a primer set or primer set / probe combination.

Maybe discuss with a couple of other users before changing.

Tidyqpcr needs to have a test suite to be submitted to rOpenSci. This needs to be implemented with testthat.

Key unit tests are the interesting/workhorse functions that calculate:

• calculate_normvalue
• calculate_deltacq_bysampleid
• calculate_deltadeltacq_bytargetid
• calculate_efficiency
• calculate_efficiency_bytargetid

Maybe also the creation and labeling functions?

• create_blank_plate
  *label_plate_rowcol

Later can think about the other functions for curve data:

• debaseline
• calculate_dydx_1
• calculate_drdt_plate

(edited to reflect updated names from #62)

Package checks with devtools is giving some warnings with inconsistent vignette names in different places.

Also browseVignettes("tidyqpcr") is not giving any results. Despite vignettes existing.

We should:

• fix these by giving vignettes coherent names
• check that all cross-references between vignettes and help/README files are in place and accurate.

After some work, we still have some "no visible binding" warnings when running devtools::check() / R CMD check.

As of commit ee6d192, the remaining complaints are:

   calculate_deltacq_bysampleid: no visible binding for global variable
     ‘sample_id’
   calculate_deltacq_bysampleid: no visible binding for global variable
     ‘.’
   calculate_deltacq_bysampleid: no visible binding for global variable
     ‘.value’
   calculate_deltacq_bysampleid: no visible binding for global variable
     ‘value_to_norm_by’
   calculate_deltacq_bysampleid: no visible binding for global variable
     ‘value_norm’
   calculate_efficiency_bytargetid: no visible binding for global variable
     ‘.’
   calculate_normcq: no visible binding for global variable ‘.’
   create_blank_plate: no visible binding for global variable ‘well’
   display_plate: no visible global function definition for ‘aes’
   Undefined global functions or variables:
     . .value aes sample_id value_norm value_to_norm_by well

It would be good to fix those.

In some cases, the variable is defined in a tibble in function call before it is used (e.g. value_norm defined by dplyr::mutate), but R CMD check is still unhappy.

See r-lib/devtools#1714

See Sarthak Sehgal's software citation project.

For context, how to cite software by Mike Jackson.

Edit to manage the NAMESPACE (which functions are imported/exported etc) automatically with roxygen2. See guide in hadley's book.

Currently we use roxygen2 for documentation, but do the NAMESPACE by hand, and there are some problems with Imports/Depends (see #21). This should be fixed and made more maintainable by also automatically managing the NAMESPACE.

Laying out plates with multifactorial designs is a common user problem. We need functions to make this easy. Including for primer calibration.

We need a function to estimate the efficiency of primer amplification.

Currently this is done informally in calibration_vignette.Rmd, by matching the slopes of loglinear standard curves to the expected log2. It would be better to have a function
estimate_efficiency <- function(Dilution,Ct)
that applies a (log)-linear model to estimate the slope and converts to an efficiency value in %.

As the MIQE paper says:

PCR efficiency = 10^{−1/slope} − 1, when the logarithm of the initial template concentration (the independent variable) is plotted on the x axis and Cq (the dependent variable) is plotted on the y axis.

Informal description here:
https://toptipbio.com/calculate-primer-efficiencies/

After loading tidyqpcr, the pipeline operator is no longer found. If I try to load dplyr afterwards to get it back, I receive the following error:
Error in value[3L] : Package ‘dplyr’ version 0.7.6 cannot be unloaded: Error in unloadNamespace(package) : namespace ‘dplyr’ is imported by ‘tidyqpcr’ so cannot be unloaded.

normalizeqPCR currently uses median Ct of reference gene(s). Can we make it an option to use mean rather than median?

Also document in terms of delta delta Ct method.

Relates to #17

Write a short email that can be forwarded by eLife open innovation colleagues and others, inviting people to use/test/contribute to tidyqpcr.

Intro needs to be 3 sentences.
Perhaps we can include more details after that.

See Using ggplot2 in packages vignette.

Go through code according to the tidyverse style guide, using the styler package.

Is it confusing that we call the measurement variable "Probe", when it could equally refer to a Primer Set (for SYBR dye-style) or a fluorescent-quenched probe (for Taqman-style)? We cover this in documentation, but worry that some users might be confused, or choose not to use tidyqpcr as a result.

Ideas:

• Target
• Primer
• Probe (no change)

Question from @j-aux

tidyqpcr is intended to be
a) a user friendly and flexible tool for analysing qPCR data and
b) an educational tool for users to learn how to conduct MIQE-compliant qPCR experiments and also
c) a friendly way to learn the basic building blocks of tidy data analysis.

We are actively engaging with users to gain feedback on documentation and usability. If you are looking to help improve tidyqcr for everyone, or just interested to learn more, please volunteer to be interviewed. Add your name as a comment below, and we will be in touch!

In the calibration vignette the rowkeys object is defined as a dataframe not a tibble.

rowkey <- data.frame

Probably should replace this with tibble to avoid confusion!

Create a function that outputs out a modified plate map clearly stating which target probe to place in which row (i.e. target_id as row name) and which columns have the same sample (sample_id as column name). This can be physically printed out to minimise plate loading mistakes.

Check the MIQE-recommended GeNorm method, and compare in detail to tidyqpcr's normalizeqPCR function, which is geometric (Ct/log-scale) and uses median.

Method is described in Vandesompele et al., Genome Biology, 2002, 'Accurate normalization of real-time quantitative RT-PCR data by geometric averaging of multiple internal control genes'.

According to the geNorm website, this method is implemented in commercial software qbase+.

Fixing this will likely require adding an "efficiency" argument to normalizeqPCR.

We need a short developer guide including:

• welcoming language
• how to contribute
• procedure for forking/branching/pull requests
• R package requirements
• anything relevant for roxygen2 documentation
• code style to follow

We should officially decide what to call tidyqpcr in print. The R package name is already lower-case, which is fine and avoids issues with typing things wrong. But in print (e.g. in the paper #44) we could reasonably call it tidyqPCR as PCR is generally capitalised. It would be nice to be consistent.

Check conventions on which way round delta delta Cq goes.

As currently queried in deltacq_96well_vignette.Rmd, section "Plot delta delta Cq (log2-fold change) for each target gene":

NOTE: is this meant to be upside-down here? Or need we reverse the sign on delta delta Cq??

R functions in R/ need basic introductory documentation.

We should do this in roxygen2 style as described here: http://r-pkgs.had.co.nz/man.html

There seem to be repeated problems with windows users installing tidyqpcr. It's not quite clear why. Problems probably lie upstream with rtools and devtools, see devtools installation instructions.

We should fix or at a minimum write better installation instructions, because this is a big barrier to users.

Goal was to create a 384 well plate using the label_plate_rowcol(create_blank_plate(),rowkey,colkey) function but using my own manually defined colkey.
Documentation in help for label_plate_rowcol() states there may be a problem if "WellC is a character instead of a factor or integer".
I received the following error: Error: Can't join on 'WellC' x 'WellC' because of incompatible types (integer / factor)

Problem was solved when I manually made WellC factors. Documentation should be updated that integer WellC values cause issues.

Add capability to import RDML (Real-time PCR Data Markup Language) format files.

Try using the RDML package.

So far the create_plate helper functions assume that plates are in 8x8 (or 6x8, 4x4) tight blocks. This is fine for 96-well plates with standard multichannel pipettes, or for 384-well plates with variable width pipettes. However loading 384-well plates from a 96-well plate or strip with fixed-width multichannel pipettes results in loading every 2nd well with one pipette run. This could result in adjacent wells being "paired" if we move the multichannel 1 across for a duplicate. Or adjacent wells being unrelated if two entirely different approaches are taken.

First step is to ask for some example plate layouts from real users, then figure out what is needed.

Related to #20 and #2.

Take functions defined in calibration_vignette.Rmd and move them into separate R script file, following package guidelines in the R packages book

Current edition of tidyqpcr works for SYBR safe experiments, i.e. 1 probe in 1 colour per well. The other major approach to qPCR is hydrolysis probes (TaqMan), which has multiple probes measured in different wavelengths per well. tidyqpcr should cope with this fine, but the plate plans & display_plate will need adapting. We may need a new function to read multicolour data.

Help wanted! Good first issue for someone with Taqman data, especially from a Roche Lightcycler.

Plates need to have

• Well
• some other variables

Function should wrap readxl::read_excel, check info, maybe add WellR and WellC columns?

To load ingredients to a qPCR plate automatically, we need to specify reagents and amounts in a source plate to be loaded in the destination plate. This is called a pick list. To enable this, we need appropriate functions and a vignette in tidyqpcr. @j-aux is planning some experiments for this soon, so we can work with her to implement.

This issue is related to, but distinct from, #5. Pick lists would be useful even for loading smaller (e.g. 384-well) plates.

There's a new implementation of the pipe operator in magrittr 2.0, see tidyverse blogpost

Although it's been checked for not causing errors, there is still a likelihood of errors arising from explicit return statements in functions.

We should check this and make sure nothing in tidyqpcr goes wrong; and that our use of return conforms to tidyverse style guide.

The current delta-cq vignette shows how different forms of qPCR data can be incorporated and analysed by tidyqpcr but is not a good example of plate design according to the tidyqpcr ethos. A new vignette going from raw qpcr machine data to publishable results with MIQE compliant, tidy plate design would be a perfect stepping stone for new users.

Currently tidyqpcr calculates delta Cq for targets against reference set. We need to calculate delta delta Cq for the change in delta Cq between samples or conditions.

Needs a new calculate_ddcq function, or similar.

@ewallace to implement using recent reporter-gene qPCR data from Jamie Auxillos as test dataset.

Some of our users may want to be able to make bar-and-stem graphs of qPCR data. We should have a vignette explaining how to do that, and various alternatives such as dot plots, how to use shape/colour/dodge/etc to make distinctions clearer. All concisely within the framework of a sample qPCR experiment, referring to other resources for more general solutions.

This would be most useful within the framework of a published PCR experiment. Could we ask e.g. David Barrass for data corresponding to a published dataset?

Suggested other resources:

• Beyond Bar and Line Graphs, Weissgerber et al
• Fundamentals of Data Visualization, Wilke

Complementing the real-data vignettes, add a .Rmd tutorial describing how to design plate layouts.

The rule of thumb is to have a column describing everything you might need to know about a well contents during analysis (biological replicate, technical replicate, strain, treatment, etc). Can either make this through constant-identifiers, e.g. Sample column with entries like WT_hot_A and then use separate. Or, can start with the components Strain, Treatment, BioRep, then make Sample using unite.

Explicitly refer to the MIQE guidelines in this.

We want an open-source and tested algorithm to calculate Ct/Cq from raw amplification curves.

A threshhold method is probably best, see T Nolan, J Huggett, E Sanchez, Good practice guide for the application of quantitative PCR (qPCR), LGC (2013).

The underlying principle of the threshold method is that information related to the target quantity
is available in the log-linear phase of the amplification curve. By simply detecting the cycle where
the log-linear phase of the amplification curve crosses an arbitrary threshold level, information
about relative target quantities in different samples is obtained.

It is recommended to set the threshold as follows:

• Sufficiently above the background fluorescence baseline to be confident of avoiding having
  any amplification curve cross the threshold prematurely due to background fluorescence, and
• As low as possible to ensure that the threshold crosses at the log-linear phase of the
  amplification curve where it is unaffected by the plateau phase.

See also chipPCR paper, who have an implementation in R based on S4 classes. As they say, "Pre-processing in most commercial cyclers is a black box, which restrains reproducible research".

Our multifactorial vignette is fairly complicated, as pointed out by @seaaan on https://discuss.ropensci.org/.

Could we complement it by a simpler 96-well vignette with someone else's real data?

Vignettes currently give examples of taking median or mean of technical replicates, but don't really explain it. Since this is a core capability of dplyr, using group_by and summarise, we don't need a separate function or help section. But we do need to tell users how it works and point them to generic dplyr/tidyverse help.

Currently, the normaliseqPCR function only groups by Sample. Therefore, if you are trying to normalise the same construct to the same control but for two or more experimental replicates the function doesn't work as expected. The function will group all the control's Ct values and calculate a cross-experiment median to normalise all construct's Ct. Instead, if provided with a another variable, s.a. "exp_rep", the function should normalise the constructs by the median of their respective experimental controls.

Add thanks to collaborators in README.md.

• @seaaan and Stuart McKellar for help with 96-well vignette
• @j-aux, @RoseyBayne, Liz Hughes, Stuart McKellar, David Barrass for user interviews.

Anyone else?