Technical issues around GitHub-based content (placeholder discussion)

[joncison]

Use this for general *technical discussion around mooted GitHub-based content management architecture (see #355 and #242)

[joncison]

Misc. concerns & solutions discussed mostly with @bgruening, @hmenager and @hansioan thus far:

• preserve the existing entry ownership / edit rights function
  • existing entry ownership / edit-rights would have to be annotated (on entry level) as GitHub handles
  • meaning some mechanism to map bio.tools accounts to GitHub accounts would be needed
• should not overload bio.tools curators with pull requests
  • use GitHub handle (of GitHub user, or annotated in bio.tools entry) as means to automatically accept pull requests
• ensure data integrity / validity
  • validation as part of CI such that commits must pass validation checks to be accepted / before pull request is issued / accepted
• full-strength validation
  • validation in bio.tools goes beyond what biotoolsSchema provides (although in 1st instance pointing users to XSD/XML validation log could be a starting point)
  • full-strength solution is standalone validator, see biotoolsLint
  • provide the validator as a Github app / bot, which must pull everything it needs (not stateful!) as it will be spun up in it's own VM on demand. Don't worry about cacheing as this is handled by bot-hosting service
• preserve the existing GUI-editing function
  • a standalone curators interface is needed, e.g. based on edamToolAnnotator
• auto-management of file format variants
  • use shims to automatically generate / interconvert alternative formats (XML, JSON, YAML) - assuming this can be done in a lossless way - again, as part of CI

[joncison]

This issue was moved to research-software-ecosystem/content#1