suggestions for changes, potential solutions to issues, etc.
Place for proposals around improving how we as a community or as a development team are organized.
topics requiring in-depth discussion and analysis from all interested parties
Features which don't exist (yet)
Proposals that have either been resolved or identified as part of another project/proposal.
- Advanced Embargo Support — The University of Michigan and @mire are initiating work to create a more robust and configurable embargo feature than the one that currently exists in DSpace. We would like to invite others to tweak the feature set if there's additional features of interest.
- CurationTaskProposal — Create a standard way such tools and services could be integrated and used. The idea is to define an abstraction called a 'curation task' which operates at the Item level of the DSpace data model (but whose effects may very well be on individual bitstreams, or in the creation of new ones), and have some generic machinery for managing these tasks (running them, reporting on outcomes, etc).
- Development Policies Proposal — Stuart Lewis's thoughts after his experience as 1.6.0 Release Coordinator. Some of Stuart's key points are quoted below, but read his full blog entry for more background on these ideas. (Reviewed on 10 March 2010 during DSpace Dev Mtg)
- Distributed Community and Collection Management — DSpace 1.6.0 now allows for Delegated Community and Collection Management
- DSpace 1.8 Configurable Reviewer Workflow
- DSpace 4.0 indexing commands
- Embargo on Bitstream
- Enhancing the metadata available for Communities, Collections and Files — allow metadata not just at the Item level
- Google Analytics Statistics in DSpace
- Item Versioning Support
- JIRA Workflow Improvements
- Linked Open Data for DSpace — EPrints supports VOID and LoD, http://semanticweb.org/wiki/VoiD http://semanticweb.org/wiki/VoiD So should we.
- Maven Release Artifact Use & POM Optimizations
- Metadata For All — This is based on Claudia's comments in the commiter list and the topic discussed elsewhere. Goals should be to expand on this and relate it to other projects/efforts. For instance, the async release proposal will now include establishing a true "API" for DSpace legacy objects and placing this in the "modules" directory where other projects can depend on it.
- Migrate Search and Browse to DSpace Discovery — This is a proposal to replace DSpace Search and Browse implementations completely with Solr
- Migration to GitHub
- NewFeatureReviewWorkflow — Proposal for closer collaboration between Committers and DCAT when it comes to reviewing & locating resources to implement new feature requests.
- OAI — The DSpace OAI offers only very basic sets out-of-the-box.
- ORCID Integration
- Proposal to Update DC Registry and Add DCTERMS Registry
- ReleaseAdvisoryTeamProposal — Proposal to create a Release Advisory Team to help support the Release Manager during DSpace releases, and also provide opportunities for more immediate feedback from repository managers or other non-techie community members. (Reviewed on 10 March 2010 during DSpace Dev Mtg - see page for comments)
- Replace DSpace ConfigurationManager and PluginManager — Work on using the DSpace ServiceManagers ConfigurationService, Activators and Spring Configuration of Services to replace Configuration and Plugin Manager will finally and effectively encapsulate this functionality and remove a few sore spots in DSpace design where these "God Objects" interfere with our ability to make all parts of DSpace more easily replaceable and reconfigurable.
- Stateless Embargo Authorization Support — readdress how the current embargo is implemented in DSpace, this Issue comes up because we have started working on an Embargo solution that actually uses the start/end dates of resource policies to enforce the embargo rather than a cron tab script.
- Statistics Addon — DSpace 1.6.0 now includes an improved Statistics engine based on Apache Solr http://lucene.apache.org/solr/
- Thoughts on Version Numbering
- TimeDrivenReleaseProposal — Proposal to move to regular, recurring releases on a schedule. (Reviewed on 10 March 2010 http://www.duraspace.org/irclogs/index.php?date=2010-03-10 during DSpace Dev Mtg – see page for comments)
- Updating the Qualified Dublin Core registry in DSpace to the latest standards of the DCMI — Qualified Dublin Core registry in DSpace has not been updated for 8 years. Standardization would help compatibility with other systems and benefit from information gathered by the DCMI community
- Upgrade Process Improvements — Improve upgrade Process with tools that complete and test upgrades.
- Versioning — Versioning is planned as a future contribution to DSpace by NESCent and @mire
Proposals that have either been retired or decided to not move forward on. These may contain details that still may be of interest in future proposals
- Adding metadata authority controls and vocabularies to the data model — Open up rights to use a controlled vocabulary and link from an external source
- Asynchronous Release — Asynchronous Release: Asynchronous Release is change in the DSpace release process and version numbering process on modules within the DSpace trunk to allow more flexibility adding prebuilt Addon modules into DSpace.
- Asynchronous Release - Alternative Option
- CGIProposal — Configurable submission is one of only a few mechanisms in DSpace to assist the process of managing the metadata or other characteristics of items being ingested. Another tool is the Item template, which notably also is only configurable by collection. You can think of both of them in terms of a more general capability: using contextual information to streamline or automate the ingest. We can call this capability 'context-driven ingest' or perhaps 'context-assisted ingest'. Maybe the best descri
- Database Persistence of Configuration State — Design Direction Proposal to work on the elimination of configuration files in favor of storing configuration in database wherever possible.
- Develop support for additional metadata standards — Use the "Other" field to specify which standards
- Fedora Inside
- Improved or more transparent metadata flexibility — Simplify/make local customizations more accessible through UI and expose RDF triples
- Maven Project Consolidation
- Metadata enhancement work or proposals summary — summary page of the metadata projects/priorities identified by the October 2011 community survey on improving metadata support https://wiki.duraspace.org/download/attachments/30217377/Metadata+Support+Survey+Final.pdf?version=1&modificationDate=1328709175068 authored by the DSpace Community Advisory Team at the request of the DSpace Committers/Developers https://wiki.duraspace.org/display/DSPACE/DSpaceContributors
- Moving metadata related configurations from dspace.cfg to the database — Improve the verification/safety measures when editing/removing metadata fileds
- Proposal For Metadata Enhancement
- Proposed RoadMap to 2.0 — This page represented a proposed RoadMap to 2.0 from Tim Donohue. It still needs broader discussion/approval before adoption.
- Quartz for Asynchronous Scheduling Service — Using Quartz as a utility to manage asynchronous eventing in DSpace Services, we can setup a job scheduling environment in the DSpace web application that is consistent across platforms. Likewise, jobs can be managed such that they are persistent across tomcat sessions/restarts and give the Repo Admins the ability to manage the scheduling and de-scheduling of activities.
- Refactoring MediaFilterManager for greater reuse and flexibility
- Refactoring the DSpace Domain Model
- Refactor Packagers to support Chain of Command
- Restructure Trunk Projects — This is a page of possible technical refactoring proposals for moving the trunk forward towards greater modularity and plug-ability.
- Standardizing the default namespaces — Currently instead of creating a customized metadata schema, some DSpace repository managers edit the default registry, effectively breaking compliance with the standard Dublin Core. This can create a problem for the portability of data to/from of your repository. It has been proposed that in the future that DSpace would include 3 different metadata schemas, to insure that the metadata will be easily portable to other systems
- VOID LoD Endpoint Descriptor — EPrints supports VOID and LoD, So should we?
The Discussions Archive contains various developer musings, ideas, historical tidbits.