You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are several things that make this repository (and therefore the standard specification) hard to maintain = issues:
The source of truth is a Google spreadsheet which is then transformed to the README.md document which is the point of reference. PRs to the README must be closed and it must be done in the spreadsheet first to maintain consistency.
Serialization formats (JSON/Schema and RDF/OWL) and their examples are part of this repository making; moreover, they have their own versioning as part of filenames making it not clear what is the relation to the version of the standard.
Versioning schema is not proper semantic versioning.
License is The Unlicense which is in general discouraged esp. for world-wide used projects (see e.g. this discussion).
GitHub Pages are generated using the README but it is not really clear what is the goal as the GitHub repo is the point we refer to (not the page).
What I suggest:
Separate different things (concerns) to different repos of a single GitHub organization: DMP Common Standard for maDMPs (DCS), JSON Schema (+ examples), DCSO (+ examples and its docs), website with adoption stories etc. (for GitHub Pages).
Utilize CI/CD with GitHub Actions for tasks like consistency checks, code style, etc.
Switch to full semantic versioning, incl. git tags as well as GitHub Releases
Keep DCS specification in machine-actionable way (preferrably RDF) and generate human-readable documentation and other artefacts (e.g. JSON Schema) from it directly - again to keep consistency
Change license to CC0 or MIT
Use standard stuff for supporting contributions (CONTRIBUTING, CODEOWNERS, CODE_OF_CONDUCT, CHANGELOG, GitHub Discussions, etc.)
We can do this while working on v1.2.0 and basically do that release in both repos and afterwards archive this one for reference and in new one refer to that (as the older history is here).
Any opinions, suggestions, counter arguments?
The text was updated successfully, but these errors were encountered:
There are several things that make this repository (and therefore the standard specification) hard to maintain = issues:
What I suggest:
We can do this while working on v1.2.0 and basically do that release in both repos and afterwards archive this one for reference and in new one refer to that (as the older history is here).
Any opinions, suggestions, counter arguments?
The text was updated successfully, but these errors were encountered: