Versions Compared

Old Version 2

changes.mady.by.user Andrea Bollini (4Science)

Saved on

compared with

New Version Current

changes.mady.by.user Grazia Quercia

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: point 1.c

...

  • (30 mins) General Discussion Topics
    1. Discuss design of Bulk access control management (previously called "Advanced Policy Manager" in 6.x) - The ability to modify policies on several items/bitstreams at once. (UI ticket #781,REST ticket #2848)
      1. Ideally, we should scope this to be as simple as possible to achieve the same "use cases" in DSpace 7. The feature can be redesigned but also should be simplified.
      2. Known Use Cases include: (Neither of these are currently possible in 7.5)
        1. Access restricting (or giving access to) all Items in a Collection, 
        2. Access restricting/embargoing (or giving access to) all Bitstreams of all Items in a Collection.
        3. Replace all polices or append to existing policies in either use case
        4. (4Science addition: modify all policies within a single Item to restrict or access restrict all in a single Item. Similar to Submission or Workflow you could use access settings.)
      3. Bulk access control management - 4Science proposal - it was approved. The UI will be simplified in the case of community, collection and item administrator by including only step 3 (and 2 for item). The multi-object case retains steps 1 and 3. 4Science is going to integrate the proposal with this detail.
    2. Planning for 7.6
      1. 7.6 board has been cleaned up & is ready. However, need help from Atmire/4Science on the "In progress" column.
      2. General rule for 7.6:  New features are welcome if they used to exist in 6.x.  Everything else must be a fix that would normally be acceptable in a "bug fix only" release.
        1. 7.6 is a "transition" release, where we are transitioning back to our release numbering scheme
      3. Timeline for 7.6:  Looking at a June release (unless we find that upcoming/planned 7.6 development can be done sooner than anticipated)
        1. TODO: Tim will update release schedule above.
      4. Releases after 7.6:  Later releases will be bug-fix only.
        1. Andrea Bollini (4Science) and Lieven Droogmans suggest to switch to a 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. With 8.0 however, we would move back to our existing release numbering scheme.  Bug fix releases would be numbered 8.1, 8.2, 8.3, etc.
    3. (Future Topic) Lyrasis' new CEO has asked Tim Donohue to investigate what it would take to implement OCFL-based storage (or similar preservation-friendly storage) for DSpace (v8 or later)
      1. Early brainstorm is to likely keep DSpace's existing database & Solr usage as-is.
      2. However, migrate from current "[dspace]/assetstore" to an OCFL storage structure. 
        1. OCFL storage would contain both the content file(s) (PDF, etc) and a metadata representation (exported/synced from database). The metadata representation might be similar to our existing DSpace AIP Format.
        2. Tools would need to verify/validate that data in OCFL storage "matches" with what is in the database (similar to a Checksum Checker, but more specific to OCFL storage)
      3. ANYONE interested in brainstorming this idea further, perhaps even in a separate meeting?
    4. (NO UPDATES) Demo Site maintenance (https://demo7.dspace.org/ and https://api7.dspace.org/server/)?  
      1. LYRASIS is still working on this, but some restructuring of plans has had to occur because of internal deadline changes.  Likely not to be completed until late March or April.
      2. In the meantime, can we ensure that it is still possible to send updates to both the frontend & backend per instructions at Updating DSpace 7 Demo Sites 
    5. (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.6 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

...