Versions Compared

Old Version 2

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 3

changes.mady.by.user Tim Donohue

Saved on

Key

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

...

  • (60 mins) General Discussion Topics
    1. DSpace 7.6 release retrospective
      1. Anything we feel we'd like to do differently as we move towards 8.0?
      2. Any processes/procedures we'd like to keep in place for 8.0?
    2. Disbanding the "DSpace 7 Working Group".  Moving back to general "DSpace Developer" Meetings
      1. Proposing simply renaming this meeting & keeping the meeting time the same.
      2. Wiki obviously will need to be updated to note this change and make it easy to find where the developers meet
    3. Planning for 8.0 (Summary from Steering meeting yesterday)
      1. Goals for 8.0
        1. Move forward major features which missed 7.x. 
          1. COAR Notify support (4Science & Harvard)
          2. OpenAIRE integration with notification broker/claim service (4Science)
          3. Porting "REST-Based Quality Control Reports" from old REST API to new one. (U of Laval, Canada)
          4. Duplicate Detection in Submission ported from DSpace-CRIS (The Library Code)
        2. Include new features which empower users in the admin UI.  Make things easier for Admins.
        3. Improve documentation, training to allow for greater community contributions.  (Ease setup/install/customization, etc.)
          1. Angular upgrade/maintenance. Spring upgrade/maintenance. Solr upgrade/maintenance, etc.
          2. Possibly need cleanup of Submission Refactor to support Angular upgrade. https://github.com/DSpace/dspace-angular/issues/858
            1. Library used to create the Submission form may need updating?
      2. Timeline for 8.0 release: April 2024.
      3. In parallel, proof of concepts / planning regarding modularization (e.g. 4Science angular proposal) and OCFL/preservation storage (Lyrasis proposal to be discussed in more detail).
    4. Planning for 7.6.x releases - bug-fix only.   
      1. Tim will bring to Steering the suggestion to switch post-7.6 release numbering to 7.6.1, 7.6.2, 7.6.3 (for eventual bug fix release). This clarifies that 7.6 is the final feature release, and that every later release is a minor upgrade.
      2. Two development branches: dspace-7.x and main 
      3. Two project boards in GitHub: DSpace 7.6.x Maintenance and DSpace 8.0 Release
      4. Revisiting code review process brainstorms: See Incentivizing Code Reviews and PR Testing
    5. (No Updates) Demo Site migration to Lyrasis (https://demo7.dspace.org/ and https://api7.dspace.org/server/)  
      1. Tim will work with Lyrasis to make this happen as soon as reasonably possible now that 7.6 is released.
      2. Demo site will be renamed back to "demo.dspace.org" (instead of "demo7.dspace.org"). 
    6. Future meeting discussions for 8.0
      1. 4Science proposed to present
        1. COAR Notify on July 13th 2023
        2. ORCID Login improvement on July 20th 2023
        3. Angular : library-based architecture proposal updated proposal on July 20th
    7. (Other topics?)

...

  • 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

  • Feedback on 7.x process
    • Way too much in 7.x (too long to get out - 4 years is a long time)
    • Kept adding more features. Too much "scope creep".  Not strict on release dates
    • Took time to improve what is there which resulted in larger refactors (couldn't avoid all "scope creep" that occurred & there were positives out of it.)
    • Early releases we may have taken too much time to discuss  solutions.  Got better about that later on.
    • We learned the hard way: move features, not release dates. We should keep this.
    • DSpace 7 is a massive improvements over 6.x. 
    • Massive overhaul (UI and REST API) is not something we'll need to do frequently. Was necessary in 7.x.
    • Code Reviews: Lose a lot of time keeping PRs up-to-date without being able to anticipate when reviews will occur.
    • Originally noted that 7.x needed more than just a flashy UI.  But, maybe that was all we needed all along
    • Community involvement:  Did we do too much work to bring them along early on?  It wasn't easily attainable to bring community members along until we "finalized" the 7.x platform.
      • Hadn't documented the design principles well enough (and the design principles sometimes changed)
    • Funded Development: absolutely necessary to ensure this level of effort could occur for 7.x.  Allowed service providers to balance work on open source DSpace much better.
    • Staffing: More support for Tim/Tech Lead.