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.

Meeting Information

Date and Time: January 15, 2026, 17:00-18:00UTC

Meeting link: See calendar invitation

Attendees

(green star)  Note taker

Regrets

 Agenda


TimeItemDescriptionResources
15 minsWelcome and Introduction

Welcome to the Group

Group Composition (voting and non-voting members)

Your Role and Expectations

Discussion of Goals, Responsibilities, Timelines, Deliverables

Review of Charge

Charge (Merger Management Team)
20 minsTracking Merger Activities 

How to best track current merger activities.

"DSpace-CRIS merger" label in GitHub:

(Work-in-Progress / Draft) Merger GitHub Project Board

Project Planning spreadsheet from Technology Planning Group.
20 minsIncentivizing Code Reviews

Revisiting idea around pool of code reviewers. Can we incentivize reviewers/testers to create a pool of willing reviewers for new PRs.

How to best assign PRs quickly for review.


5 minsWrap-up

Meeting Frequency

Communication between meetings (Slack, email)



Notes

  • Welcome & Introduction
  • Tracking Merger Activities in GitHub
    • Tim shared the work he's done to move all the merger planning information out of the Project Planning spreadsheet and into GitHub as issue tickets and into this Merger Project Board
    • Overall, there was positive feedback on moving this all to GitHub.  Tim will complete process of moving this information to GitHub over the next week.
    • Clarification Discussion: Can anyone claim a merger-related tasks (especially the smaller feature ports) and create a PR for it?
      • Yes, anyone can help by porting features via a PR. 
      • To claim a task, you must request to be assigned to the ticket.  That will ensure we avoid duplicative work, and also will allow the Merger Management Team understand who wants to claim this work.
      • In order to assign the ticket, the Merger Management Team may need to understand your familiarity with DSpace-CRIS and the task, and get an estimate of completion from you. This just ensures that the work can be done based on the merger roadmap. 
  • Updates from 4Science on upcoming / existing merger-related PRs
  • Discussion of GitHub best practices for merger tasks / PRs
    • Recognition that we need to find ways to speed up the PR creation process and review process.
      • There will be three very large PRs (though two are scheduled tentatively for 10.0: #11748 and #11749) 
      • Can we ask PR creators to "break down" PRs into logical commits that are easier to review?  Answer: This will be very time consuming as we are porting existing features in most cases. The "boundaries" of these features are not always clear and separating them in commits would take more time than we have available (especially for 10.0 work).
      • Can we ask PR creators to create more detailed PR descriptions which provides details about each individual change/feature, so that reviewers can still review it in pieces?   Answer: We agree this may be the best approach to start with.  We can adapt if needed if it's not working.  
      • We can also hold overview or Q&A meetings for each of the larger PRs?
        • Tim notes we could consider scheduling 30 mins immediately after Developer Meetings to discuss one larger PR in more detail. Anyone interested can attend.
        • Lieven notes that'd work better if we make it a "Q&A" style session. We don't want to wait to review large PRs until the next developer meeting. But, it could be a good opportunity to hold a Q&A session then to allow developers or reviewers to ask questions about the PR to understand it better.
        • Tim agrees that makes sense.
        • Tim notes he'd be OK with scheduling these types of PR-specific Q&A meetings, but would want to understand if they are of interest. If no one wants to attend, then they are not purposeful. 
    • PR Description Best Practices 
      • Ensure very large PRs have a detailed "Instructions for Reviewers" section in the PR description.  These instructions ideally should include:
        • A list of all "major changes" (features or architectural changes) made in the PR
        • Break down which code file(s) / Java classes are being added/changed for each of these "major changes"  (This will allow reviewers to review the code in "pieces" by looking at groups of related files)
        • Link to relevant DSpace-CRIS documentation which provides more context.  (This will also allow us to pull this documentation into the DSpace docs)
    • What to do if we notice any changes in PRs which are not  in DSpace-CRIS?
      • Call them out in the PR.  The intention is that these merger-related PRs should be direct ports  of features in DSpace-CRIS.  If there seems to be something unrelated or new, call it out in a comment.  We'd want to verify the purpose of that new code, as new code should only be added if necessary to get the feature to "work right" in DSpace.
  • How will the Merger Management Team keeping track of new PRs and/or merger-related discussions
    • Tim: Let's create a Slack channel to share this information.  Tim will try to note when new merger-related PRs are created or if any important discussions arise in Developer Meetings.
  • Incentivizing Code Reviews
    • We didn't have time for this topic. Will wait for next meeting.
  • Wrap-Up
    • At least for now, we will meet every two weeks. Next meeting on Thurs, Jan 29.   
    • If we find there's less to discuss, or we can tackle most things asynchronously, then we may cut back meeting frequency eventually

Action Items

  • Tim will continue moving all merger-related tasks from the Project Planning Spreadsheet to the new GitHub Project Board
  • Tim will create a private Slack channel for the Merger Management Team
  • No labels

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