RFC: adopting forgejo-aneksajo for DataLad versions of dandisets + issue tracking etc.

[yarikoptic]

ATM github is used for a number of purposes in the project

• authentication into archive
• code, documentation, and infrastructure management development
• helpdesk support for our users: https://github.com/dandi/helpdesk
• (managed outside of dandi-infrastructure) replication of dandisets and zarrs as DataLad datasets on https://github.com/dandisets and https://github.com/dandizarrs

we contemplated also

• use of github for issue tracking etc based on individual datasets on https://github.com/dandisets in Design of issue tracking/reporting via GitHub dandi-archive#1595

That development of issue tracking has stalled in part because reliance on external commercial service (github) potentially complicates "roll out" of "platform as a whole" and might be jeopardized by terms and conditions of the service (e.g. by limits on sizes etc). That is why I am actively considering RFing our "datalad"ification to serve DataLad (git/git-annex) versions on dandisets on managed by us instance of https://codeberg.org/forgejo-aneksajo/forgejo-aneksajo . You can find listing of existing, sciencey deployments on

• Support discovery/indexing datasets from forgejo-aneksajo instances datalad/datalad-usage-dashboard#47

Additional benefits for going with that solution instead of github would be ability to customize

• its look / branding
• adding additional handlers for data types of interest to us, e.g. see
  • watching videos right from the portal: https://hub.datalad.org/distribits/recordings/src/branch/master/distribits2024/2024-04-04_01_welcome_day1.webm
  • visualization of metadata extracted for files or adding additional viewers etc, not alike we already do in "Open With": see e.g. https://hub.datalad.org/test-resources/nifti1-testdatasets/src/branch/main/avg152T1_RL_nifti.nii.gz page
• adding CI execution which would be under our control and thus could be much more scalable/involved

In principle, then that's where we could implement workflows for accepting data as well, doing validation and review etc. May be even allowing individual users/labs to have their own forks for the dandisets etc.

Potentially eventually may be even providing a complete alternative to ad-hoc dandiarchive.org web UI, and relying on community developments in that platform.

Authentication sources include OAuth2