2020-10-08 DSpace 7 Working Group Meeting

Date

08 Oct 2020 from 14:00-15:00 UTC

Location: https://lyrasis.zoom.us/my/dspace (Meeting ID: 502 527 3040).  Passcode: dspace

• More connection options available at DSpace Meeting Room

Agenda

• (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
  
  1. (20mins) Discussion of Auto-Save behavior in Submission UI: https://github.com/DSpace/dspace-angular/issues/835
     1. Previously mentioned possible improvements to auto-save:
        
        1. Should auto-save not be time-based, but be entirely based on removing focus on fields? 
        2. If the page takes a while to reload, is there a way to capture/retain content until save has completed?
        3. How can we avoid errors appearing from sections that the user hasn't even gotten to yet?  Should we not display error popups until Save button is pressed?
  2. (10mins) Brainstorming options for security testing & performance testing.  How do we want to handle both of these prior to 7.0 final?
     1.  Security Review/Scanning of pre-7.0
        1. Is Testathon an opportunity to have a third-party do a security review and/or scan of the codebase?  If so, any ideas of who could do this work?
        2. Other ideas?
     2. Performance testing of pre-7.0
        1. Again, is this an opportunity for Testathon? How/Where do we find someone with a large scale DSpace to test pre-7.0 with?  (There's also Chris Wilper's JMeter scripts from 2019 which might be able to provide some basic feedback here)
        2. Other ideas?
• (30 mins) Planning for Beta 5
  
  • Review of our Beta 5 Project Board & assigning issues for estimation which have Estimate TBD label
  • Beginning to assign work

Attendees

• Art Lowel (Atmire) 

• Andrea Bollini (4Science)

• Tim Donohue

• Lieven Droogmans

• Giuseppe Digilio (4Science)
• Ben Bosman
• Paulo Graça

7.0 Release Goals

These resources define the prioritization and general schedule we are working towards

• DSpace 7 Release Goals : overview of goals/timelines & beta release process
• DSpace 7 Release Plan spreadsheet:  our planning spreadsheet which details which features are scheduled for each Beta release.

Current Work

Project Board

DSpace 7.0 Beta 4 Project Board: https://github.com/orgs/DSpace/projects/3

To quickly find PRs assigned to you for review, visit https://github.com/pulls/review-requested  (This is also available in the GitHub header under "Pull Requests → Review Requests"

Delayed / Needs Discussion

1. 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)
   • 1. Review current spreadsheet (from Andrea Bollini (4Science) ) : https://docs.google.com/spreadsheets/d/1182LcD_WqIZRbUGWpLtBw0aOMR9jhbOVB7GZqtTpR9A/edit?usp=sharing 
        1. Art Lowel (Atmire) : I don't see any immediate issues with the current set of features, but I would prefer a consistent naming scheme. I'd use canDoSomething for everything
        2. Tim Donohue added possible renames of these features based on Art's idea (see cell comments in spreadsheet).  I like the "can[DoSomething]" naming scheme as well.
2. Initial Performance Testing from Chris.  Needs revisiting / retesting prior to 7.0. 
   1. https://cwilper.github.io/dspace-perftest/
   2. These performance tests were run prior to the work on "projections" (to limit the data returned by the REST API).  Therefore, it is likely performance is much improved, but needs verification testing.
3. (REST Contract) Edit Homepage News: https://github.com/DSpace/Rest7Contract/pull/45
   
   1. 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.  
   2. 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
   3. Timeline for this is uncertain.  Possibly in 7 or 8. May depend on how/whether it can be scoped.

Notes