Versions Compared

Old Version 3

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 4

changes.mady.by.user Tim Donohue

Saved on

Key

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

...

  • Overview of our Testathon 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 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.
      1. "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.
      2. "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).
      3. "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.
    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 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.
      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".
  • (10 mins) General Discussion Topics
    1. OR2021 DSpace 7 Workshop - Attendee list increased from 40 to 100.  Should we increase all the way to 500 attendees (maximum allowed by Zoom / OR2021)?
    2. Reminder: Help us update the 7.0 Technical Documentation (prior to / during Testathon)
      1. Installation Guide for Angular UI. Currently no Production-level instructions at Installing DSpace
      2. Configuration Reference updates (Tim has been working on little by little)
      3. See also, tickets at https://github.com/orgs/DSpace/projects/5?card_filter_query=label%3Adocumentation
  • (50 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.

...