Accessibility site (for Deque) should be updated to Beta 5 code once released
Our Dev meetings during Testathon will involve two boards:
7.0 Project Board - These are tickets we are planning to complete prior to 7.0 Final. Tickets here can be worked on during Testathon.
In each meeting, we will review this board & continue to estimate tickets, assign to work on, review/test, etc. Any tickets merged will be deployed immediately to the Testathon demo servers.
Once Testathon is completed, based on estimated work on 7.0 Board & in consultation with Steerring, we'll set a goal/date for 7.0 final. This may involve re-prioritizing tickets on the 7.0 board as necessary.
Backlog Board - New bugs/issues reported during Testathon will appear on this board (in "Triage" column).
Tim Donohue can take lead on Triage (but others welcome). As necessary, he will pull in developer(s) who worked on that feature to do a quick estimate, prioritization & (as necessary) assign the work.
Once triaged, ticket will move to 7.0, 7.1 or 7.2 project board based on priority. Tickets may also move between 7.0/7.1/7.2 boards if priority changes (based on additional feedback, etc.)
During our weekly meetings, we'll glance at the "Triage" column for newly reported bugs & help move them along if needed.
Updating 7.0 Documentation (prior to / during Testathon)
Installation Guide for Angular UI. Currently no Production-level instructions at Installing DSpace
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.