The #R econometrics package {fixest} will be removed from CRAN next week. I'd like to have an honest conversation with the gatekeepers because I can't possibly understand. #Rstats #CRAN 1/

Facts: • 7 Feb: demand from CRAN to fix stg in 2 weeks (21 Feb) to avoid removal • 17 Feb: I submit {fixest} version 0.10.2 which fixes issue + adds many stuff 2/

• 21 Feb: notice of archival from CRAN bc changes not made in time... Note that in v0.10.2 I introduced new features and **new tests** and a new test made a low level error pop 3/

For those not familiar with pkg dvt: when your pkg contains non-R code (usu. c/c++), special checks happen from time to time from CRAN side. If an error pops, then you are to fix it asap. These checks are imptt to ensure all pkgs work well, yet what I'm questioning is: 4/

A) Why give only **two weeks** to apply a fix? B) Why isn't there any delay when the said bug was fixed but another (bc of new features!) has crept in, and **new tests were written**? 5/

Because, hold on, the said stringent checks only happen on the test/examples in the pkg... that **you** (the maintainer) wrote! This means that pkgs with no tests/no examples are never worried by the 2-weeks command. Even though their code can be super buggy at a low level. 6/

Now the point I wanted to come to: The super stringent CRAN requirements: What kind of incentives does it create? Very simple: Don't write tests, don't make your pkg robust, (bitter me would even add "don't contribute to OSS") and your life will be easier. 7/

I'm really open to counter-arguments bc obviously there's stg I missed. It would help me accept the situation much more easily. Ideas @eddelbuettel, @AchimZeileis, CRAN team in twitter? 8/

Btw make no mistake: I love the R project and CRAN/R core team are doing a fantastic job keeping a stable software with 10,000s of packages (that's quite a feat!). I'm only questioning the specific non-R code rules (esp. the 2-weeks delay). 9/9