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.

Developers Meeting on Thurs, September 3, 2026

Time/Location

 from 14:00-15:00 UTC

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

11.0 Release Schedule (TBD)

  • New Feature Development Deadlines
    • Feature PR Creation Deadline: Friday, February __ 2027
    • Feature PR Review/Test Deadline: Friday, March __
    • Feature PR Merge Deadline: Friday, March __
  • 11.0 Release Candidate:  Friday, April __
  • 11.0 Testathon: April __-__ (three weeks)
  • 11.0 Translation updates: April __-__ (during Testathon)
  • Bug Fix Deadlines
    • Bug Fix PR Creation Deadline: Friday, May __
    • Bug Fix PR Merge Deadline: Friday, May __
  • Documentation & Release Week: May __-__ 
  • 11.0 Release Announced: May/June, 2027

Agenda

Attendees

Current Work

Project Boards

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 11.0

Finish the merger of DSpace and DSpace-CRIS. Other priorities be decided by DSpace Steering Group with feedback from Leadership Group. 

Priorities listed at DSpace Release 11.0 Status. 

Goals for 10.1 / 9.4 / 8.5 

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

DSpace-CRIS Merger activities

AI Contribution Policy

  • DSpace AI Contribution Policy
  • Timeline: The policy will be going to Committers and Steering next for a vote, as early as next week if feasible
  • Goal remains to get a policy in place as early as we can, since there are already a lot of AI-generated contributions being submitted 
  • The policy is in a final draft state; Tim and Lia updated it based on previous feedback from this group and DSpace Governance.
  • Reviewing comments

    • Comment re. wording of "variable auto-completion" was resolved as covered by "similar low-impact assistance provided by IDEs". However as Kim noted, we should check that this would be consistent in the draft PR template

    • Comment re. phrasing translation as an exception: human-authored still applies, but translation tools may be used on human-authored text in the author's native language

    • PR descriptions

      • Andrea: suggested loosening the "human-authored" requirement for text content, noted finding AI descriptions sometimes more useful. Mentioned Debian policy as another example

      • Tim: This policy was modeled on a set of other examples such as Apache, Mastodon, Linux and more, as well as the range of opinions that have been expressed in the DSpace community (including last week's Developer meeting in support of "human-authored" requirement)

      • In practice will be difficult to identify, so intention is simply to avoid overly careless AI-generated text content

        • Drew: I don't see us as using this policy antagonistically within the active developer community, but primarily to help respond to random, low-effort AI contributions from outside the active community

      • Discussed making sure our existing standards are enforced as well, AI or not. May be a good opportunity to improve on those (Code Contribution guidelines, etc.)
      • Noted there may be governance going forward in the EU that would enforce watermarks on AI-generated content
        • Tim: We can of course adapt the policy as new context changes come up. We also would not immediately close down PRs with AI-generated descriptions, but ask the author to edit and clarify those descriptions
    • Copyright & Legal "If you cannot guarantee the provenance and legal safety of the AI-generated code, do not submit it."
      • Discussed, but cut short by end of meeting - comment on thread in the document with any further opinions

  • Next Steps: If you want to continue any discussions, please add your thoughts to the document ASAP. If you have objections, now is the time to voice them before this goes back to Committers & Steering for votes.



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