Developers Meeting before OR14 on Mon, June 9, 2014

• Tim explained new governance model and survey results:
  • see Tim's slides (and embedded notes) from the first part of the "Future of DSpace" Steering Group panel session: Future-of-DSpace-panel-OR14-survey-analysis.ppt
    

    • The full "Future of DSpace" Steering Group panel session slides are available at: http://www.slideshare.net/DuraSpace/future-of-dspace-steering-group-panel-at-or14

  • see also wiki page: DSpace 2014 Product Plan
• Plan for a 2 year organised project to make changes, likely scope:
  • Single UI, decrease duplicity
  • Refactor code base
  • This was presented to new Dspace steering group in May
• Technology decisions are made by committers, changing governance to get more aspects/feedback of the community involved, e.g. DCAT, administrators, funders etc.  So the managers and decision makers can get support for change.
• Bram, great to tackle more ambitious goals. 
  • Reflections on DSpace 2 work, of which some did not make it into core, what is the biggest difference with this approach. 
  • Tim not directly involved in DSpace 2 work, seems in retrospect that the communication around DSpace 2 wasn't great and therefore not integrated back into core. 
  • RR DSpace 2 was fixed resources for fixed period and no integration work was done. This new work will have to have a full integration framework. 
  • Tim there will be a product plan for this work to move it forward. 
  • Bram Dspace 2 new data model but could not fit it in as an evolution, and upgrades were not considered. 
  • GT with Dspace 2 there were technology challenges. More ambitious projects harder to fit back in.
• Tim, need plan for upgrades and migrations.
  
  

• See wiki pages:
  • Product Planning Process
  • Project Governance
• Product Planning Process: 5 point planning process diagram (every 3/5 years) revisit/review vision.
  • High Level Vision
  • Community survey/use cases
  • Product Plan
  • Implementation Options (analysis to choose best case)
  • Technical Roadmap (release plans)
• New Project Governance roles, structure is being introduced for each Duraspace product:
  • Steering Group (oversee project, set strategic direction, hold the purse strings) members are voted into role
  • Leadership Group (get to vote on priorities) Guaranteed if highest level of membership.
  • Project Members (paid members)
• DSpace specific "governance" groups:
  • Working Groups
    • DCAT
    • Technology Advisory Group (subset of committers, make analysis of options)
    • Product Planning Group (led by Product Manager)
  • Technology Team
    • DSpace Committers
• Q. Not clear what the group is going to deliver and the time-frame for delivery. Certain core features need to be addressed. 
  • A. Depends on support and participation from the community. Product planning group will start looking after the next release. Start looking at options for changes, in order to do that the Steering Committee feels that a Product Manager is needed and committer time is required. e.g. 1/2 FTE over a year, institutions can commit this resource may be rewarded with representation on the leadership group. Need to get use cases and Product Manager, hope to start to do this for DSpace 6 and if that is 2015 or 2016.
• Q. A lot depends on community buy-in and commitment of developer time. 
  • A. Just started membership campaign, too early to tell. Should have a good idea by the autumn. A lot of promise. Steering group wants to be as inclusive as possible so there is a special rate for institutions in developing nations. 
• Tim what do the committers think? This does not necessarily answer the issue of lack of developers. Need to be able to plan developer times. (Tim this may be done through 2 week sprints) 
• Q. How would communication be done between these groups? 
  • A. Tim this is still to be considered.
• DCAT co-chairs from the community (currently Bram & Maureen Walsh)
• TAG and DSpace Committers Chair = Tim
• Product Planning Group Chair = Product Manager
• Q. From EUDAT - If we cannot commit upstream where do we let people know what we have developed and let others know what we have done?
  • A. Use Github, mailing lists, raise a JIRA ticket and point back to code.
• Q. Bram how would maintenance and support be done for older versions with move to new versions, if developers are going to move to new work.
  • A. Committed to only support 3 full releases (see DSpace Software Support Policy). May not be the same groups bug fixing and working on DSpace 6.
  • Followup Q. How is it working for Fedora with working on new work and old support.
  • A. Still bug fixing 3 and maintaining 4. They've announced the final 3.x release however...at which point all momentum moves to 4.

DSpace 5.0 & Open Discussions:

