-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[INFRA] use tributors to list contributors and CITATION.cff for referencing #1115
Conversation
FWIW, here is the workflow @vsoch (welcome to provide feedback here) prepared for datalad where we get a PR if tributors finds something needing updating (e.g. a new contributor, updated metadata etc): https://github.com/datalad/datalad/blob/master/.github/workflows/update-contributors.yml So I guess similar setup could be done here.
FWIW, I don't think it is very reusable as-is but just an idea: here is the script I used to collate list of invitees for DataLad's JOSS paper https://github.com/datalad/datalad-git-bug-dumps/blob/master/tools/make-summaries . The point was to invite also contributors to issues (not only code contributors), so we used https://github.com/MichaelMure/git-bug (IIRC) to fetch all issues from datalad github repo (hence this large https://github.com/datalad/datalad-git-bug-dumps/blob/master/all-bugs.json ), and then populate list of invitees with aforementioned script. I don't know if there are any contributors which aren't committers in BIDS though, so might not be worth the struggle. But also it seems that git bug dump includes github logins (and names) so you could match a good portion of contributors... alternative -- just use github api to get list of all PRs and their owners, and names for those users. |
In terms of issue openers that never commited I think we might have quite a few
Yup that should get me quite distance already. FLW |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @Remi-Gau -- I think this is a good initiative, also relating to some comments in #901
Do you think we'd be able to integrate contributor email addresses here as well? AFAIK we currently only have those in a sheet shared among maintainers, because we need them for the steering group elections.
Thought about that. There are already some emails in the tributors file already that were caught by the tributor package when it pinged the github API to get a first list of commiters. Before adding more however, I would like to make sure that contributors are OK having their email listed on there. Would make it more convenient for us maintainers but I am not sure that all would be OK with this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
discussion between @Remi-Gau and me just now:
- 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 - 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 - HOWEVER, this is not what happens (see point 1)
- we never commit the PDF to our repo history:
bids-specification/Release_Protocol.md
Line 142 in 8c9fa11
### 6. Get the built PDF - 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
- (but we want the PDF without the other bids-specification repo files)
- we never commit the PDF to our repo history:
Potential solutions
- 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- in a next step, we manually upload the PDF to the other zenodo entry (as before)
- we copy the
CITATION.cff
metadata from the bids-specification record and add it to the manually created zenodo entry - this is potentially laborious, but allows us to keep the present setup with minimal changes
- (we'd have to check exactly how laborious the copying over would be)
- 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)- UPDATE: Remi tried, and this doesn't work: [INFRA] use tributors to list contributors and CITATION.cff for referencing #1115 (comment)
- 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 theCITATION.cff
file back then).- 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.
- 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.
- (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")
Just a note that on the "recent contributors" WIKI, where contributors are supposed to enter their details, it currently says:
If all details except the name is optional, we should maybe include the caveat that contributors that we don't have contact information of are effectively excluding themselves from participating in elections etc. -- and may not even be considered "active contributors" if we vote for a governance amendment that defines "active contributors" as those that:
see also: EDIT: I've seen above now:
I agree that that's a valid and good alternative. It needs to be explicitly mentioned, however. AND I think we should start a private repository (maintainers access only) where we store contributor emails. |
Actually I think we need to make it clear in the wiki that if people do not want to share their contact info publicly then they can do it privately but if we do not have a valid contact info then we can't count them for the votes. |
This is in the wiki: https://github.com/bids-standard/bids-specification/wiki/Recent-Contributors#adding-yourself-as-a-contributor
Let me know if you think we need more. |
I added an email they should write to (bids.maintenance+question@gmail.com, which gets redirected to anyone who has access to the account signs up for this particular "forward rule", currently only me). Other than that, it's good! |
Not seen any info in the zenodo doc that this would work. |
Are we sure that if we do that we will keep the same generic DOI?
Other possibility, github allows cutting release from any branch, so we could have a branch that we just use for realeases that has only the pdf and the citation.cff for the metadata? |
it will be a different "generic" DOI. With this solution, we'd have But yes, perhaps we can discuss solutions with the Zenodo team, however I am afraid that most requests we could have would be rather invasive, like: "can we cancel this project and redirect all DOIs to the new one?"
I would prefer having a dedicated repo for this 🤔 it seems cleaner to me and we wouldn't have to be careful if we ever wanted to archive the actual bids_specification repo content on zenodo. Overall, I am in favor of my option 3 from #1115 (review) and in a next step asking zenodo whether they'd kindly close the currently existing zenodo project (https://zenodo.org/record/7263306) and:
If zenodo won't cooperate on that (which would be totally understandable, as it's a huge request) -- I'd bite the bullet of having each BIDS spec PDF from version 1.0.0 until 1.8.0 accessible under two different DOIs, which is dirty ... but life is messy. In that latter, messy, case we could upload one last release to the old zenodo project which contains just a README that says: "please look at this project instead". |
Ok most of that makes sense to me but let's see what the other maintainers have to say about this at our next meeting |
@sappelhoff |
Yes. After you left the call yesterday, we agreed that it made more sense to get this in and then test any plans in the Zenodo sandbox. I don't think anybody else has the energy to review this, and it's not spec-related, it just needs to work. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make buttons turn green.
#LifeGoals |
.tributors
file for the list of contributors, their info and their contribution typeCITATION.cff
file for the bids spec version and potentially other metada of the repo to be used when releasing on zenodo.all-contributorsrc
file for the required info to update the README contributors tabletools/new_contributors.tsv
as input and.tributors
.tributors
to update.all-contributorsrc
andCITATION.CFF
.all-contributorsrc
Note that this table is now sorted alphabetically
The
.all-contributorsrc
is generated to make use all-contributors to generate a table of contributors in the README.Changes little to the workflow for users to add themselves as contributors (or update their contributions): still done via the wiki, but they should now specify:
New contributors email should in any case be provided to the maintainers privately.
update_contributors
.tributors
.all-contributorsrc
(thetributors
package handles this),README.md
contributor table (theall-contributors
package handle this)CITATION.cff
(can be scripted but may be refactored oncetributors
can handle this)TODO
To discuss