Be humble in the language and feedback you give, ask don't tell.
Consider using positive language as opposed to neutral when offering feedback. This is to avoid the negative bias that can occur with neutral language appearing negative.
Offer suggestions on how to improve code e.g. simplification or expanding clarity.
Ensure you give reasons for the changes you are proposing.
@KellyStathis I looked over this edit quite a bit, so just a quick scan would be great. The intent was to improve the coverage of the reference rather do a full rewrite just yet.
Purpose
Updates to improve coverage of Usage Reports API reference. Many of the attributes in
report-datasets
in particular were not documented. Included descriptions from the SUSHI spec where possible: https://app.swaggerhub.com/apis/COUNTER/researchdata-sushi_1_0_api/1.0.0#/default/getReportsDSRcloses: https://github.com/datacite/product-backlog/issues/12
Approach
Cross-referenced the SUSHI spec and our existing documentation: https://support.datacite.org/docs/usage-reports-api-guide The SUSHI descriptions may be adjusted in the future to better match our attribute naming.
Open Questions and Pre-Merge TODOs
Learning
Types of changes
[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
Reviewer, please remember our guidelines: