Skip to content
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

Clean up and restructure repository #95

Open
MarekSuchanek opened this issue Feb 26, 2025 · 0 comments
Open

Clean up and restructure repository #95

MarekSuchanek opened this issue Feb 26, 2025 · 0 comments
Assignees
Labels
discussion Under discussion, opinions needed to decide enhancement New feature or request
Milestone

Comments

@MarekSuchanek
Copy link
Collaborator

There are several things that make this repository (and therefore the standard specification) hard to maintain = issues:

  1. 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.
  2. 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.
  3. Versioning schema is not proper semantic versioning.
  4. License is The Unlicense which is in general discouraged esp. for world-wide used projects (see e.g. this discussion).
  5. 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?

@MarekSuchanek MarekSuchanek added the enhancement New feature or request label Feb 26, 2025
@MarekSuchanek MarekSuchanek added this to the v1.2.0 milestone Feb 26, 2025
@MarekSuchanek MarekSuchanek self-assigned this Feb 26, 2025
@MarekSuchanek MarekSuchanek added the discussion Under discussion, opinions needed to decide label Feb 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Under discussion, opinions needed to decide enhancement New feature or request
Projects
Development

No branches or pull requests

1 participant