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).
- More connection options available at DSpace Meeting Room
Beta 3 Sprint : June 15-26
- Working on finalizing beta3 (Goal to release at end of June or very early July)
- Review DSpace 7 Release Plan spreadsheet for beta3 and beta4 tasks
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
- (15 mins) Revisit our draft Beta 3 Project Board
- Updates from Heather Greer Klein and Tim Donohue on questions from last week
- Any way to sync JIRA tickets and GitHub Issues? (would be necessary if we wanted to continue to use both tools for time being)
- No way to do this easily (without paying for an expensive plugin/tool)
- Any way to embed GitHub issue information into Confluence Wiki (in same manner as JIRA tickets)? For example, this feature in JIRA helps auto-create our Changes in 6.x in documentation.
- Not a perfect solution. But, you can embed issues or PRs via this Confluence Plugin: https://marketplace.atlassian.com/apps/1216734/github-macros-for-confluence (seems to meet use cases for basic lists of GitHub issues)
- Also able to auto-generate Release Notes (in markdown format) using https://github.com/github-tools/github-release-notes (Would allow us to post changelogs/release notes in GitHub directly instead of on the Wiki)
- Any way to sync JIRA tickets and GitHub Issues? (would be necessary if we wanted to continue to use both tools for time being)
- Board structure/workflow
- To do (unassigned) → In Progress (assigned) → Needs Reviewers Assigned → Under Review → Reviewer Approved → Done
- We've chosen to include all active PRs/tickets on this Project Board. However, the "milestone" notes which beta the PR/ticket is aimed at. So, some tickets have milestone "7.0beta4" on this board, which just means they are done early & lower priority to review right now.
- Questions for the team:
- How is this Board working for you so far? Likes/dislikes?
- Should we bring this to the DSpace Committers to vote on moving all DSpace 7 tickets from JIRA to GitHub Issues?
- Updates from Heather Greer Klein and Tim Donohue on questions from last week
- (15 mins) Status check on 7.0 beta 3 release by end of June or early July
- Release possible by week of June 29?
- Or do we need to look at week of July 6? (NOTE: Tim is on vacation July 6-10)
- (15 mins) Revisit our draft Beta 3 Project Board
- (30 mins) Planning for next week
- Review of our Beta 3 Project Board
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
Claim a Ticket!
If you do not have access in JIRA or GitHub to officially claim the ticket you wish to work on, contact Tim Donohue
- Available Angular UI Tickets
- Open issues in 7.0beta3 milestone (highest priority)
- Open issues flagged as "Difficulty: low". These may be a good starting point for newer developers.
- Available REST API Tickets
- Unassigned tickets scheduled for 7.0beta3 (highest priority)
- General REST API tickets flagged as "low hanging fruit". These may be a good starting point for newer developers.
- General REST API unassigned bug tickets. Again, might be a good starting point for newer developers.
Project Board
DSpace 7.0 Beta 3 Project Board: https://github.com/orgs/DSpace/projects/1
To quickly find PRs assigned to you for review, click these links
- REST API PRs assigned to you for review: https://github.com/DSpace/dspace/pulls/review-requested/@me
- Angular UI PRs assigned to your for review: https://github.com/DSpace/dspace-angular/pulls/review-requested/@me
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
- Proposal from Art Lowel (Atmire)on enhancing object cache in Angular UI.
- Initial Performance Testing from Chris. Needs revisiting / retesting prior to 7.0.
- https://cwilper.github.io/dspace-perftest/
- These performance tests were run prior to the work on "projections" (to limit the data returned by the REST API). Therefore, it is likely performance is much improved, but needs verification testing.
- (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.