Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

Date

 from 14:00-15:00 UTC

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

Testathon Sprint : Ongoing

Agenda

Testathon Triage process

  • Overview of our Testathon triage process:
    1. Initial Analysis:  Tim Donohue will do a quick analysis of all issue tickets coming into our Backlog Board (this is where newly reported issues will automatically appear).
    2. Prioritization/Assignment: If the ticket should be considered for 7.0, Tim Donohue will categorize/label it (high/medium/low priority) and immediately assign to a developer to further analysis. Assignment will be based on who worked on that feature in the past.
      1. "high priority" label = A required 7.0 feature is badly broken or not working. These tickets are considered "blocking" and must be resolved prior to 7.0 final.
      2. "medium priority" label = A required 7.0 feature is difficult to use, but mostly works. These tickets should be resolved prior to 7.0 final (but the 7.0 release will not be delayed to fix these issues).
      3. "low priority" label = A required 7.0 feature has usability issues or other smaller inconveniences or a non-required feature is not working as expected.  These tickets are simply "nice to have" in 7.0 final.  We'll attempt to fix them as time allows, but no guarantees are made.
    3. Detailed Analysis: Developers should immediately analyze assigned tickets and respond back within 1-2 days. The developer is expected to respond to Tim Donohue with the following:
      1. Is the bug reproducible?  (If the developer did not understand the bug report they may respond saying they need more information to proceed.)
      2. Does the developer agree with the initial prioritization (high/medium/low), or do they recommend another priority?
      3. Does the bug appear to be on the frontend/UI or backend/REST API?
      4. Does the developer have an idea of how difficult it would be to fix? Either a rough estimate, or feel free to create an immediate PR (if the bug is tiny & you have time to do so).
      5. Are you (or your team) interested in being assigned this work?
    4. Final Analysis: Tim Donohue will look at the feedback from the developer, fix ticket labels & move it to the appropriate work Board.  If it is moved to the 7.0 Project Board, then the ticket may be immediately assigned back to the developer (if they expressed an interest) to begin working on it.
      1. If the ticket needs more info, Tim Donohue will send it back to the reporter and/or attempt to reproduce the bug himself.  Once more info is provided, it may be sent back to the developer for a new "Detailed Analysis".

Attendees

7.0 Release Goals

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

Current Work

Project Board

DSpace 7.0 Final Project Board: https://github.com/orgs/DSpace/projects/5

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"

Security / Performance Tests

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:  See DSpace 7 Security Analysis 
  2. Performance testing of pre-7.0: See DSpace 7 Performance Analysis

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. (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


All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.