jmobrien/speccurve

R package for constructing, estimating, and visualizing results from specification curves

speccurve's Issues

Need to design and add method for summary(), to facilitate easier review

Task: code refactoring to make debugging/model checking easier

Most important is separating out the code for iterating through spec estimations from the code that actually estimates individual specs. But also

1. separate out model crossing/generation code to own module
2. separate out perm testing to own module
3. final processing in s.curve.update() cleaner
4. general cleanup and some thoughts about which functions are public

flexible definition of "treatment" outcome (rename parameter?)

The key test of interest could be a lot of things: an interaction term in more complex situations, or even something more esoteric like a comparison of model fits with and without a term in ordinal regression. The first feels easy enough, while the last feels like a separate program entirely. So maybe there's a line.

But, ideally, perhaps development should limit itself to being primarily a framework within which you can construct and run complete model sets, while staying minimal enough to allow you to set up analyses.

Is there some kind of approach that lets you specify an arbitrary outcome that can be captured and compared across models? The "tidy" methods from broom (and broom.mixed) seem like guideposts/potential directions here. They're already being used, of course, but it will need more thought.

Visuals: update plotting to (potentially) include importance of different aspects, per original paper visualizations

The original s-curve paper added something under the plotting that let you compare against the different aspects. Ideally, it would include:

1. clustering by category, similar to original. should rely on categorization already used in spec definitions, and should be able to select certain aspects?

2. Can do general inclusion/exclusion of categories

3. Can select particular individual parameters (distinct from groups) and look at inclusion/exclusion?

4. Maybe something similar for the dot colors, if desired?

5. Maybe pretty up the design aspects a bit as well, while you're at it?

add tidyeval for model specification + lists of unrelated models?

List specification would offer a general purpose solution for complex s-curve specification that could replace the limited additional functionality provided by "extra.models" parameter.

Could have standalone list vs. main specification, or list items to just change particular aspects.