RFC: Naming and checklist for a New Panel Data Econometrics Package

[Nosferican]

Description

UEM is a panel data econometrics package I have been developing and would like to register soon. Finishing last round of testing / unit tests and beta test with some people. Currently the package implements most common linear unobserved effects models: pooling ordinary least squares, first-difference, between (cross-sectional or temporal), fixed effects (cross-sectional, temporal or two-ways), random effects (cross-sectional), and their instrumental variable through 2SLS methods. It also provides estimators for robust covariance matrices (OLS, HC0, HC1, HC2, HC3, HC4, clustered by panel ID, clustered by time ID, two-ways clustering). It also provides a few other diagnostic tests for unobserved effects models.

Similar Products

Similar packages are R's plm, Python's linearmodels or Stata's xtreg / xtivreg functions.

Developing Strategy

I would very much like to prepare for the "submodule" package structure (see JuliaLang/Juleps#8 (comment)). The first alternative would be to do it à la DataFrames.jl with StatsModels.jl and the second alternative would be developing multiple smaller packages PanelLinearModels.jl, PanelNonlinearModels.jl, EconometricsTools.jl etc.

Naming

The similar products and their names are:

• plm: Panel Linear Models
• linearmodels: Linear Models
• xtreg: Fixed-, between-, and random-effects and population-averaged linear models
• xtivreg: Instrumental variables and two-stage least squares for panel-data models

Other thoughts were Unobserved Effects Models (UEM) or Linear Unobserved Effects Models (LUEM). I don't think UEM/LUEM are general enough acronyms. If going with the first development strategy which is more development friendly in early stages a possible name could be Econometrics.jl. If the second approach, a good name candidate could be PanelLinearModels.

Checklist

Some of the steps I have completed in addition to the programing are:

• License (and shield)
• Travis CI (and shield)
• Documenter.jl (hosted documentation and shields)
• CodeCov (and shield)
• Repo Status (metadata and shield)

Are there any other features I am unaware for registering a package best practices? For example, optional à la R Description File.

[tkelman]

The recommendation in the package naming guidelines https://docs.julialang.org/en/stable/manual/packages/#Guidelines-for-naming-a-package-1 is to avoid acronym names, in favor of spelling out the package name a bit. Packages and modules will usually get tab-completed, so it's not too costly to have longer package names, and the discoverability helps potential users see at a glance what your package might be for.