Contribute to the DSpace Development Fund

The newly established DSpace Development Fund supports the development of new features prioritized by DSpace Governance. For a list of planned features see the fund wiki page.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

What is a Proposal?

"Proposals" definition: Proposals detail ideas, brainstorms or potential solutions to a known issue or problem in the code, community or process. Proposals may recommend changes we could make that may help us resolve issues we've encountered in the past. A few examples: a proposal could recommend accepting or adding a new technology, changing an API, or changing how we interact as a team or plan new releases of the software.

"Special Topics" versus "Proposals"

  • Special Topics are higher level topics/questions/problems which need to be addressed or discussed. They may include some details or background about the problem domain, but should not suggest any particular solutions to the problem.
  • Development Proposals should present potential solutions to the problem. One Special Topic (e.g. "How can we better handle Preservation Metadata?") may result in many Proposals (e.g. "Option #1", "Option #2", "Combo of Option #1 and #2", etc.)

Overview: Adding a new Proposal

This page is a place to post new proposals for review by DSpace Community and/or Developers. New proposals can recommend any sort of change to solve an existing or perceived problem/issue. A few examples: a proposal could recommend accepting or adding a new technology, changing an API, or changing how we interact as a team or plan new releases of the software.

To add a new proposal:

  1. Please create a sub-page for the details of your proposal. In your details you should describe the reasons behind your proposal. Your proposal need not be flushed out completely – even initial ideas are welcome, especially if they can start to answer some basic questions:
    • Why do you feel this will help DSpace Software or our Community as a whole?
    • What problem(s)/issue(s) are you trying to solve?
    • How do you feel your proposed solution could resolve these problems/issues?
  2. Once your proposal is ready for review/comments, add the appropriate label to classify your proposal below, but including an {excerpt} marco in your proposal page you can include a description of your proposal below.
    • Feel free to add additional proposal categories below if your proposal does not fit into an existing category.
  3. Announce that you have a new proposal posted for comment/review. The best way to announce this is via either a mailing list, or at a DSpace developers meeting (if it is a technology proposal)

To comment on an existing proposal

  1. Visit the proposal page and either comment on the proposal directly, or add your thoughts on the "discussion" page.
  2. Please keep comments constructive. Give reasons why you agree/disagree to help us improve upon the proposal.

Development Proposals

Place for proposals about underlying development and technology changes in the software (e.g. API changes, architecture/design changes, etc.). Technology changes may need to be sub-categorized if we start to receive many different levels of proposals.

To include your proposal here give it the label "developmentproposal".

  • Page:
    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.

  • Page:
    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 description would be 'context-guided ingest' (CGI), since it suggests that context can provide relevant data, but need not rigidly determine all ingest properties.
  • Page:
    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).
  • Page:
    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.

  • Page:
    Google Summer of Code 2008 Collection Workflow

    In the current DSpace implementation, a workflow system is present that allows content submitters to ingest an item in the repository, that can be reviewed by simply accepting the submitted content, changing some of the submitted metadata or rejecting the item so it can be altered by the submitter. The current collection workflow system contains up to three steps for the submission of files. Except for the metadata changes, there are no possibilities for changing any of the submission content during the different steps of the workflow system.

  • Page:
    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.
  • Page:
    Migrate Search and Browse to DSpace Discovery — This is a proposal to replace DSpace Search and Browse implementations completely with Solr
  • Page:
    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.
  • Page:
    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.

  • Page:
    Restructure Trunk Projects — This is a page of possible technical refactoring proposals for moving the trunk forward towards greater modularity and plug-ability.
  • Page:
    Upgrade Process Improvements — Improve upgrade Process with tools that complete and test upgrades.
  • Page:
    VOID LoD Endpoint Descriptor — EPrints supports VOID and LoD, So should we?

Organizational Proposals

Place for proposals around improving how we as a community or as a development team are organized. Including proposals about improving our normal DSpace release cycle (e.g. how frequently we release a new version, how we plan those releases, how we communicate those releases, etc.).

To include your proposal here give it the label "organizationalproposal".

  • Page:
    NewFeatureReviewWorkflow — Proposal for closer collaboration between Committers and DCAT when it comes to reviewing & locating resources to implement new feature requests.

Past Proposals

Past Proposals that were either accepted or rejected, see proposal notes for further details. By changing the label of the proposal to "pastproposal" and removing "organizationalproposal" and/or "developmentproposal" it will move to this list.

  • Page:
    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)
  • Page:
  • Page:
    Mirage XMLUI Theme and Restructured dri2xhtml for DSpace 1.7

    @mire contribution of new theme to support easier development and branding.Provides the following: (1) Mirage, a basic theme that contains the templates that need customization most often in the UI. (2) A Restructured dri2xhtml base templates for easing locating specific XSLT templates.

  • Page:
    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)
  • Page:
    TimeDrivenReleaseProposal — Proposal to move to regular, recurring releases on a schedule. (Reviewed on 10 March 2010 during DSpace Dev Mtg – see page for comments)
  • No labels