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.
Date
from 14:00-15:00 UTC
Location: https://lyrasis.zoom.us/my/dspace (Meeting ID: 502 527 3040). Passcode: dspace
- More connection options available at DSpace Meeting Room
Beta 5 Sprint : Ongoing
- Planning Sprint for Beta 5
- DSpace 7 Project Boards
- View PRs assigned to you for review/testing: https://github.com/pulls/review-requested
Agenda
(BEFORE MEETING IN #dev-sprint) Developer Stand Up - Developers give brief updates on their effort (or their team's effort).
- Update/see "Current Work" section below based on your status. Please feel free to update prior to meeting.
- Please highlight any new work (needing reviews/testing), any blockers (for you), and any discussion topics you may have.
- (30 mins) General Discussion Topics
- (15mins) Discussion: "Workflow Actions refresh entire MyDSpace page instead of just WorkflowItem" https://github.com/DSpace/dspace-angular/issues/721
- Giuseppe Digilio (4Science) will add notes to the ticket describing where he feels the problem is. Entire team will brainstorm possible solutions
- As discussed last week, if this turns out to be a major effort, we may need to discuss whether to delay for 7.1. If it needs to be delayed, a possible "quick fix" (just for the "Claim Task" button) is to consider implementing a preview page https://github.com/DSpace/dspace-angular/issues/772
- (15mins) Reviewing larger tasks scheduled for Beta 5.
- Are there any that could be delayed for 7.1? Possible candidates from Tim:
- Cannot drag & drop multiple files at once: https://github.com/DSpace/dspace-angular/issues/820 (40 hours)
- Usability issues with both Controlled Vocab & Configurable Entities enabled on same field: https://github.com/DSpace/dspace-angular/issues/847 (48 hours)
- Support separate themes per community/collection (like XMLUI): https://github.com/DSpace/dspace-angular/issues/729 (70 hours)
- Which larger tasks should be prioritized first (cause of dependencies)? How to split these up between the teams
- Angular 10 upgrade: https://github.com/DSpace/dspace-angular/issues/787 (60 hours)
- Angular Cache Redesign: https://github.com/DSpace/dspace-angular/issues/739 (70 hours) and https://github.com/DSpace/dspace-angular/issues/740 (40 hours)
- Cleanup of the existing theme for UI: https://github.com/DSpace/dspace-angular/issues/728 (40 hours)
- Simple second template theme for UI: https://github.com/DSpace/dspace-angular/issues/727 (30 hours)
- Auto-save in item submission breaks the form: https://github.com/DSpace/dspace-angular/issues/835 (40 hours)
- Are there any that could be delayed for 7.1? Possible candidates from Tim:
- (15mins) Discussion: "Workflow Actions refresh entire MyDSpace page instead of just WorkflowItem" https://github.com/DSpace/dspace-angular/issues/721
- (30 mins) Planning for next week
- Review of our Beta 5 Project Board & assigning PRs to reviewers.
- Beginning to assign work
Attendees
7.0 Release Goals
These resources define the prioritization and general schedule we are working towards
- DSpace 7 Release Goals : overview of goals/timelines & beta release process
- DSpace 7 Release Plan spreadsheet: our planning spreadsheet which details which features are scheduled for each Beta release.
Current Work
Project Board
DSpace 7.0 Beta 5 Project Board: https://github.com/orgs/DSpace/projects/4
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"
Security / Performance Tests
Brainstorming options for security testing & performance testing. How do we want to handle both of these prior to 7.0 final?
- Security Review/Scanning of pre-7.0
- Is Testathon an opportunity to have a third-party do a security review and/or scan of the codebase? If so, any ideas of who could do this work?
- Ideally, we build security tests into Integration Test framework to ensure we are checking permissions at all times
- In March 2020, 4Science did an analysis of existing IT security coverage (as part of DS-4411) here: https://docs.google.com/document/d/13DMZ1iYE04D_6_8lrnHrI0uqKkz5RqMU6tWJMrHv88Y/edit
- An update to this analysis could be performed, concentrating on any new gaps.
- Other ideas?
- Performance testing of pre-7.0
- Again, is this an opportunity for Testathon? How/Where do we find someone with a large scale DSpace to test pre-7.0 with? (There's also Chris Wilper's JMeter scripts from 2019 which might be able to provide some basic feedback here)
- Ideally, again it'd be nice if we could perform this sort of analysis in a more automated/regular basis (perhaps via Integration Tests which load a lot of dummy data?).
- Other ideas?
Delayed / Needs Discussion
- Finalize / approve the initial list of all authorization features which we should implement for the /api/authz/features REST endpoint. This list of features should be limited to only features which are required to enable/disable User Interface functionality. (In other words, we can always add more features in the future. We just need to approve the list necessary for 7.0)
- Review current spreadsheet (from Andrea Bollini (4Science) ) : https://docs.google.com/spreadsheets/d/1182LcD_WqIZRbUGWpLtBw0aOMR9jhbOVB7GZqtTpR9A/edit?usp=sharing
- Art Lowel (Atmire) : I don't see any immediate issues with the current set of features, but I would prefer a consistent naming scheme. I'd use canDoSomething for everything
- Tim Donohue added possible renames of these features based on Art's idea (see cell comments in spreadsheet). I like the "can[DoSomething]" naming scheme as well.
- Review current spreadsheet (from Andrea Bollini (4Science) ) : https://docs.google.com/spreadsheets/d/1182LcD_WqIZRbUGWpLtBw0aOMR9jhbOVB7GZqtTpR9A/edit?usp=sharing
- (REST Contract) Edit Homepage News: https://github.com/DSpace/Rest7Contract/pull/45
- Delayed. General agreement (in meeting on March 21, 2019) that storing HTML in metadata fields is not really ideal behavior. Metadata (from a librarian standpoint) tends to be free of format-related markup (as that allows for easier sharing, understanding of metadata. Currently Community & Collection homepage information is HTML-based and is stored in metadata that is appropriate for a minor subset of information (like the title) but it is better to move large/rich text to bitstreams.
- Proposal here is to consider storing HTML-based markup (for Site, Community & Collection homepages) in Bitstream(s) associated with the object in question. May allow for more CMS-lite behavior in the future
- Timeline for this is uncertain. Possibly in 7 or 8. May depend on how/whether it can be scoped.