We will not be having a meeting on either Thursday, December 24 or 31 because of the Christmas Eve and New Years Eve holidays. Developers who are working during the last few weeks of December will be expected to ask for feedback or code reviewers via Slack or GitHub when needed.
Tim is on holiday (completely offline) from Dec 23-Jan 3, returning on Monday, Jan 4.
(BEFORE MEETING IN #dev-sprint) Developer Stand Up - Developers give brief updates on their effort (or their team's effort).
Update/see "Current Work" section below based on your status.Please feel free to update prior to meeting.
Please highlight any new work (needing reviews/testing), any blockers (for you), and any discussion topics you may have.
(30 mins) General Discussion Topics
(10 mins) Updating the demo site(s) to use the domain/URL: https://demo7.dspace.org/ (This is requested by Steering in preparation for Beta 5)
Andrea Bollini (4Science) noted that one domain may be ideal, but it requires a separate server to act as a proxy. It's ideal though because it can capture request logs/statistics of both the UI and REST API in one place...it'd just take more effort from Tim/LYRASIS. Separate sub-domains is also reasonable (e.g. api7.dspace.org and demo7.dspace.org), but logs/stats are then only at Atmire/4Science servers (as currently). Additional comment by Bollini: It would be easier to start with the two subdomains and switch to a single one only if we really want to do it and a proxy server is ready)
(10 mins) Open Repositories 2021 (virtual) Conference
Finalize / approve the initial list of all authorization features which we should implement for the/api/authz/features REST endpoint. This list of features should be limited to only features which are required to enable/disable User Interface functionality.(In other words, we can always add more features in the future. We just need to approve the list necessary for 7.0)
Delayed. General agreement (in meeting on March 21, 2019) that storing HTML in metadata fields is not really ideal behavior. Metadata (from a librarian standpoint) tends to be free of format-related markup (as that allows for easier sharing, understanding of metadata. Currently Community & Collection homepage information is HTML-based and is stored in metadata that is appropriate for a minor subset of information (like the title) but it is better to move large/rich text to bitstreams.
Proposal here is to consider storing HTML-based markup (for Site, Community & Collection homepages) in Bitstream(s) associated with the object in question. May allow for more CMS-lite behavior in the future
Timeline for this is uncertain. Possibly in 7 or 8. May depend on how/whether it can be scoped.