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.

Developers Meeting on Weds, June 29, 2011


  • General Announcements:
    • New "Unreleased Documentation" Space in Wiki: DSDOCDEV (You can start adding 1.8.0 Docs here immediately!)
      1. DSDOCDEV -> Developers write new docs/update docs here (before release)
      2. DSDOC -> This space always points to the latest released docs
    • Reminder: GSoC's Weekly Update meeting immediately after this meeting (21:00 UTC) (also GSoC Mailing List)
  • GSoC Discussion Topic (May wait until GSoC Meeting at 21:00UTC)
    • How can we support "infrastructure" for GSoC projects? For example, supporting a virtual server for demoing/testing
      • General answer from DuraSpace. There's a few options:
        1. Students/Mentors could set up a Free Amazon Virtual server. If somehow you went beyond the needs of the "Free" category during GSoC, DuraSpace would reimburse you up to a limit (Need to determine that limit, but likely not more than the $500 received from Google for each project).
        2. DuraSpace could host a GSoC virtual server on our Amazon account. But as this costs us money (NOT free), it would either be: (a) temporary (will be taken down almost immediately after GSoC), or (b) there would be one virtual server for all GSoC projects to share.
          • If we went this route, management of the software (DSpace & prerequisites) on the server would likely fall to GSoC mentors and students.

General Reminders

  • GSoC General Reminders:
    • GSoC's Weekly Update meeting immediately after this meeting (21:00 UTC)
    • New GSoC Public Mailing List this year (shared with Fedora & DuraCloud):
    • Important Dates (full timeline)
      • May 24: GSoC Begins
      • August 22: GSoC Ends

Topics in the Waiting...

  • Topics which are still on the "back burner" (which need someone to lead a "Special Topic" meeting around them)
    • Do we want to schedule a meeting to go over proposed Modularization / Refactoring work in near future?
    • Discuss improving how DSpace handles Metadata. Several ideas mentioned recently:
      • Updating to current DCMI standards: DS-805
      • Creating a new "dspace" internal usage schema (for administrative, or non-DC metadata)? Formalize the "dc" schema to be strictly valid QDC/DC?
      • Metadata on all DSpace objects (not just Items)
      • Per discussion at OR11, DCAT is going to make recommendations on Metadata Schemas that DSpace should support.
    • Discuss forming a "Documentation Management Team"? Or reworking our procedures for managing/reviewing/approving Docs on the Wiki.
    • More discussion of Proposed RoadMap to 2.0
      • In meantime, feel free to forward thoughts on to Tim or everyone (via dspace-devel or dspace-commit).
    • Followup on some Async Discussions (both from last week and from recent email threads):
      • Tim & Mark D had a discussion about potentially reorganizing the SVN "Modules" area into more specific "groupings", to make it more clear which modules/projects are "supported" and which may be experimental, etc. Would like to consider possibly reorganizing into these general 'groupings':
        1. "Sandbox" - all modules which are still experimental (or very outdated?) should likely move to existing SVN Sandbox area
        2. "Core Modules" (may need a better name) - These are fully supported modules which actually are released as part of out-of-the-box DSpace.
        3. "Extension Modules" (may need a better name) - These are modules which should be considered "more stable" than those in Sandbox. But, they are not released as part of out-of-the-box DSpace (rather they can be installed separately as "addons" or "extensions" to DSpace).
      • The idea would be that "Sandbox" and "Extensions" areas are open to any/all developers to take part in development. But that the "Core" area is likely managed more like current SVN TRUNK (where you need to be a "Committer" or "Highly Trusted Developer" to commit code there).

Meeting Notes

JIRA Review, Welcome Andrea Schweer as new Committer, New DSDOCDEV wiki space, DS-935 review

Meeting Transcript

  • No labels