-
Notifications
You must be signed in to change notification settings - Fork 26
Technical Minutes 2020 05 08
Andrew Cooke edited this page Jun 4, 2020
·
2 revisions
- In attendance: Andrew C, Anton H, Arjan L, Beate MF, Bert VL, Craig V, Erwin S, Kor O, Marvin R, Michael J, Mike L, Peter B, Thomas P.
- Introductions
- Feedback from Webinar
- ADE 1.0 publication
- Workplan for ADE 1.1
- Webinar participation for 9 June 2020
- Release notes and change log
- There was good feedback from the main ADE working group meeting
- Attendees found it easy to follow and a good introduction
- ICAR can promulgate the release - they have announced this through the links to the webinar and GitHub.
- Andrew will put out an announcement on LinkedIn and Twitter that people can share.
- Andrew and Cesare (ICAR) created new branches - ADE-1 the default release branch, and DEVELOP for contributors.
- The group discussed the workplan for v1.1 - ie, next non-breaking changes. Agreed there should be a focus on new messages.
- Body Condition Score #83
- Health and Treatments #96 (e.g. to support antimicrobial resistance analysis)
- Live animal conformation scores/inspections #97
- Standardise PUT/POST methods
- Aggregated data
- Group assignments (management or other groups) #88. This is different from contemporaryGroup for statistical purposes. Potentially may require a group resource or membership resources, or join/leave messages.
- Agreed that more suggestions could be added through Issues.
- Discussed the use of enumerated types vs. strings. Where validation is not known or essential, items have been left as strings/numbers, but enumerations are used where values would be useful.
- Noted that medicines could be constructed with a (country or international) scheme and ID (e.g. registration within country). Some thinking would be necessary when animals are transferred between countries. The same applies to diagnosis coding.
- Discussed feedback on the 1.0 API
- Want to avoid breaking changes so early in the cycle. Breaking changes would require a new MAJOR version.
- Most fields are optional, and developers should implement fault-tolerant reading. This way they can consume data with MINOR version additions and implementation-specific additions.
- Success or implementation stories (e.g. Lely)
- Suggestions for version 1.1 and the future roadmap
- Possibly a technical "how-to" session for developers or technical people. Would need to advertise separately. Invitations could be made directly.
- Bert will discuss this further with Robert and other organisers.
- Suggested that we should have good release notes to track changes, for instance between 1.0 and 1.1.
- All Pull Requests should link to the issues that they close/address (and vice versa). This makes it easy to automatically generate a change log.
- Add to instructions for people contributing, and the checklist for those reviewing change requests.
Next meeting scheduled for 22 May 2020 at 9am CET