Given the counts that have accumulated within less than three weeks, I think a count of 30-day/monthly downloads would be both fair and typical. I suppose you’d add that to the stats file alongside the all and recent counts?
Python packaging has standard URL labels that include an issues label, so we should look for project.urls.issues (and potentially the aliases listed at the linked page too, e.g. bugs) and encourage people to use that mechanism.
I’d suggest we also provide a general link to the plugin’s repository as well, which we don’t have to rely on the pyproject.toml for, we already have that info in the plugin database.
Here I’d also suggest reusing the standard mechanism, encouraging authors to use the project.keywords field and then extracting that. We’ll need the search to match on substrings of the plugin name too though, in case a plugin doesn’t specify any keywords.
Isn’t that already possible by sorting on the Features column?
Right now “recent” is defined as 180 days. I’d just change it to 30.
I’d just want to make sure we have a fallback for plugins that don’t add the project.urls.issues or bugs. Right now, for example, I see that “description” is missing on one of mine (mattersim)
As for citations, GitHub suggests CITATION.cff files, but I kind of like the duecredit package which handles NumPy and SciPy, as well as MDAnalysis already.
My concern is that as the number of plugins grow, we’ll want more organization than a sorted list. I feel like ~30 is starting to get to that point and certainly ~50 will start to feel a bit overwhelming.
I’m also thinking about some ways to add a “plugin gallery” to the website - since some users don’t realize we already have plugins for RDKit, xtb, etc. based on the survey.
We could just fall back to the main repo URL. Or, the script in avogadro/plugins that extracts the metadata from the plugins’ TOML files to generate the index could automatically generate the appropriate issues URL for any plugin that is on GitHub and doesn’t manually specify project.urls.issues.
Not sure I’m a huge fan of something that’s Python-specific, encodes the metadata using Python code, and is a solution specific to that one implementation. This CITATION.cff is GitHub’s own solution, but it is at least supported by Zotero and Zenodo. But I don’t have strong feelings. It’s a shame there’s no standardized way to handle companion publications, really – it would be good if citations of academic papers were part of the SPDX Bill of Materials specification, for example.
That would be my suggestion, since most (all?) of the current plugins don’t use project.urls.issues
It’s fairly common for people to list things in the README, but that’s not very uniform and I’m a little reluctant to try to extract DOI or BibTeX from the README.
I guess the alternative would be to add something like pyproject.urls.doi as a list in the pyproject.toml as an alternative if the CITATION.cff isn’t found.
Thoughts? Ideas? Right now, the keywords are stored in the model but in a hidden column. (Not that any current plugin includes keywords in their pyproject.toml yet.)
links to the GitHub issues or relevant bug tracker)
