Publish list of authors with the PDF of the specifications on Zenodo

[Remi-Gau]

discussion between @Remi-Gau and me just now:

1. the BIDS specification on zenodo is just the PDF, the entry on Zenodo is created and updated manually:

   bids-specification/Release_Protocol.md

   Line 217 in 8c9fa11

   ### 10. Uploading the stable PDF to Zenodo

2. this PR was working under the assumption that Zenodo pulls the repo contents via a webhook (on release), thereby automatically parses the newly created CITATION.cff file to update the zenodo metadata, and makes the PDF available with the correct metadata
3. HOWEVER, this is not what happens (see point 1)
   1. we never commit the PDF to our repo history:

      bids-specification/Release_Protocol.md

      Line 142 in 8c9fa11

      ### 6. Get the built PDF

   2. if proceeding with this PR as is all we would get is an archive of the bids-specification repo (without PDF) and the correct metadata
   3. (but we want the PDF without the other bids-specification repo files)

Potential solutions

1. switch on zenodo for the bids-specification repo --> on release, an entry will be automatically created with correct metadata informed by the CITATION.cff from this PR
   1. in a next step, we manually upload the PDF to the other zenodo entry (as before)
   2. we copy the CITATION.cff metadata from the bids-specification record and add it to the manually created zenodo entry
   3. this is potentially laborious, but allows us to keep the present setup with minimal changes
   4. (we'd have to check exactly how laborious the copying over would be)
2. try whether dumping a CITATION.cff (from this repo at release time) together with a pdf into the manually curated zenodo entry can automatically updated the zenodo metadata (i.e., update the info without going via the github webhook)
   1. UPDATE: Remi tried, and this doesn't work: [INFRA] use tributors to list contributors and CITATION.cff for referencing #1115 (comment)
3. create a new repository under the bids-specification org called "pdf-releases" (or similar), and hook it up to zenodo. Then start putting the BIDS spec PDFs in there piece by piece, always releasing each version. For the most recent ones, start adding the version-specific CITATION.cff file in addition to the version-specific PDF (for earlier versions, just upload the PDF, as we didn't have the CITATION.cff file back then).
   1. Potentially contact zenodo on whether they can remove / redirect the old DOIs to the new ones --> but little hope for that, see their FAQ: https://help.zenodo.org/ ... for records that have existed for a long time, modifications are unlikely to be made.
   2. if zenodo doesn't help us redirect, we will have two DOIs for BIDS spec PDFs from version 1.0.0 up to 1.8.0, which is unfortunate but maybe okay.
   3. (or we only start releasing spec PDFs from the new "pdf-releases" repo starting with version 1.9 -- then each version would have one DOI, but spec versions would be scattered across two zenodo records, which isn't too great either, as each zenodo record also has a "general DOI" that points to all versions of that record, and we'd thus have two such "general bids spec pdf DOIs")

Originally posted by @sappelhoff in #1115 (review)

[effigies]

I'll just note my suggestion from yesterday was to go ahead and release with the new process, and then copy over all the old PDFs as additional versions. The reason is that it would test the new setup, and have 0 chance of accidentally copying to a new Zenodo record that ends up not being the one that gets automatically generated. Additionally, it would save time, and IMO copying old versions is just bookkeeping.

@sappelhoff said that the process wouldn't be so tedious that it would introduce a barrier to release, and you could test on the Zenodo sandbox before doing it officially. That's also fine with me.

In any case, we should update the old Zenodo records with Superseded-by or similar annotations to ensure that people get redirected (by metadata, if not HTTP 308) to the new record when following old DOIs.

[effigies]

Actually, who manages the old Zenodo record? I thought I set it up, but it's not in my profile.

[Remi-Gau]

Actually, who manages the old Zenodo record? I thought I set it up, but it's not in my profile.

I assumed it was @sappelhoff

[sappelhoff]

it's under the @bids-maintenance GitHub user:

1. open private browser
2. log into GitHub with @bids-maintenance (see credentials in our bitwarden)
3. open zenodo.org in that browser and click "log in via GitHub"

[effigies]

Foresight? Planning? What new devilry is this?

[sappelhoff]

This will be solved using the following steps:

1. https://github.com/bids-standard/bids-specification/ will from now on be regularly archived by Zenodo "as is" (on each GitHub release, using webhooks)
   • this is similar to how we already archive https://github.com/bids-standard/bids-validator/ on Zenodo
   • it is just intended as an archive of our work
2. The previous way of manually archiving PDF versions of the spec will be discontinued
   • See Zenodo record here: https://zenodo.org/records/3890439
   • The version 1.8.0 over there will be the last archived PDF
   • The "description" of the record will be edited to point to the new location for PDF releases (see below)
3. This new repo will be used to release PDF versions of the specification from now on: https://github.com/bids-standard/bids-specification-pdf-releases
   • once we have released 1.9.0 from the bids-specification repo, we will have 2 artifacts:
     1. The PDF of the spec at release
     2. A CITATION.cff file with the state at release
   • both of these files will be added to the new repository
   • then we will make a 1.9.0 release from the new repository
   • a Zenodo webhook will get the information and archive the 1.9.0 version of the PDF spec
   • BIDS spec PDF versions from 1.0 to 1.8 will be available from the "old" (manually curated) Zenodo record. While BIDS spec PDF versions 1.9+ will be available from the "new" (automatic) Zenodo record
   • the new repository will also contain a README pointing to the "old" releases

I will perform these steps and will update the release protocol.

This is effectively solution 3.iii from the OP.