Should maintainer list be updated?

[hseg]

Considering the project has expanded beyond one person's private project, and @brechtm hasn't been active since 2021-06, perhaps the authors/maintainers keys in setup.py/pyproject.toml should be updated? Given I'm updating other metadata in #168, I thought it prudent to ask.

At the very least, it makes sense to clarify the policy of when people get listed there and what is meant by these keys.

Going by commit counts and consistent activity, I'd recommend adding @yarikoptic and @tmorrell, but this is based on blind interpretation of the commit statistics.

Checking:

Contribution statistics

I'm not sure when the organization started, so I'm taking the arbitrary cutoff of 2020-01-01 (the year @brechtm stopped contributing) as my indicator. There have been 496 commits in the repository overall, 135 since that date. Taking as an arbitrary cutoff that a person should've made 10% of the commits for nomination, that suggests adding @yarikoptic and @tmorrell to the list.

$ git rev-list --count --all
496
$ git rev-list --count --all --since=2020-01-01
135
$ git shortlog -sen --since=2020-01-01
    61  Yaroslav Halchenko <[email protected]>
    13  Tom Morrell <[email protected]>
    12  Brecht Machiels <[email protected]>
    11  Florian Matter <[email protected]>
     9  Tom Morrell <[email protected]>
     7  Jesse Vickery <[email protected]>
     5  John T. Wodder II <[email protected]>
     3  Zeping Lee <[email protected]>
     3  auto <auto@nil>
     2  Alexandru Fikl <[email protected]>
     2  gesh <[email protected]>
     1  Bart Moelans <[email protected]>
     1  John_Theo <[email protected]>
     1  Ryan Ly <[email protected]>

$ git shortlog -sen
   343  Brecht Machiels <[email protected]>
    65  Yaroslav Halchenko <[email protected]>
    13  Tom Morrell <[email protected]>
    11  Florian Matter <[email protected]>
     9  Tom Morrell <[email protected]>
     7  Jesse Vickery <[email protected]>
     7  John Vandenberg <[email protected]>
     7  Matthew Brett <[email protected]>
     5  John T. Wodder II <[email protected]>
     3  Zeping Lee <[email protected]>
     3  auto <auto@nil>
     2  Alexandru Fikl <[email protected]>
     2  Joshua Carp <[email protected]>
     2  davidlesieur <[email protected]>
     1  Bart Moelans <[email protected]>
     1  Jasper Op de Coul <[email protected]>
     1  John_Theo <[email protected]>
     1  Miguel Paolino <[email protected]>
     1  Nick Doty <[email protected]>
     1  Niklas Griessbaum <[email protected]>
     1  Ryan Ly <[email protected]>
     1  bbm <[email protected]>
     1  gesh <[email protected]>
     1  gmarco <[email protected]>
     1  hetsch <[email protected]>

[yarikoptic]

What about

• making it Brecht Machiels et al. or Citeproc Team as for the "authors"
• working out basic CITATION.cff with actually listing all the authors (with some specific programmatic cutoff on number of contributions; e.g. of a random number of 5 contributions... we did smth like that some JOSS papers on datalad/heudiconv/etc)?
• enabling zenodo integration (must be someone else since I can't due to https://github.com/zenodo/zenodo-rdm/issues/1118

NB ideally we should have it fully automated. In DataLad we do smth along those lines https://github.com/datalad/datalad/blob/maint/.github/workflows/update-contributors.yml using "our" https://github.com/con/tributors/ but it still needs work for fuller automation.

[tmorrell]

I like Brecht Machiels et al. for authors.

We've been using codemeta.json for our software metadata, and have some tooling that can do both Zenodo archiving and CFF generation https://github.com/caltechlibrary/iga. I can work up a PR, unless folks have a strong preference for something different.

[hseg]

I'm on board, and actually like the more personal et al, though if we do this I'd suggest removing the author_email and instead directing users to the bugtracker as a central method of communication with the devs.

[yarikoptic]

I am open to try using codemeta.json and see how that goes!

[hseg]

TIL about these tools, they look extremely useful for certain workflows! It was already useful to open this issue to get them this exposure.