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.

Developers Meeting on Thurs, August 6, 2026

Time/Location

 from 14:00-15:00 UTC

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


11.0 Release Schedule (TBD)

  • New Feature Development Deadlines
    • Feature PR Creation Deadline: Friday, February __ 2027
    • Feature PR Review/Test Deadline: Friday, March __
    • Feature PR Merge Deadline: Friday, March __
  • 11.0 Release Candidate:  Friday, April __
  • 11.0 Testathon: April __-__ (three weeks)
  • 11.0 Translation updates: April __-__ (during Testathon)
  • Bug Fix Deadlines
    • Bug Fix PR Creation Deadline: Friday, May __
    • Bug Fix PR Merge Deadline: Friday, May __
  • Documentation & Release Week: May __-__ 
  • 11.0 Release Announced: May/June, 2027

Agenda

Attendees

Current Work

Project Boards

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")

Goals for 11.0

Finish the merger of DSpace and DSpace-CRIS. Other priorities be decided by DSpace Steering Group with feedback from Leadership Group. 

Priorities listed at DSpace Release 11.0 Status. 

Goals for 10.1 / 9.4 / 8.5 

Deadline is TBD for 10.1, 9.4, 8.5.  Bug fix releases do not have fixed/scheduled deadlines. Instead, the developer team will determine when to create a release based on the significance of the issues to solve. (e.g. If major issues are fixed, then a bug fix release will occur more rapidly.  If minor issues are found, then a bug fix release may be delayed until sufficient fixes have been made to warrant a release)

  • Bug/security fixes only.  These minor releases will not include any new features.
    • New "themeable components" (for dspace-angular) are allowed in bug fix releases, provided that they don't significantly modify component behavior or similar.
    • Accessibility fixes are also allowed in bug fix releases, provided they don't significantly modify component behavior or similar.
  • Bug fix PRs should be created against "main" branch where possible. The "main" branch has the most strict code style rules. (i.e. PRs created against dspace-8_x  are becoming more difficult to port forward.)
  • Per our support policy, bug fixes are only guaranteed to be ported back to 10.x.  That said, where possible, we'll try to backport bug fixes (especially significant ones) to 9.x and 8. x.

Try "Pull Request Trading" for a quicker review

Do you have a PR stuck in "under review" that you really want to see move forward?  Or maybe it's someone else's PR but you want to get it more attention?

See Trading reviews on Pull Requests for how to get immediate attention to that PR!

Notes

Housekeeping

  • No dev meeting next week Thursday (Aug 13)
  • Tim will be out of office the entire next week until August 17 (Monday)
  • Next developers meeting will be on August 20, where we will come back to discussing the AI contribution policy
    • AI Contribution Policy discussion has been intentionally omitted in this meeting as it's been forwarded to Steering for initial review
  • Tim will draft an early agenda for the August 20th meeting; feel free to add to this agenda once it's available (end of today)

DSpace-DSpace-CRIS Merger

  • The Merger Management Team met last week and is continuing its discussion around the unifciation of the relationship entitity model
  • We now have a number of brainstorms that we are distilling down to best options and models
  • Next meeting will be August 20th

Merger-related PRs

  • Metadata extraction of PDFs using Grobid: https://github.com/DSpace/DSpace/pull/11852 
    • Initial feedback has been provided; Kim is working on addressing the feedback
    • Kim has added a question about the situation where extracted metadata ignores submission form restrictions (bug), including
      • repeatable metadata fields
      • authority-controlled fields
      • form validation rules
    • Kim explained that these behaviors are actually not introduced by the GROBID implementation itself. Instead, GROBID supplies metadata, the existing "extract metadata" workflow step inserts metadata directly into the item, and the workflow currently has no awareness of submission form configuration
    • Mark noted that validation logic should ideally become independent of the submission UI and instead occur during the ingestion process after metadata has been collected
    • The group decided that these validation issues are outside the scope of the current GROBID PR
    • The current PR should not be delayed by broader architectural improvements
    • A new GitHub issue will be created describing the broader validation problem; early implementation ideas should be documented there
  • Porting of missing CRIS external authorities (ROR, OpenAIRE, ZDB): https://github.com/DSpace/DSpace/pull/12473
    • Has had reviews; Adomo is adding comments
    • Is getting to the point where it's ready for a re-review (by Katharina)
  • Configurable Layout of Entity/Item Pages
  • Configuration options for homepage: Frontend: https://github.com/DSpace/dspace-angular/pull/5983
    • Still in draft

Other Topics

  • Lint rule to avoid method calls with async pipe (e.g. "getFoo$() | async"): https://github.com/DSpace/dspace-angular/pull/5934
    • Discussed a new frontend lint rule intended to discourage calling methods directly through Angular's async pipe
    • Aims to prevent unnecessary repeated execution that can negatively affect frontend performance
    • Art noted that using async pipes is acceptable when the observable behavior is backed by a BehaviorSubject and problems primarily arise when ordinary observables are used
      • An unconditional lint rule may reject perfectly valid code
    • Alternatives including the use of Angular Signals were discussed
    • The group generally supported improving performance safeguards, continuing discussion within the PR, and avoiding large-scale refactoring during the current merger work
  • Introducing Java Records (JEP 395)
    • Proposal from Sascha to modernize and refactor Java code
    • Generally a good idea, but difficult to prioritize this task at the moment due to focus on other priorities
    • Mark suggested that we should gradually move into this direction by adapting new and more modern coding styles and slowly fade out old code
    • Idea to create a ticket to start to add more Java records and link places where they are already in use
    • Mark raised the question whether this is something we should mention in the style guide?

Needs Discussion Topics

  • https://github.com/DSpace/DSpace/issues/12858 - DINI requirements
    • Question raised whether this is too German specific or relevant for a broader audience
    • Pascal highlighted aspects that could be beneficial for the global DSpace community and explained that the DINI Certificate has existed for roughly twenty years; it reflects repository best practices accumulated over many years
    • Global application includes
      • repository policies
      • metadata practices
      • version information
      • OAI-PMH improvements
    • Martin and Tina will work on submitting individual pull requests for features beneficial to the wider DSpace community


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