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, Oct 17, 2024

Time/Location

 from 14:00-15:00 UTC

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


No meeting on Thurs, October 10

There will be no meeting on Thursday, October 10 because Tim Donohue and Holger Lenz will be attending a Lyrasis All Staff retreat that week.  Our next Developers' meeting will be on Thursday, Oct 17.

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 9.0

To be decided by DSpace Steering Group with feedback from Leadership Group. 

Early brainstorms at DSpace Release 9.0 Status.  Please feel free to add your own brainstorms or link in tickets that you wish to be considered. 

Goals for 8.1 / 7.6.3

Deadline is TBD for both 8.1 and 7.6.3.  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-7_x  are becoming more difficult to port forward.)
  • Per our support policy, bug fixes are only guaranteed to be ported back to 8.x.  That said, where possible, we'll try to backport bug fixes (especially significant ones) to 7.6.x.
    • Keep in mind, if a specific bug fix is important to you in 7.6.x, then it is best to create two PRs (one for main and one for "dspace-7_x").  If you are able to provide a backport version of the PR, then we will merge it alongside the "main" branch version.
    • NOTE: In many scenarios, a backport to "dspace-8_x" should be possible to automate using the "port to [branch]" labels & the "Port merged Pull Request" GitHub Action

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

  • Quick update on 9.0 from Tim
    • Draft release schedule is not yet completed. Tim will try to get it ready for next week's meeting (Oct 24).
  • DOI Fields in DSpace (Pierre)
    • Pierre shared slides he created which summarize the current DOI situation, and a few brainstorms for ways we can correct this in the future.
    • Discussion occurred
    • Overall consensus was achieved around Scenario 2 (see slide 7), with some minor updates. Those updates were already made to slide 7 by Pierre during the meeting.
    • Tim will create a bug ticket to describe the consensus, so that we can work towards improving DOI storage in 9.0.  DONE: https://github.com/DSpace/DSpace/issues/9901
  • What types of code contributions are eligible for merging back to main? Example: optional french language browse filter labels [Mohana & Rachel Wang (Scholaris) ]
    1. Feedback: Please contribute any missing language tags & feel free to also correct language tags which you feel are improper translations.  However, if the language tags are not usable in out-of-the-box DSpace (e.g. they reference a customization on your end), then they should not be contributed back.
    2. When in doubt, feel free to just create a PR and ask for a review.  One of the Committers can quickly review it and provide advice on whether any translated tags should be removed.
  • Map Handles to their UUIDs instead of legacy handle links: https://github.com/DSpace/DSpace/pull/9864 The second redirect is excessive, and some bots (Altmetric) don't execute  JavaScript so cannot find the UUID
    1. Feedback: General agreement that this is a useful bug fix.  Andrea offered to help Mark.  See https://github.com/DSpace/DSpace/pull/9864#issuecomment-2419912763
  • Are there plans to merge this proposed fix into D8/D9? Will it remain Admin only? https://github.com/DSpace/DSpace/issues/3325 [Mohana & Rachel Wang (Scholaris) ] 
    1. Why do we ask? In reference to integration work with Symplectic's Elements Software.
    2. Feedback: There is no current plan to change the behavior of the /api/core/items  endpoint to include withdrawn or hidden items.  Even if we went that route in the future, withdrawn or hidden item details would ONLY be accessible to authenticated Administrators.  All DSpace REST endpoints use security to ensure that private/restricted information is only accessible if you have permissions to access it.
    3. Rachel notes that their team would love feedback from anyone else using Sympletic Elements for integration.  Get in touch with the Scholaris team if you want to swap tips or share advice.

Action items









  

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