Page History

...

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