Giving feedback¶
Data Director is built with the people who manage research data. Judgement is as useful to the project as code: whether advice suits a discipline, whether a decision suits an institution, whether a requirement of the Blueprint is met. Each kind of feedback has a form on GitHub. You need a GitHub account, and what you write is public.
Do not include personal data, unpublished research or anything confidential.
| You want to | Form |
|---|---|
| Say that an agent's advice was wrong, incomplete or unhelpful, and what good advice would have been | Feedback on advice |
| Report a review of whether a requirement is met, such as accessibility or the quality of standards advice | Conformance review |
| Question or object to how a specification says Data Director is built | Spec feedback |
| Point out where Data Director reads the Blueprint differently from you, or misses a requirement | Blueprint reading |
| Report something that does not work, or ask for something new | Bug or Feature, or Report a problem in the app |
All the forms are listed on one page.
Reviews¶
A conformance review records what one person examined and found, at one version. A maintainer adds it to the review record on your instruction, and it appears in the conformance report beside the results of the automated tests. How conformance is assessed explains what a review can and cannot show. A finding that a requirement is not met is as useful as one that it is.
Specifications and the Blueprint¶
The project's specifications say how Data Director is built and why. You do not need to propose an alternative design to object to one: saying who would be affected, and how, is enough.
The Blueprint itself is maintained by its RDA working group. The Blueprint reading form is for how this project interprets it; to change the Blueprint's text, contact the working group.