Release 1.0.0

[strengejacke]

[DominiqueMakowski]

For plotting, currently w do a lot of guesswork to pick what best goes in x / color / alpha depending on the type of the variables (factor, continuous etc). This is probably over-complex and not optimal anyways, so we could simplify the rules and streamline the inner workings. We could have the same internal for every estimate_* functions with the following aesthetics:

• y = whatever is predicted, means, prediction, contrasts, slopes etc.
• x = first argument of by
• color = second argument of by
• alpha = third argument of by
• Everything else goes into facet_wrap

[strengejacke]

Sounds good! x could be either first value of by, or first value of contrast or trend (if available - I think we save all the information as attributes).

[strengejacke]

I think we should have a 0.9.0 release soon, we have added a lot of new features the last time. Which issues would you like to be fixed for 0.9.0?

[DominiqueMakowski]

We can focus on bugs / broken vignettes since there's not a lot and leave plotting refactoring for 1.0 ?

[strengejacke]

Yes, agree. Only thing which I think we really should consider is renaming the method argument in estimate_contrasts() into comparison or something similar. Since we now can literally have any arbitrary comparison, method is no longer appropriate. Even in general, "pairwise" is not a method per se, but the kind of comparison. WDYT?

[DominiqueMakowski]

true, comparison sounds good

[DominiqueMakowski]

of type which is more generic

[strengejacke]

type could be confused with the type argument in predict(). Furthermore, comparison = "(b3-b1)=(b4-b2)" indicates a comparison, but not really a type? In the particular case of contrasts, comparison seems more generic to me.

[DominiqueMakowski]

agreed!

[strengejacke]

Just FYI, see docs for hypothesis here: https://marginaleffects.com/man/r/comparisons.html
and here: https://marginaleffects.com/chapters/hypothesis.html