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 15:00-16: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
- Ongoing development on Beta 5
- 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
- (Discussion Topics TBD)
- (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
- Tasks for Security Review
- Third party to run a security analysis/scan (e.g. see OWASP list of vulnerability scanning tools or list of free security tools) against REST API
- Third party to run a security analysis/scan against Angular UI
- Create a Wiki page on DSpace 7 Security Analysis of what work we've already done. (Reviewed by someone in Leadership)
- 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.
- Better document expected permissions for all endpoints in the REST API.
- Other ideas?
- Tasks for Security Review
- Performance testing of pre-7.0
- Tasks for Performance Testing
- Third party to install/upgrade to DSpace 7 in a dev environment with...
- Large site overall (in terms of number of Items). What to test: overall performance of browsing/searching site.
- Large Community/Collection hierarchy. What to test: browsing Communities/Collections. Test creating a new Community, Collection or Item.
- One Collection with thousands of Items. What to test: browsing/searching within that Collection.
- One item with 100s of Bitstreams. What to test: test viewing/editing that individual Item. Test searching for that Item.
- One item with lots of Authors. What to test: test viewing/editing that individual Item. Test searching for that Item.
- Third party to install/upgrade to DSpace 7 in a dev environment 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?
- Tasks for Performance Testing
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.