Time/Location
from 15:00-16:00 UTC
Location: https://lyrasis.zoom.us/my/dspace?pwd=RTk4QUhISnhPRi9YenVrTFJKbDllQT09 (Meeting ID: 502 527 3040). Passcode: dspace
|
Agenda
Preparation PR (preparing for possible Nx or Angular Workspaces migration): https://github.com/DSpace/dspace-angular/pull/4629To 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")
To be decided by DSpace Steering Group with feedback from Leadership Group.
Priorities listed at DSpace Release 10.0 Status.
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)
dspace-7_x are becoming more difficult to port forward.)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!
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.
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.
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.
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.
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.
Supports idea but distinguishes between:
Old backlog (historic issues) → might need separate cleanup strategy.
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.
Confirmed that GitHub’s stale action uses last activity, not open date.
Tickets or PRs with ongoing discussion remain active.
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.
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.
Suggests possibly setting a 3-year inactivity threshold to start conservatively.
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.
| Action | Owner | Notes |
|---|---|---|
| Create a draft PR to implement GitHub stale automation (YAML config) | Tim Donohue | Include sample messages, long inactivity periods (1–2 years), configurable settings |
| Review and comment on PR proposal | All developers/committers | Discuss in upcoming meetings and Slack |
| Consider DCAT involvement | Pierre Lasou | Pierre to raise topic with DCAT and report back; Tim available to join if invited |
| Investigate merge conflict handling options in stale config | Tim Donohue | See if PRs with conflicts can be specially flagged/exempted |
| Add “stale” management as periodic agenda topic | Tim Donohue | Use to discuss flagged/closed issues regularly |
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.
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.