Developers Meeting on Thurs, November 13, 2025

Time/Location

13 Nov 2025 from 15:00-16:00 UTC

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

• More connection options available at DSpace Meeting Room

Agenda

• Discussion Topics - If you have a topic you'd like to have added to the agenda, please just add it. 
  1. DSpace & DSpace-CRIS potential merger discussions
     
     1. DSpace and DSpace-CRIS Planning Groups - wiki pages to follow along with ongoing discussions.
  2. Potentially auto-closing "stale" issues and PRs via https://github.com/actions/stale (Tim)
     1. Our boards and list of open tickets/PRs has grown over time. We have PRs from 2015 and tickets from 2012.  Do we need to keep these all open?
     2. Should we consider some automation to allow us to better concentrate on active tickets/PRs?
        1. E.g. of others using "stale": https://code.ornl.gov/mantidproject/mantid/-/blob/Matplotlib-3.8-Update/.github/workflows/stale.yml
     3. Perhaps consider issue tickets stale after 2-3 years?  Consider PRs stale if they have a "merge conflict" flag and unchanged for >6months (or >1 year).
  3. Other topics
     1. Pulling some spring XML from src/main/resources into config folder (e.g. spring-dspace-addon-validation-services.xml)
• Board Review:
  • 10.0 Project Board - Review PRs collaboratively or Assign new PRs to volunteers to code review and/or test.
  • Backlog Board - Are there any tickets here stuck in the "Triage" column?  We'd like to keep this column as small as possible.
  • Maintenance Board (9.x, 8.x, 7.6.x) - Known bugs can be found here, along with any backported bug fixes.
• Upcoming Topics: (Let us know if there are topics you want to discuss in future weeks)
  • Revisiting Nx / modularization discussion: Prototyping Nx vs Angular CLI Workspaces
    • Preparation PR (preparing for possible Nx or Angular Workspaces migration): https://github.com/DSpace/dspace-angular/pull/4629
    • Prototype Angular Workspaces PR: https://github.com/DSpace/dspace-angular/pull/4783
    • Original Nx PR (example full migration to Nx): https://github.com/DSpace/dspace-angular/pull/4019
  • Follow-up on "aggressive bot" discussion:  https://github.com/DSpace/dspace-angular/issues/4565
    • PR to update our built-in "rate limiter": https://github.com/DSpace/dspace-angular/pull/4620

Attendees

• Tim Donohue 
• Holger Lenz 

• Art Lowel (Atmire) 

• Andrea Bollini (4Science)

• Giuseppe Digilio (4Science) 
• Paulo Graça
• Mark H. Wood 
• Grazia Quercia (4Science)
• Stefano Maffei (4Science)
• Julian Timal (eScire) 
• Martin Walk 
• Melissa Anez  
• Pascal-Nicolas Becker 
• Pierre Lasou 
• Kim Shepherd 
• Nicholas Woodward 
• Sascha Szott 
• Marsa Haoua 
• Jesiel Viana 
• Arturo Garduño Magaña 
• Scholaris Team

Current Work

Project Boards

• DSpace 10.0 board: https://github.com/orgs/DSpace/projects/32
• DSpace 9.x, 8.x and 7.6.x maintenance board: https://github.com/orgs/DSpace/projects/29

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 10.0

To be decided by DSpace Steering Group with feedback from Leadership Group. 

Priorities listed at DSpace Release 10.0 Status. 

Goals for 9.2 / 8.3 / 7.6.5

Deadline is TBD for 9.2, 8.3 and7.6.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-7_x  are becoming more difficult to port forward.)
• Per our support policy, bug fixes are only guaranteed to be ported back to 9.x.  That said, where possible, we'll try to backport bug fixes (especially significant ones) to 8. x and 7.6.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

Update on Potential Merger of DSpace and DSpace-CRIS

• Status: No new updates since last week.

• Progress:

  • Final reports from both planning groups (strategic and technology) have been sent to the Steering group, will be forwarded to Leadership today.

  • Steering is reviewing and has provided positive feedback.

• Next Steps:

  • Await a decision from Steering and Leadership—either approval or rejection of the merger.

  • There is a possibility that planning groups may be asked to revise their work.

• ETA: Decision expected “relatively soon,” though no control over the exact timing.

• Action: Tim will inform everyone once there’s a formal decision.

• Over 1,000 open tickets across backend and frontend.

• Many are likely outdated, solved, or extremely low priority.

• Some tickets date back 13 years; PRs as far back as 2015.

Proposal:

• Implement GitHub’s “stale” action to automatically close inactive issues and pull requests.

• The action:

  • Marks items as “stale” after a certain period of inactivity.

  • Sends an automated warning message (e.g., “This issue has had no activity for X days and will be closed in 7 days unless updated.”)

  • Allows customization (different rules for PRs vs issues, exempt labels like “high priority,” etc.).

  • Closed issues/PRs can be easily reopened if needed.

Suggested Configuration:

• Issues marked stale after 1–2 years of inactivity.

• PRs marked stale after 6–12 months.

• 7-day grace period before auto-closing.

• Exemptions for “high priority,” “in review/test,” or other designated labels.

Discussion:

Mark Wood:

• Concerned that auto-closing works “the problem backwards.”

• Suggests finding why issues aren’t getting attention instead of closing them.

• Notes that volunteer projects naturally accumulate long backlogs.

Tim Donohue (response):

• The goal is to prompt attention through automated reminders.

• Automation spreads the workload: individual contributors can confirm whether an issue is still relevant.

• Reduces manual triage of 1,000+ tickets.

• Stale warnings can help surface neglected tickets.

Pierre Lasou:

• Supports idea but distinguishes between:

  1. Old backlog (historic issues) → might need separate cleanup strategy.

  2. New workflow going forward → can use automation.

• Likes adding a “stale” label for visibility.

• Suggests ensuring activity-based tracking (last edit/comment), not just creation date.

• Also suggests bringing this to DCAT for discussion on feature tickets and assistance with sorting through these

Tim (clarification):

• Confirmed that GitHub’s stale action uses last activity, not open date.

• Tickets or PRs with ongoing discussion remain active.

Marcia:

• Notes that issues at “review or test” stages might need special handling.

• Tim: such issues likely won’t go stale due to linked PR activity; can be exempted or relabeled manually if needed.

Nicholas Woodward:

• Strongly supports automation (“plus one”).

• Notes the difficulty of manually finding relevant PRs among outdated ones.

• Suggests starting with loose thresholds (long inactivity periods) and tightening later.

Martin:

• Suggests possibly setting a 3-year inactivity threshold to start conservatively.

Sasha:

• Supports automation and raises question about handling DSpace-CRIS issues if merger proceeds.

• Tim agrees this would depend on merger outcome; relevant issues could later be consolidated.

Outcomes & Action Items (Ticket/PR Automation)

Other Topics

Configuration File Relocation (Kim’s Topic)

• Kim (absent) proposed moving certain Spring XML files from /src/main/resources to /config.

• Tim and Mark discussed:

  • May depend on whether these are developer-level or site-level configs.

  • Some files may be intentionally embedded for safety (“dangerous to modify”).

  • Decision deferred until Kim provides context.

Recent Angular Modularization PR

• Large prep PR for modularization was merged.

• Causing merge conflicts in ongoing PRs (especially on the Angular side).

• Action: Developers should rebase/update; notify team on Slack if encountering issues.

Including ORCID Id(s) in Datacite DOIs

• Briefly discussed and looked at backend PR (topic brought up by Eike)
• Noted a small change to the virtual metadata mapping
• Assigned Tim and Kim as reviewers, with Kim testing this PR