• DSpace 5.0 scheduled for November/December with the current development model (see DSpace Release 5.0 Status). 
• Deadline for new feature submissions (pull requests) is tentatively October 06 2014. 
• Still looking for a DSpace 5.0 release team. Peter Dietz and Hardy Pottinger will be part of the release team. 
• Tentatively Oct 20 feature freeze, testathon early November.
• Basic Documentation is required for all new features, e.g. How to use and configure.
• What are people working on for 5.0?
  • Mirage 2: Bram, UI work and discussion, Mirage 2 for XMLUI user interface. Includes new UI technologies, Bootstrap and extension language for CSS. New build tools e.g. Grunt. Stylesheets need to be precompiled. Release in 2 flavours, one precompiled and source versions to allow you to pre-compile. Do not want to make the installation more difficult. Can put a bootstrap theme over the top. Key advantage of the source version is that all the CSS and javascript is minified for performance, this is not the case with the pre-compiled version.
    • Edinburgh investigating making the JSPUI to look like Mirage2.
• REST API Discussion:
  • Bram if we build a new UI it should interact with the RESTAPI. Building a read only DSpace on RESTAPI would be manageable.
  • Tim, Could even have multiple APIs, a read-only and a write API for different purposes.
  • Q: Why not just use SOLR for the discovery layer. A. Have to know SOLR.
  • Q from Tim anyone looking at RESTAPI? Peter and Anya, Richard Rodgers (in MDS project), will share URL, does not do search, does not model workflow at the moment, Read, Write and Delete of DSpace domain objects.
  • Graham, concern with working on top of a RESTAPI, need to be tightly integrated. Why isn't it just Fedora?
• What else are we working on for 5.0?
  • ORCID support: Bram, work for 5.0 with integrating Orcid, funded with ORCID integration and adoption programme, within submission and Item edit and CSV batch edit. Using DSpace 1.6 authority control to store the ORCID. Using a system generated ID. Allows storing of other IDs not just ORCID. Not tackling use-cases for ORCID minting. Not visualising the information on the item record page.  Look up to live ORCID API and existing registry to improve the results. Does not map to eperson. Multiple forms of the name are stored in ORCID. DSpace authority cache, to store ORCID data, script to get the authority data updated. 
  • Bram, "researcher pages" should be configurable, working on this but no promise for Dspace 5.0
  • Open Repository / BioMed Central looking at working on streaming of audio/video. 
    • Tim there is a JIRA ticket for HTML5 video and audio patch (). 
    • Kim S looking at streaming as well based on engineX (details at: Audio/Video Streaming (RTMP, HLS, DASH) Support). 
    • Tim might be good to have both an HTML5 and a streaming server option (former could be "out of the box" / simple...latter would be more for high end / advanced sites). Would be good to get into DSpace 5.
    • Was also discussed in this March Developer Mtg: DevMtg 2014-03-19 - Let's Talk About Features
  • EUDAT rewritten replication for iRODS and an enhanced control panel. Tim there is a ReplicationTaskSuite plugin to store to Duracloud or a local filestore (However, sounds like EUDAT is using a custom built iRODS "replication" tool). Other control panel changes, e.g. Shibboleth logins, OAI-PMH. Licencing module for other licenses other than CC and licensing which would require licensing to sign-in.
  • Richard Rodgers, to add documentation for configuration of curation task to pull data from webservices e.g. Sherpa Romeo. Skeleton webapp for curation tasks ??
• Development Processes / Making Contributions:
  • Q from Duraspace: Do people have issues with making contributions to the release, publish work, find collaborators and get code into core. How should we improve the process? A lot of work comes in at the last moment which can push released back. Please share early via JIRA, Github and mailing lists.
  • A. From Graham T could create a developer hub, for user to go and talk about development. Not sure of a platform to do this on though.
  • Should we combine the wiki and JIRA, link them together?
  • Mailing list discussions go stale.  Wiki is never kept up to date / hard to find current projects, if they are even listed there. Is there an easier way? 
  • Andrea S, somewhere to share small changes for feedback e.g. A "stackoverflow" for DSpace, up votes etc. What is possible via github? 
  • SS Is this something for the Product Manager to help manage. 
  • Action: separate JIRA's from general DEV mailing list to two mailing lists.  Some people want to see Devel discussions without JIRA. Others want JIRA notifications without Devel discussions.
  • Action: Not obvious how to create an account in JIRA. Tim will talk with DuraSpace staff about re-enabling self-registration
  • Action: We should have a small group investigate ways to "share work / ideas" earlier...something like "stack overflow" for DSpace?  Need to avoid duplication of effort/projects. Need a better way for individuals/institutions to advertise what they are doing (or have done). Empower the discovery of small tweaks or existing projects. A place for folks to share large or small projects.  Graham T, Andrea S, and Tim raise hands.
• Bram, World Bank has work they want to contribute e.g. OAI sets, but is on the 1.8 codeset at the moment, so there may be conflicts with latest codebase.