Page History
...
- (55 mins) General Discussion Topics
- Main topic: 7.4 Release (due Oct 3): Maintenance release only? Or prioritize maintenance first but also allow new features? Which approach do we want to take?
- Development priorities for 7.4, given the v5 & 6 EOL announcement. These priorities have been approved by Steering
- HIGHEST PRIORITY: Stability fixes and major bug fixes. Goal is to immediately fix any major issues we are aware of (or hear about) that might impact production sites.
- We will need to prioritize bug fixes based on severity, likely number of impacted users, whether workarounds exist, etc.
- HIGH PRIORITY: Porting of any missing 5.x/6.x features to 7.x from tier listing
- Several steering members noted that porting additional Admin Tools would be welcome, especially batch import/export tools.
- LOWER PRIORITY: Any other new features (which were not in 5.x/6.x)
- HIGHEST PRIORITY: Stability fixes and major bug fixes. Goal is to immediately fix any major issues we are aware of (or hear about) that might impact production sites.
- Based on feedback, we will likely want to rethink our planning strategies for the 7.4 release. In 7.3, we've noticed the same pattern of too few reviews prior to the Review Deadline and too many PRs getting created at the last minute (just before PR creation deadline). Some brainstorms follow
- During 7.4 planning, we may want to set earlier deadlines for large features. Existing model works best for small features / bug fixes.
- Large features should be broken down into stages / steps. Schedule an earlier PR deadline(s) for those steps. Also schedule review deadlines for those steps
- Goal is to ensure Large features being implementation earlier & get feedback earlier. If they can be broken down into stages/steps, then the final PR & review will be much easier.
- Development priorities for 7.4, given the v5 & 6 EOL announcement. These priorities have been approved by Steering
- Maintenance tasks we feel should be included in 7.4 (Below, please include links to tickets or brief descriptions of issues you feel need to be prioritized highly)
- task 1
- task 2
- Curation Tasks are not very usable from the Admin UI: their results are only sent to dspace.log https://github.com/DSpace/dspace-angular/issues/1322 and they cannot restore deleted objects https://github.com/DSpace/DSpace/issues/7956 and cannot run on items https://github.com/DSpace/DSpace/issues/8384
- Resource Policy edit form is confusing & have usability issues. See for example https://github.com/DSpace/dspace-angular/issues/1704 and https://github.com/DSpace/dspace-angular/issues/644 (which is not policy specific but is reproducible when editing a policy)
- Improve password requirements/management. See for example these tickets https://github.com/orgs/DSpace/projects/18?card_filter_query=label%3A%22authentication%3A+password%22
- Provide a way to manage/cleanup Processes, e.g. https://github.com/DSpace/DSpace/issues/7974 and https://github.com/DSpace/dspace-angular/issues/1343 and https://github.com/DSpace/dspace-angular/issues/1660
- Issues with file download from submission/workflow, see https://github.com/DSpace/dspace-angular/issues/1644 and https://github.com/DSpace/DSpace/issues/8378
- General caching issues, e.g. https://github.com/DSpace/dspace-angular/issues/644 and https://github.com/DSpace/dspace-angular/issues/742 and https://github.com/orgs/DSpace/projects/18?card_filter_query=label%3A%22performance+%2F+caching%22
- Statistics display issues, e.g. https://github.com/orgs/DSpace/projects/18?card_filter_query=label%3A%22component%3A+statistics%22
- (Possibly) Restrict system managed metadata fields from editing: https://github.com/DSpace/DSpace/issues/8299
- Feature PRs which missed 7.3
- Recent Submissions Listing on Homepage (Tier 2, donated, smaller PR): https://github.com/DSpace/dspace-angular/pull/1632
- SAF (Simple Archive Format) Import/Export from UI (Tier 3, highly-prioritized by Steering, medium PR): https://github.com/DSpace/DSpace/pull/8318
- OpenAIRE Graph "quality assurance" (notification broker) feature (Tier 4, donated, large PRs but has had several reviews): https://github.com/DSpace/dspace-angular/pull/1562 and https://github.com/DSpace/DSpace/pull/8184
- OpenAIRE "suggestions" (publication claim) feature (Tier 4, donated, large PRs - no reviews yet): https://github.com/DSpace/dspace-angular/pull/1638 and https://github.com/DSpace/DSpace/pull/8280
- Flexible additional metadata for MyDSpace page (Donated, small PR): https://github.com/DSpace/dspace-angular/pull/1621
- Amazon S3 support improvements (arguably not a new feature): https://github.com/DSpace/DSpace/pull/8356
- Port + Refactor event consumer curation code (Queuing Curation Tasks) (donated): https://github.com/DSpace/DSpace/pull/8151
- Main topic: 7.4 Release (due Oct 3): Maintenance release only? Or prioritize maintenance first but also allow new features? Which approach do we want to take?
- ((5 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.4 Project Board - Assign tickets to developers & assign PRs to reviewers.
- Paid (by DSpace project) developers must keep in mind priority. If new "high" or "medium" priority tickets come in, developers should move effort off of "low" priority tasks.
- Volunteer developers are allowed to work on tickets regardless of priority, but ideally will review code in priority order.
...
- Overview of our 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 this release, 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 feature is badly broken or missing/not working. These tickets must be implemented first, as ideally they should be resolved in the next release. (Keep in mind however that priorities may change as the release date approaches. So, it is possible that a "high priority" ticket may be rescheduled if it is a new feature that cannot fit into release timelines.)
- "medium priority" label = A feature is difficult to use, but mostly works.. These tickets might be resolved prior to the next release (but the release will not be delayed to fix these issues).
- "low priority" label = A 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 the next release. 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 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".
Notes
- Discussed release plan for 7.4. Decided together that it MUST concentrate heavily on maintenance fixes.
- However we want to include donations
- We also want to do our best to include PRs which missed 7.3 (see list in agenda)
- Donations: How do we include?
- Concern about larger donates (e.g. Notify work, OpenAIRE)
- Set a donation notification deadline – that way we can discuss the donation **before** it is added. Very large donations may need to be pushed to 7.5, if we cannot find reviewers
- Who are the reviewers these days? Mostly Atmire, 4Science & Tim. A few others help but our review team is very small
- Need clear messaging on 7.4. Need to make it clear core team is primarily doing maintenance, but we still welcome donations (of code or reviewers). Need to make it clear we also encourage others to review
- Bugs in system
- Too many "high priority" bugs these days. Seems like a default tag. Need to reprioritize
- Discussions of maintenance tasks
- Lots of feature have known minor issues or cleanup needed (e.g. ORCID has parts flagged as "beta", etc). Do we work on this?
- Also many small, but annoying bugs popping up in v7 (reported by users)
- Recommend concentrating more on stability and annoying bugs . While "cleanup" of existing features is nice, we need to concentrate 7.4 on fixing things that have the most impact (e.g. a bug that impacts all users is more important than one that only impacts some – so, it would be more important to fix a bug in authentication than to cleanup ORCID)
- LARGER PRs
- Need individual attention/discussion. Need to assign reviewers & set deadlines specific to those PRs. Cannot be treated the same as all other PRs.
Overview
Content Tools