Page History

...

• (30 mins) General Discussion Topics
  1. Release of 7.3 - Any final changes/feedback/fixes prior to release?
  2. 7.3 Documentation:
     1. Release Notes (Assigned to Tim)
     2. Updates to Installation or Upgrade (Assigned to All, led by Tim)
     3. ORCID documentation (Assigned to 4Science)
        1. ORCID Integration
        2. ORCID Authority
     4. Entity/Relationship Versioning Documentation (Assigned to Atmire)
        1. Configurable Entities
        2. Item Level Versioning
     5. Import Sources documentation (e.g. which ones exist, how to enable/disable, how to configure) (Assigned to 4Science, with support from Tim)
     6. Sherpa/Romeo integration in Submission UI (Assigned to 4Science, with support from Tim)
  3. (Notes for post-7.3) 7.4 Planning discussion
     1. Development priorities for 7.4, given the v5 & 6 EOL announcement. These priorities have been approved by Steering
        1. HIGHEST PRIORITY: Stability fixes and major bug fixes. Goal is to immediately fix any major issues we are aware of (or hear about) that might impact production sites.
           1. We will need to prioritize bug fixes based on severity, likely number of impacted users, whether workarounds exist, etc.
        2. HIGH PRIORITY: Porting of any missing 5.x/6.x features to 7.x from tier listing
           1. Several steering members noted that porting additional Admin Tools would be welcome, especially batch import/export tools.
        3. LOWER PRIORITY: Any other new features (which were not in 5.x/6.x)
     2. Based on feedback, we will likely want to rethink our planning strategies for the 7.4 release.  In 7.3, we've noticed the same pattern of too few reviews prior to the Review Deadline and too many PRs getting created at the last minute (just before PR creation deadline).  Some brainstorms follow
     3. During 7.4 planning, we may want to set earlier deadlines for large features.  Existing model works best for small features / bug fixes.
        1. Large features should be broken down into stages / steps.  Schedule an earlier PR deadline(s) for those steps.  Also schedule review deadlines for those steps
        2. Goal is to ensure Large features being implementation earlier & get feedback earlier.  If they can be broken down into stages/steps, then the final PR & review will be much easier.
• (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.3 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.

...