Page History

...

• Action 1A: Verify and validate the needs of a "modern institutional repository". This is instrumental in formalizing the value proposition of DSpace.
  
  • This activity has already begun part of the 2014 Vision Survey and Use Case gathering by DCAT. However, the gathered use cases are still being analyzed and prioritized.
• Action 1B: Survey the community on gathered use cases
  • (Do we want another, post OR15 survey of the community based on Strategic Plan, Tech Roadmap & Use Case gathering?)
• Action 1C: Clarify and improve the DSpace value proposition. Enhance our message and goals of the project going forward.  The DSpace Steering Group is working towards establishment of a new "DSpace Marketing Working Group" to help with this effort
  
  • NOTE: This is not really a "Technology" activity, but more of a "Sustainability" activity.
• Action 1D: Identify minimum set of functionality/features for 'IR-core' and refactor codebase to provide this. This core may not be functional as-is, since it may require plugins that aren't extensions (e.g. authN)

Goal 2: DSpace will be "lean", with agility and flexibility as primary goals

...

• Action 2A: Converge on a single, out-of-the-box user interface (UI). DSpace will no longer be released with multiple User Interfaces (JSPUI vs XMLUI).  A single user interface should be developed as DSpace's out-of-the-box UI. Early discussions on the requirements of this single UI (and some brainstormed candidates) are at Brainstorms on a Future UI.
• Action 2B: Converge on a single, out-of-the-box search/browse system.  DSpace will only support Apache Solr for search/browse, and the older, deprecated Lucene and DB search/browse system should be removed.
• Action 2C: Converge on a single, built-in statistical engine. DSpace will only support a single, built-in statistical engine (based on Apache Solr), and support for Elastic Search statistics should removed or migrated to an optional module. Support for Google Analytics will be retained, as it's an optional integration with an external statistics engine.
• Action 2D: Develop a basic User Interface "style / layout guide". In order to ensure a consistent user experience across all pages/features within the User Interface, we should provide basic guidelines for layout and styling of common page elements, etc. Examples may include basic guidelines for how errors/warnings/notices should be displayed, what class(es) to use for types of buttons, etc.

Goal 3: DSpace

...

can be "extended" (think plugins) or have "hooks" (integration points) to complimentary services/tools

Assigned: Richard Rodgers

[summary of goal]  There will obviously be limitations to what DSpace can and should do, so we need to have ways to support plugins/addons/extensions to that core functionality. Not all users of DSpace will need to achieve the same set of Use Cases, so we will need to define which are "core" and which would be better implemented as plugins/extensions (either centrally supported or third-party supported).

• Action 3A: Identify minimum set of functionality/features for 'IR-core' and refactor codebase to provide this. This core may not be functional as-is, since it may require plugins that aren't extensions (e.g. authN)Action 3B: Define a family of specifications/interfaces/tooling for 'implementation' plugins (like authN, storage, persistent ID services, etc).
• Action 3C3B: Define a family of specifications/interfaces for functional extensions to 'IR-core' ( working title: 'modules'), and refactor existing bundled code to conform to new model (if appropriate/cost-effective). 
• Action 3D3C: Provide infrastructure/tools for a module registry, where users can discover, and install modular extensions. Likely include both modules maintained by committers and community contributions.
• Action 3E3D: Devise a flexible but rigorous system of versioning all components (core, module, etc) where compatibility requirements can be checked/enforced by the build/deploy tools.
• Action 3F3E: Define and expose new interfaces (in 'IR-core' and possibly modules) to allow local customized code to run: 'integration points'.
• Action 3G3F: (Highly dependent on UI architectural work) Provide a user-discoverable registry/library of user interface templates (working title: 'themes'), that can be installed and adapted for local use. 

...