WIP: JOSS paper

[IndrajeetPatil]

Closes #47

@easystats/maintainers This is just a rough draft and needs to be significantly cleaned up, but just wanted to get started with a rough draft to get the ball rolling.

Current state of the manuscript can always be seen here: https://github.com/easystats/report/actions/workflows/draft-pdf.yml

[DominiqueMakowski]

oh boi

[IndrajeetPatil]

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 72.16%. Comparing base (08b374d) to head (6bf208b).
Report is 3 commits behind head on main.

❗ Current head 6bf208b differs from pull request most recent head 80f152e

Please upload reports for the commit 80f152e to get more accurate results.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #342   +/-   ##
=======================================
  Coverage   72.16%   72.16%           
=======================================
  Files          53       53           
  Lines        3643     3643           
=======================================
  Hits         2629     2629           
  Misses       1014     1014           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mattansb]

What contribution can I have to a paper introducing a package I don't really endorse using? 😅

[DominiqueMakowski]

What contribution can I have to a paper introducing a package I don't really endorse using?

You can add a critical perspective, or...

just fasten your seatbelt and enjoy the ride cos the future is coming baby 🚀

[rempsyc]

Good job so far!

[rempsyc]

It seems there are currently two references for easystats, which one is correct?

citation("easystats")
#>   Lüdecke, Patil, Ben-Shachar, Wiernik, Bacher, Thériault, & Makowski
#>   (2022). easystats: Framework for Easy Statistical Modeling,
#>   Visualization, and Reporting. CRAN. Available from
#>   https://easystats.github.io/easystats/
report::cite_easystats()
#> - Lüdecke, D., Makowski, D., Ben-Shachar, M. S., Patil, I., Wiernik, B. M.,
#>     Bacher, Etienne, & Thériault, R. (2023). easystats: Streamline model
#>     interpretation, visualization, and reporting (0.6.0.7) [R package].
#>     https://easystats.github.io/easystats/ (Original work published 2019)

^{Created on 2023-02-26 with reprex v2.0.2}

[IndrajeetPatil]

Second one.

We should update the first citation.

[bwiernik]

What contribution can I have to a paper introducing a package I don't really endorse using? 😅

Let's get some options/arguments added to match our preferred styles

[mattansb]

My issues are with reporting of statistical models: Overall, I feel like this functionality is aimed at users who don't understand their models, and we aren't actually helping them understand better, we're just giving them a shortcut to the end-goal of "let's write a paper!".

1. We make here some reporting decisions that are not uniformly accepted as the "standard reporting methods" across many research domains, meaning that either many will not use the package or (worse) many will adapt out guidelines as some new gold-standard even if it does not match their actual needs.
2. I think standardized coefficients should not be part of the default output for regression models.
   • and if they are they shouldn't be the "refit" kind that can have a mis-match in meaning between the raw and the standardized coefs (e.g., when there are interactions!)
3. I think we should not be reporting inferential statistics with "default" thresholds for Bayesian models, as these depend on scales, domain and hypotheses, and including these will lead to bad inference.

Having formatted tables of "here are things you probably should report" is perhaps easy-stats, but having results as formatted text out-of-the-box makes mindless-stats IMO. We've put out a very tempting package, and I feel we have a huge responsibility to do what we can to make sure it is abused as little a possible. So for this package to be useful but not mind-numbing it probably needs to have less "clean" outputs. I.e., something that cannot just be copy-pasted, but that would require editing by an actual human.

I have no issues with reporting data frames (though I prefer datawizard::describe_distribution()), table 1, htests, packages, ...

[IndrajeetPatil]

Mattan, when asked to use report:

[IndrajeetPatil]

How should we proceed here? Any concrete steps we can follow? Or should we just abandon this publication as we are filled with self-doubt?

[DominiqueMakowski]

It's busy-time, that's all, but we'll get this pushed, don't worry :)

[rempsyc]

Agreed, once I land in Berlin I think things will calm down for me. As a bonus, we’ll be able to meet in person to discuss the paper :)

[bwiernik]

I think a good perspective for the paper and the package generally is that {report} provides templates for reporting various types of statistical analyses completely and transparently following best practices and style guides like the APA manual. It's not that it's about automating statistical thinking, but rather providing scaffolding for "there's all of these different numbers I could report for this analysis, what do I need to show and how?"

[IndrajeetPatil]

I think it was premature to work on this paper. There is no consensus among the team about the utility of this package.

We can revisit this maybe in a couple of years; we will probably have a better perspective on the scope and the utility of it by then.