Page History

...

•  Idea: Virtual collections based on a search query. What is a collection other than a tag? What does it mean for something to be in a collection?
• There are wiki pages for each of the priority use cases
• API seems to be conspicuously missing. Is the idea that the new user interface will interact with a Web API that supports the entire suite of - - DSpace interactions
• Part of the agenda is to figure out what is missing in the current REST API. We will need to fill in those gaps.
• This is the time to make the API the canonical way to interact with DSpace
• Single UI will be a massive job; API will be another massive job; if I were to focus on one massive job, it would be the API
• Top down or bottom up?
• Developers agree that the core business logic is where we want to be.
• What is the difference between refactor and rewrite?
• Refactor can be done incrementally, whereas a complete rewrite would have to happen “behind closed doors” until it is completed
• Fedora did a lot of new development, which was a risky venture albeit a successful one
• Difference between us and Fedora: The Fedora group had enough resources, with committed institutions contributing $30,000. Fedora has about 250 institutions; DSpace has over two thousand. We need to figure out how to best harness that large user group, particularly from non-North-American institutions
• How can we reach out to the non-USA institutions?
• Mostly around what’s going on in the UK: everything we are doing around repositories is in preparation of the open access ref
• Need to come back to the definition of contribution; in-kind contributions is a way forward; suggest we don’t close the gate on random, ad-hoc improvements
• Can DSpace try to work more with the European funding models
• Repositories have changed since DSpace stared. We use it for a lot more things nowadays. DSpace has to be a place for other kinds of content
• Is DuraSpace able to accept smaller contributions? Full membership is a challenge.
• Is there marketing material for how to convince your boss to support DSpace?

BREAK

Notes on the roadmap presentation (cont.)

• Integrations to lower effort to deposit - 
• Priority selection for 7.0 - Top priority items depend on whether there are developers available, not feasible to make everything priority 1
• Priority 2 - recommended for 7.0 but dependent on contributors
• Hierarchical metadata, MODS
• Enhanced basic statistical reports - based on data already available, but not already surfaced; use cases have been collected 
• Basic preservation - format recognition, checksum tracking; potential advanced integration use cases, such as migration
• Easy and intuitive deposit UI - still collecting use cases for this, high priority but not developed enough yet
• Beyond 7.0 - priorities
• Simplify installation and upgrade - some work done on this, but more work to do; may be dependent on modularisation of DSpace hence lower priority right now
• Theme management - once single UI has been developed, focus could 
• Replacing "bundle" with metadata flags on bitstreams
• Prioritised integrations - dependent on UI framework

How will we achieve this?

• Managed projects - based on part time, donated developers with scheduled (1-2 week) development sprints
• More volunteers/contributors needed to achieve this; some organisations have stepped forward already but get in touch

DSpace Single UI - 7.0 release late 2016

• Prototype (at least) 2-3 UI platforms
  • at least 1 Java-based
  • at least 1 non-Java
• By the end of 2015 intention to approve a single platform/prototype and finalize the developer team/schedule
• Early 2016 - developer sprints begin in readiness for a 7.0 release

Discussion

• 3 UIs in prototype but only one will go forward as the new UI for 7.0
• Clear path for moving to new UI for users
• Need input from the DSpace community early 
• Make the process as open as possible 
• Goal at OR2016 would be to present some kind of beta
• Resources for testing will be stretched and a lot of effort from committers with testing for 6.0 candidate, plus work on prototype
• Prototyping may have to be done by people who are not committers
• Need to scope now what 6.0 release contributions are with an earlier cut off 
• Suggestion that 6.0 could be a larger bug fix release and hold off major changes to UI based on potential single UI in later release
• Does there need to be a 6.0 release this year? 
• There was some discussion about this in the roadmap meetings
• Feeling was that there are things that institutions would like to get into 6.0 as soon as possible 
• There is some development in process around the API  on the 6.0 status page - Atmire have been developing this
• High risk not to do a 6.0; roadmap is speculative at the moment, and targeted for end of 2016 but this cannot be promised potential for a big gap between major releases
• More people really needed, not just for members, but also developers/contributors who can help and also test
• More contributors fundamental to the roadmap

Other 7.0 priorities

• Projects will be established for these with a similar development model as the single UI project, not as developed at the moment
• Mentoring may be possible to build on the committer team and bring on developers/contributors to become committers

How you can help

• Become a DuraSpace member
  • Helps toward hiring a Product Manager
  • Voice in DSpace governance & roadmap

• Donate a developer (part time)
  • choose a project
  • get in touch
  • sprints get scheduled by DuraSpace

Discussion

• Acknowledgement of the amount of work that has gone into developing the roadmap and strategies
• Support for open discussion and use of DCAT - this would be continue for future projects

DSpace 6.0 planning

• 6.0 status page - DSpace Release 6.0 Status
• Highest priority is to clean up search/browse
• Basic priorities have been identified
• Atmire - a few open issues on JIRA that Atmire are working on, should be resolved through work being undertaken with Sydney at the moment
• Collection quality control management has been requested by Georgetown
• Rough list at the moment
• Pull request nearly ready for the OAI harvester  - CottageLabs
• 'Code Review Needed' - flagged items mean that something is ready for testing and developers would be interested in feedback
• Texas A&M - SAF (Simple Archive Format) builder working with batch loading, added capabilities for special licences
• DSpace Labs project - cool tools that have been developed/under developed where people can go and test these and also work collaboratively
• Licences - access control licences, specifically for datasets where need special licence request that prompts login
• Special agreements page 
• Command line utility for reporting
• More contributions welcome for the REST API - gaps to be identified
• More use cases very welcome - there are lots there already
• None of the use cases cover 'Review'
• Add new use cases using the template here: Use Cases, also add to and comment on current use cases
  
  

Discussion

• What is the migration status of DCTerms? - DCTerms schema came with version 5.0 (in addition to Dublin Core)
• What is the plan for completing migration to DCTerms from Dublin Core? 

• Ticket for this work open in JIRA 

  Jira
  server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key DS-1927

• DSpace-general - list is very busy and easy for things to get lost; suggest that questions be moved to Stack Overflow - http://stackoverflow.com/

Questions

• IRC - is there intention to move to web/audio meetings?
• IRODs - is there current integration for this for Dspace? EUDAT have been working on something in this area
• Integrations - is there somewhere that we can survey and record who is working on specific integrations?  Such as a Google Spreadsheet? Suggestion to contact DCAT in the first instance and then look at ways to survey the community