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.

...

  • (30 mins) General Discussion Topics
    1. Any feedback out of the DSpace 7 Workshop series in November?
    2. Any new updates / brainstorms about improving initial response speed of DSpace 7 UI ?  See DSpace 7 UI Optimization Analysis and https://github.com/DSpace/dspace-angular/issues/1921
      1. NOTE: In a new ticket (https://github.com/DSpace/dspace-angular/issues/1954) related to this issue, it was mentioned that DSpace 7.2 has much better homepage performance than DSpace 7.4.  We may want to look closer at what major changes occurred between these releases that could have impacted performance.
    3. Possible duplicate Self-Registration tickets?  https://github.com/DSpace/DSpace/issues/2793  vs https://github.com/DSpace/DSpace/issues/3272
    4. Migrating https://demo7.dspace.org/ and https://api7.dspace.org/  to LYRASIS likely in early 2023 (Jan or Feb)
      1. Will run off our Docker Scripts in codebase (some updates to these scripts will be necessary).
      2. Will be possible to send an auto-reset command at any time (Committers will be given this access).
      3. Will be possible to reset demo content on demand (eventually may be auto-scheduled)
      4. Possibly two demo sites (one for latest version, e.g. 7.4, and one for latest code, e.g. sandbox.dspace.org)
    5. Open Repositories 2023 (June 12-15 in Stellenbosch, South Africa).  Proposals due Jan 15.
      1. Who is planning to attend?  Any early plans for DSpace proposals?
    6. (Other topics?)
  • (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.5 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

...

Current Work

Project Board

...

  • 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

  • Workshops were a huge success.  Hoping to have more of these in the future as they were the largest (attendance wise) in the history of DSpace (over 400 live attendees per workshop).  May want to try to have similar workshops around once per year?
  • UI Optimization. A new ticket on the board: https://github.com/DSpace/dspace-angular/pull/1975
  • Duplicate Self-registration tickets:  All these tickets were assigned to Ben as he's already got folks working on the issue. 
  • Migrating demo sites to LYRASIS. All had positive feedback. Tim will let everyone know when this is formally scheduled...not likely till Jan or Feb though.
  • OR2023 participation.  Atmire & 4Science will likely have staff there.  LYRASIS will likely have at least one person.  But, Dev team feels the decision on the ideal "DSpace presence" at OR2023 should come from DSpace Steering.  Atmire will send whatever staff is necessary based on what Steering would like to see.
    • All generally agreed though that a Workshop at OR2023 may not be possible, unless it's less technical.  Technical workshops at OR don't have a broad of an appeal as the online workshops we've been running & they are harder to organize.
    • All generally agreed DSpace should have some  presence at OR2023, but the type should be decided by Steering.