Contribution Guide

DPV Contribution Guide

Note: It is not recommended to submit PRs without checking this guide first. PRs are not necessary to get attribution or to be listed as a contributor. We add contributors also by using git acknowledgements i.e. using Authored-by or Co-authored-by. Therefore, it is strongly recommended to discuss the proposal before submitting a PR to avoid potential issues in the submission and to make the best use of available time.

Contribution / Participation

The DPVCG is the primary forum for contributions and participations regarding the DPV. As such, all decisions and resolutions will be conducted through the group's meetings and call. Membership in DPVCG is not necessary to contribute to DPV, but is recommended for participating in the group's decision making process. Contributions and questions can be sent to the group's public mailing list or expressed as GitHub issues.

Suggesting new terms

To suggest a new term, we request following information:

Please ensure the terms follow the Style Guide

• term
• description of the term
• whether it should be a class or a property
• relation to existing term(s) in DPV e.g. through sub-classes
• source (where applicable)
• justification or relevance of why this term should be added (where not obvious)

Suggestions are welcome via the group's meetings, mailing list, and GitHub issues.

Raising issues

Before submitting an issue, please see the whether the issue has been addressed on GitHub. If not, please raise the issue via the group's public mailing list or expressed as GitHub issues.

Fixes, corrections to the terms are considered as issues and can be submitted similarly. For minor changes, we may prefer to incorporate them directly rather than through pull requests and patches. For larger issues, please check with the group before submitting a pull-request to ensure its appropriate and efficient incorporation.

Development Guide

DPVCG strongly suggests discussing proposals (e.g. via mailing list or github issues) before submitting code or PRs. This is to ensure proposals are well-defined, and no time is spent on outputs that are difficult to integrate or are potentially outdated. Attribution is provided via git co-authoring for proposals irrespective of their origin or whether code/PRs were submitted or not. Therefore, 'contributors' are not recognised solely through PRs, and are also be added through discussions and proposals.

(1) DO NOT change the outputs (HTML, RDF) directly - they are autogenerated from a different set of inputs

(2) DO NOT make changes over the master branch - use the dev branch to make changes or raise PRs

For info on how to generate the outputs, see Documentation-Generation

PR Checklist

• The PR SHALL NOT make changes to the master branch unless this was agreed upon beforehand. Why: By default, PRs should aim to make changes to the dev branch as that is where development happens. The master branch is intended for completed work (primarily), and making changes to published work is not recommended. There is also a risk that changes to master branch will be out of sync with other changes made in dev branch.
• The PR SHALL NOT include changes to RDF and HTML files. Why: DPV's documentation generation happens via a workflow consisting of managing spreadsheets used for discussions, which are then used to generate the RDF, and then the HTML using Jinja2 templates. A PR adding/fixing something only in the RDF/HTML 'output' will not be in snyc with the 'input'. Instead, please open a new issue with the suggested changes.
• The PR SHALL NOT make changes to CSVs in vocab_csv or other source folders. Why: The CSVs are an export of spreadsheets maintained online for convenience and discussions. Why the repo downloads them and uses them as the canonical source of data, if changes are made to CSVs without reflecting them back to the online spreadsheets, there will be a discrepancy in both, and a chance that the change is overwritten the next time the spreadsheets are downloaded. Recommendation is to make changes in the spreadsheet if you have access, or to discuss the PR before making changes (e.g. in an issue).
• The PR SHALL NOT make changes to a large number of files. Why: This makes code review difficult. Since most of these files are the outputs, only the changes to the source files should be made in the PR. The outputs can then be generated alongside any other pending change. This will also help keep the history clean and to make it easy to revert changes in needed.

Getting help and assistance

If you're unsure about something, or would like clarifications, or suggestions - please communicate with us or open an issue. We would be happy to help.