What would go in a 2.0 paper
Outdated: The article is now written on authorea. The draft is open for reading and commenting by all.Contact hamogu (hgunther at mit dot edu) for edit permissions and he'll add you.
- Discuss implementation details, tests with other implementations, show robustness, referring to externals tests such as comparison of PINT (which relies on
Time) with standard pulsar timing package tempo2 [hamogu: To me seems to be a very important point, because this data-driven approach to software quality is still quite rare in astronomy. It would give a reference for the quality of a package not only for astropy users, but for the comparison packages as well.] We've done this type of comparison with different packages both for time and coordinates and to my knowlegde we might well be the first team to run the comparison over such a large number of packages using all sorts of languages. - Give update of new capabilities (enhancements of Quantity, modelling, Tables with time and coordinate columns, etc.)
- Show how astropy fits in a larger ecosystem (VO work, fits files, ...) [???]
(not all of these need to make it into the paper):
- Modeling
- SAMP
-
Cone searchdeprecated in v2.0 as moved out to astroquery - Upgrades to units/quantity (including logarithmic units and [bolometric] magnitudes, speed up with numpy 1.13; interaction with numpy arrays)
- Table grouping; new QTable
- Groundwork between making different classes behave more similarly: ShapedLikeNDArray for shape manipulation, DataInfo property for allowing something to be part of a Table.
- New coordinate framework, including proper motions;
- Inclusion of JPL ephemerides in SkyCoord transformations, barycentric corrections.
- Use of Representations for vector algebra.
- Convolution
- Coordinate benchmarks
- Brief discussion of the ambiguities of Galactic coordinates. (As part of a push to standardize?)
- Implementation of the Galactocentric coordinate frame
-
Analytic functionsin the process of being moved into modeling - The astropy-helpers framework and the package template for (affiliated) packages
- Organizational challenges and how we surmounted them (or didn't...)
- Would it be worth referring to any specific research that has used Astropy in a particularly interesting way?
- wcsaxes and other functionality from visualization for plotting
- major additions to statistics subpackage (e.g., Lomb-Scargle)
- versioning of constants (pending it gets into v2.0)
- difficulty of dealing with poor design choices (arguably units on columns, fixing default unit of angles in SkyCoord)
- difficulty of deciding where general use ends and a "handy feature for some" starts, i.e., how to refuse PRs and how to deal with the maintenance burden.
- update on testing and documentation framework.
Options:
- All contributors ever.
- All contributors after 2013 (paper I). [MHvK: prefer this option; earlier contributors get credit via Paper I]
The first astropy paper has over 200670 citations and counting. In that sense it does a good job of giving academic credit to the early contributors, but not to the new contributors.
Do we want one highly cited paper or dilute the citations?
Options are:
- Ask people to cite only the most recent paper. [hamogu: My preferred option. Simple. Paper I has enough citations to be important. Gives credit to recent contributors. MHvK: agreed.]
- Ask people to cite all papers. (Fine for now, gets messy in 2025 when we have paper VI).
- Ask people to cite paper I and the most recent.
There are precedents to all three strategies.
I think it might help show to a different set of astronomers that astropy is not just a nice new packages full of nifty stuff, but that it very much helps one stop worrying about whether, e.g., leap seconds are properly included, whether a particular transformation also works near the poles, etc. In this respect, it may also be useful to have some examples of external usage -- e.g., that using Time the new pulsar timing package PINT "can already produce residuals from most "normal" timing models that agree with Tempo and Tempo2 to within ~10 nanoseconds." [1]
All the best,
Marten
[1] https://github.com/nanograv/PINT
We could consider asking people to cite all the papers up to the present, so e.g.
Astropy Collaboration (2013, 2015)
to try and avoid the citation dilation issue. Though I think we should think about what is more important - having one paper with 500 citations or five papers with 100 citations - the latter does a lot more for most people's h-index.
A somewhat radical idea would be to have 3 papers, possibly with different author lists:
(1) Devoted to discussing new features since the last release, identifying areas that have seen the most growth and identifying areas that need support from the community going forward. Being honest about critical subpackages that need support and maintainers with evidence of their impact might be useful for future funding proposals? It would at least provide a place to cite for justifying the need for money and people,
(2) What we have learned about the development model? I think this is sufficiently important that it warrants its own paper. I'm sure many of you have great ideas for what could go in a paper like this.
(3) Astropy-helpers, the affiliated package template, and affiliated packages. Discuss the broader ecosystem and highlight success stories. Not as sure about what would go in this paper, but I think it is a big enough topic.
Of course, these could all be stuffed in a single paper as sections, but I think Astropy is mature and impactful enough to deserve a paper series.