Versions Compared

Old Version 1

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version Current

changes.mady.by.user Sascha Szott

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

...

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.

...

Potentially auto-closing "stale" issues 

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

Sascha:

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

ActionOwnerNotes
Create a draft PR to implement GitHub stale automation (YAML config)Tim DonohueInclude sample messages, long inactivity periods (1–2 years), configurable settings
Review and comment on PR proposalAll developers/committersDiscuss in upcoming meetings and Slack
Consider DCAT involvementPierre LasouPierre to raise topic with DCAT and report back; Tim available to join if invited
Investigate merge conflict handling options in stale configTim DonohueSee if PRs with conflicts can be specially flagged/exempted
Add “stale” management as periodic agenda topicTim DonohueUse to discuss flagged/closed issues regularly


...

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