Audit Trail work (nearly finished/partially approved): https://github.com/DSpace/DSpace/pull/11072 and https://github.com/DSpace/dspace-angular/pull/4576 . When enabled, tracks DSpaceObject metadata changes, bundle creation/deletion, bitstream add/remove/replace (with checksum). Audit trail is stored separate from each object and is searchable globally or at an object level.
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")
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)
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 PRsshould 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 9.x. That said, where possible, we'll try to backport bug fixes (especially significant ones) to 8. x and 7.6.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?
Leadership met on Nov 19 and voted on the merger of DSpace and DSpace-CRIS. A public announcement communicating the result of this vote is expected in the next few days
Provenance and Audit Trail System Overlap
The majority of the meeting focused on whether proposed pull requests should enhance
The provenance metadata field, or
The new audit trail system
Context
Several PRs were submitted to extend provenance tracking. These overlapped with a larger audit trail feature already in development, which led to confusion and the need for alignment.
Background
Audit Trail is for:
System actions occurring within DSpace (machine-recorded)
Tracking what happened, when, and by whom, while an item resides inside the repository
Provenance is for:
Major history or chain-of-custody information that should travel outside of DSpace
Information that may pre-date or post-date DSpace storage
Metadata that should “outlive the system” if the item is exported to another repository
Concerns
Risk of Duplication & Confusion:
Several participants worried that both systems tracking the same information would confuse administrators and future developers
Storage Bloat:
Writing too many detailed system-level events into provenance could produce very large metadata fields that offer little value if the information already exists in the audit trail.
Audit Trail Should Be Automated
Audit trails should not be manually editable – otherwise auditors would distrust them. Provenance can contain manually added entries when needed.
GDPR / Privacy Implications
Tracking additional information may have GDPR implications and must be considered carefully.
Proposed Resolution Path
Working Definition Moving Forward:
Keep major curated, historically important object changes in provenance.
Keep day-to-day system events in the audit trail.
Examples of what may belong where:
Belongs in Provenance
Belongs in Audit Trail
Permanent rights changes
Metadata edits
Major embargo changes
Bitstream changes
High-level change summaries
Next Actions
Tim Donohue will create a ticket outlining the working rules for what belongs in each system.
Community may consult with external curation experts (e.g., DCAT) for professional guidance on what archival standards recommend.
Pull Requests and Implementation Notes
Some functionality (metadata changes, bitstream changes) is already tracked in the audit trail, while others (e.g., item collection transfer, certain policy changes) would need additions.
PR authors may be asked to reframe their contributions to use the audit trail framework instead of provenance, where appropriate.
Where overlapping work already exists, PRs should be cross-linked to avoid isolated development.
GitHub Cleanup – Automatically Marking Stale Issues
Tim Donohue proposed enabling GitHub automation to:
Flag inactive PRs after long periods
Automatically close them after 2 weeks if no action is taken
High-priority items would never be automatically closed
Some PRs and tickets have been open for nearly 10 years, and this system would help with backlog grooming