Versions Compared

Old Version 2

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version Current

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info
title7.6 Release Plan

Release Schedule:

  • (tick) Friday, April 7 (Donated Feature Notification Deadline): Any community members who wish to donate a feature to this release must notify Tim Donohue by this date (either via email, Slack or GitHub). The DSpace 7 team will then provide feedback on whether it will be possible to include this feature in the release (based on team member availability and the size of the feature).  Early notifications are more likely to get included in the release.
  • (tick) Friday, May 12 (Feature PR Creation Deadline):PRs should be created by this date if they are to be reviewed in time for the release.  Please note there is no guarantee that a PR will be included if it is created by this date. Larger PRs are recommended to be created earlier, as that makes it more likely they can be reviewed in time for inclusion. (Smaller bug fixes are welcome anytime)
  • (tick) Friday, May 26 (Feature PR Review/Test Deadline): All code reviewers or testers should submit their feedback by this date. Code reviews must be constructive in nature, with resolution suggestions. Any code reviews submitted AFTER this date will be considered non-blocking reviews. NOTE: Larger PRs or donated PRs may have their own deadlines established for PR creation, review and merger.This deadline only applies for PRs with no other deadline established.
  • (tick) Friday, June 2 (Bug PR Creation Deadline): Bug fix PRs are still acceptable after this date if they are very high priority.  However, any submitted after this date will likely need to have pre-assigned reviewers in order to ensure the review can be completed before the PR Merge Deadline.
  • Friday June 9 (PR Merge Deadline): All PRs should be merged by this date.  (Note: bug fixes can still get in after this deadline, as long as they are small or important)
  • Week of June 12-June 16 (Documentation & Release Week):  Any merged PRs which don't have minimal documentation (how to enable / configure) MUST have documentation created this week. Later in this week (around Thurs) will be the release.
  • Tuesday, June 20:  (RESCHEDULED for June 27 during today's meeting) Public Release Announcement. 7.6 will be announced/released by this date.

Ongoing/Weekly tasks:

...

  • Overview of our Triage process:
    1. 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).
    2. 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.
      1. "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.)
      2. "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).
      3. "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.
    3. 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:
      1. Is the bug reproducible?  (If the developer did not understand the bug report they may respond saying they need more information to proceed.)
      2. Does the developer agree with the initial prioritization (high/medium/low), or do they recommend another priority?
      3. Does the bug appear to be on the frontend/UI or backend/REST API?
      4. 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).
      5. Are you (or your team) interested in being assigned this work?
    4. 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.
      1. 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 deploying to demo site issues (Updating DSpace 7 Demo Sites)
    • Deployment of backend is working... just isn't reported on slack anymore
    • Deployment of frontend is no longer working.  But, Art can manually deploy when needed.
  • Reviewed board
    • Most tickets are moving along... but just running behind. Lots still open
  • Discussed 7.6 release deadline
    • Tim recommends pushing release back one week to June 27.  This is necessary simply because the review process has taken longer than anticipated & we've had fewer reviewers.  Also preparation for OR2023 (next week) has caused some conflicts / additional stress.  Giving us all one more week makes it much more likely we'll get most everything in that's on the board.
    • Atmire agrees.  4Science notes either date works for them... they are still aiming to get all their development completed this week, but understand the need.