Versions Compared

Old Version 6

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.

...

  • 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

  • Updates from Notify project with regards to DSpace 7
    • Tim talked with Harvard team & 4Science this week.
    • Good working prototype from Harvard (with support from 4Science).  However, it's not really ready for contribution to core DSpace yet.
    • This work will continue while 7.4 is going on (and Tim will help support it), but it won't be contributed back to DSpace core until 7.5 (at the earliest).
  • Updates from Steering
    • Budget approval for 7.4 paid work (4Science & Atmire)
    • Very early discussions of a possible online "DSpace Summit" in early 2023 (perhaps Feb).  Nothing finalized, but several Steering members are passionate about planning a global DSpace user group meeting & making it free to attend online.  A subgroup of Steering will start to talk more about this in the near future, and Tim will keep this team up-to-date on anything that is decided.
  • Initial discussion of possible microservice architecture for IIIF search API queries and OCR indexing.
    • Team decided that we needed a more formal proposal, with a possible workflow diagram or rough design.  There were no objections to consider a microservices approach for the IIIF Search API... however, Tim noted that maintenance and installation need to be considered. Ideally any such microservice would be in a common language (Java ideally) so that others could help maintain it.  We'd also want to ensure it is relatively easy to install/update (clearer instructions / documentation).
  • Deduplication Detection submission step – ported from DSpace-CRIS by the Library Code.  Consider for 7.4?
    • All glad to see this moving forward. 4Science very appreciative & interested in helping review these PRs.
    • Biggest question for 7.4 is whether it is possible to do a full review "cycle" (initial review, address feedback, follow-up review(s), address more feedback as needed) given our lack of resources/reviewers for 7.4.  It may not be possible unless we find another reviewer.  However, if it misses 7.4, we definitely should ensure it gets into 7.5.