Page tree
Skip to end of metadata
Go to start of metadata


 from 15:00-16:00 UTC

Location: (Meeting ID: 502 527 3040).  Passcode: dspace

Beta 5 Sprint : Ongoing

Upcoming schedule changes per Daylight Saving Time

Daylight saving time starts in USA on March 14, but in Europe on March 28th.

  • On March 18 and March 25 we will continue to meet at 15:00 UTC, which is the same time in Europe but one hour later in USA (15UTC will be 11am EDT).
  • Starting April 1, we will switch our meeting to 14:00 UTC for the remainder of daylight saving time .


  • (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. Beta 5 Release Schedule & Testathon Dates (APPROVED by Steering)
      1. Week of March 22 - Concentration on Code Reviews
      2. Week of March 29 - Concentration on updating PRs / responding to feedback
      3. Week of April 5 - Concentration on Re-reviews / final updates where needed
      4. Beta 5 PRs merged by Thursday, April 8
      5. Beta 5 Release Date: Friday, April 9 or Monday, April 12
      6. Testathon (3 weeks): April 19 - May 7  (See DSpace Release 7.0 Testathon Page)
        1. We are aware of the overlap here with Ramadan (April 12 - May 12), but our understanding is most celebrating Ramadan still work during that time. This date was set based on the earliest possible date that we can schedule a Testathon, based on the developer team's work schedule.
    2. Clarifying Theme Decisions for 7.0, 7.1 and 7.2
      1. We will not be creating any brand new theme for the 7.0 release, as we do not have time to do so prior to Testathon. However, Steering is interested in creating a "fancy" new DSpace 7 theme in either 7.1 or 7.2, but has not finalized the roadmap for those upcoming releases.
      2. In 7.0, there will be three theme folders:
        1. A "base" (or core) theme (which is defined by the core components under /src/app/) which defines the core look & feel of DSpace (in terms of HTML layout, header/footer, etc). It only has basic Bootstrap styling (mostly default Bootstrap with minor tweaks for accessibility). This "base" theme is being finalized in by 4Science.
        2. A "custom" theme folder (/src/themes/custom) which acts as a template theme for institutions. It provides (empty) templates for changing the theme of individual components. When enabled, it looks identical to the "base" theme, as all template files are empty.  This template theme folder was created in and by Atmire.
        3. A "dspace" theme folder (/src/themes/dspace) which acts as the default theme for 7.0 only (it's a temporary theme to be replaced in 7.1 or 7.2). Because we are NOT creating a new theme, this folder will ONLY provide basic CSS/image overrides to the "base" theme and will not change HTML in any manner.  Essentially, it is just a new color scheme & homepage image on top of the "base" theme.  This theme will be based loosely on the old "mantis" theme from 7.0 Preview, but the end result will look like a combination of the new "base" theme and the old "mantis" theme. This work is in early draft form in
      3. When a brand new DSpace 7 theme is created (in either 7.1 or 7.2), it will replace the contents of the "dspace" theme folder.  It may also update aspects of the "base" theme, depending on the scope of the work approved by Steering.  No decision has been made on who will create this final DSpace 7 theme, but it has been discussed to hire a designer / firm to do this work.
    3. Main discussion will be related to the above schedule
      1. Any PRs that need group discussion?
        1. Need second set of eyes on "Usability of Edit People / Groups UI":
        2. CSRF Cookie issue when making requests from Angular Universal (SSR) :
      2. Status update on content reset for prior to Testathon? (Assigned to Tim Donohue to update the sample data used by Docker & pass that to 4Science to update demo site)
  • (30 mins) Planning for next week


7.0 Release Goals

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

Current Work

Project Board

DSpace 7.0 Beta 5 Project Board:

To quickly find PRs assigned to you for review, visit  (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) ) : 
        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:
    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.