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
7.0 Final : Next Steps / How to get there
Final analysis of Testathon feedback
Final review of Test Plan spreadsheet. Ensure all feedback/bug reports are captured in GitHub Issue tickets (most already should be), so that we can prioritize, etc
- UNTESTED TASKS:
(DSquare Technologies ran an initial scan, see summary on wiki page) DSpace 7 Security Analysis (In our dev process, we have been running automated security checks, but an external analysis would be nice)
(Needs volunteer) DSpace 7 Performance Analysis (In our dev process, we've done past performance analysis, but more "real life" checks would be nice)
(COMPLETED) Final analysis of Accessibility Results (from Deque) - assigned to Tim Donohue
- Analyze all "Critical" (72) and "Serious" (293) accessibility issues (link requires login). Turn into GitHub Issue tickets & prioritize & assign for estimation
- Estimating/Announcing 7.0 Release Date
- Requires estimating all high/medium priority TBD tickets: https://github.com/orgs/DSpace/projects/5?card_filter_query=label%3A%22estimate+tbd%22
- Requires completing both analyses above
- Ongoing bug fixing / code reviews of remaining 7.0 tickets (with concentration on high/medium priority)
- Fix all "high priority" bugs and ideally all "medium priority" bugs on our 7.0 board
- Review/test all PRs assigned to you for review/testing: https://github.com/pulls/review-requested
- Finishing 7.0 Technical Documentation
- More eyes on Installing DSpace (especially the Angular UI instructions)
- See also, Documentation tickets at https://github.com/orgs/DSpace/projects/5?card_filter_query=label%3Adocumentation
Agenda
- (30 mins) General Discussion Topics
- Any final OR2021 prep/questions from anyone?
- Setting a release date for 7.0
- Assuming only "high priority" tasks (~80hrs of estimated dev work). "Medium priority" tasks become "nice to have", but many/most will be delayed to 7.1
- Tentative Dates for 7.0 Final release:
- Monday, Aug 2: Public Release Date
- Internal Release Goal: Monday, July 26 (i.e. we will release early if possible to do so)
- July 15 every PR merged
- June 24 - July 15 reviews (Art out week of July 12, Ben out week of July 5, Tim out week of July 5, Andrea out June 23-July 2)
- June 24 every PR created (high priority mainly) - Guaranteed in 7.0, anything after may not be in 7.0
- Monday, Aug 2: Public Release Date
- Ranking of outstanding 7.x features (by DSpace Governance): DSpace Release 7.0 Status#7.x
- (30 mins) Planning for next week
- Review the Backlog Board - Are there any tickets here stuck in the "Triage" column? We'd like to keep this column as small as possible.
- Review the 7.0 Project Board - Assign tickets to developers & assign PRs to reviewers.
- Priority should be kept in mind here. If new "high" or "medium" priority tickets come in, developers should move effort off of "low" priority tasks. Reviewers/testers should also concentrate effort on "high" or "medium" priority PRs.
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 Project Boards : our planning/scheduled boards which details which features are scheduled for each Beta release.
Current Work
Project Board
DSpace 7.0 Final Project Board: https://github.com/orgs/DSpace/projects/5
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")
Issue Triage process
- Overview of our 7.0 Triage process:
- Initial Analysis: Tim Donohue will do a quick analysis of all issue tickets coming into our Backlog Board (this is where newly reported issues will automatically appear).
- Prioritization/Assignment: If the ticket should be considered for 7.0, Tim Donohue will categorize/label it (high/medium/low priority) and immediately assign to a developer to further analysis. Assignment will be based on who worked on that feature in the past.
- "high priority" label = A required 7.0 feature is badly broken or not working. These tickets are considered "blocking" and must be resolved prior to 7.0 final.
- "medium priority" label = A required 7.0 feature is difficult to use, but mostly works. These tickets should be resolved prior to 7.0 final (but the 7.0 release will not be delayed to fix these issues).
- "low priority" label = A required 7.0 feature has usability issues or other smaller inconveniences or a non-required feature is not working as expected. These tickets are simply "nice to have" in 7.0 final. We'll attempt to fix them as time allows, but no guarantees are made.
- Detailed Analysis: Developers should immediately analyze assigned tickets and respond back within 1-2 days. The developer is expected to respond to Tim Donohue with the following:
- Is the bug reproducible? (If the developer did not understand the bug report they may respond saying they need more information to proceed.)
- Does the developer agree with the initial prioritization (high/medium/low), or do they recommend another priority?
- Does the bug appear to be on the frontend/UI or backend/REST API?
- Does the developer have an idea of how difficult it would be to fix? Either a rough estimate, or feel free to create an immediate PR (if the bug is tiny & you have time to do so).
- Are you (or your team) interested in being assigned this work?
- Final Analysis: Tim Donohue will look at the feedback from the developer, fix ticket labels & move it to the appropriate work Board. If it is moved to the 7.0 Project Board, then the ticket may be immediately assigned back to the developer (if they expressed an interest) to begin working on it.
- If the ticket needs more info, Tim Donohue will send it back to the reporter and/or attempt to reproduce the bug himself. Once more info is provided, it may be sent back to the developer for a new "Detailed Analysis".
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: See DSpace 7 Security Analysis
- Performance testing of pre-7.0: See DSpace 7 Performance Analysis