Page History

...

1. Tim Donohue
2. Hardy Pottinger
3. Mark H. Wood
4. Ivan Masár
5. Andrea Schweer
6. Claire Knowles
7. Lisa Johnston
8. Terrence W Brady
9. Elin Stangeland
10. Graham Triggs
11. Monika Mevenkamp
12. Maureen Walsh
13. Sarah Potvin
14. Andrea Bollini (4Science) (Cineca)
15. Roberto Suardi (Cineca)
16. Sarah Molloy
17. Bram Luyten (Atmire)
18. Ignace Deroost (@mire)
19. Richard Rodgers (not sure of exact times)
20. Bill Ingram
21. Tara Stephens-Kyte (UBC)
22. Roeland Dillen
23. Leila Sterman (MSU)
24. Susan Borda
25. Suzi White
26. Jyrki Ilva
27. Erika A. Juarez Ibarra
28. Anis Moubarik
29. Catherine Cronin (NASA Langley)
30. Nicholas Webb (Mount Sinai Health System)
31. Daniel Draper (Colorado State Univ.)
32. Jose Carvalho (University of Minho) 
33. Veronique Lecat
34. Maura Carbone (Brandeis University)

Possibly Attending / Unsure

...

•  Historically, DSpace has grown organically: if someone wants a new feature, it gets developed and contributed. It should be made clear that this roadmap is a departure from the way development has been done in the past.
• We do have a very active userbase, a lot of people are contributing. How do we sustain that?
• We are proposing that the model for DSpace development will have to change. We are proposing a much more managed process. We will be coordinating the work around releases and asking institutions to commit resources toward development sprints.
• Why we think this will work: Fedora 4
• We will need to change the rules for committers: as it is now, if enough committers agree on a feature, it gets in. Going forward, the committers will only work on features that are part of features should also be analyzed for whether they align with the roadmap.

Discussion on Sustainability Goals

...

•  Concentration will be on the next two releases: 6 and 7
•  c.f. RoadMap wiki page
• Anonymous feedback can be given on the wiki
• DSpace 6.0 will be the last ad-hoc-development release, but with an eye to the roadmap; 7.0 will fully align with the be roadmap driven
• 7.0 will be late 2016 / early 2017
• Need to start planning immediately!

...

•  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