Developers Meeting on Weds, July 13, 2011

Agenda

• First 20+ minutes: JIRA Catch-Up – starting with issue DS-842
  • Search for all Unresolved Issues (since DS-842)

• Discussion:
  • DS-528 (RSS feeds to support richer features, such as iTunes Podcast or Media RSS) – Apple is in touch with us about getting this feature added to DSpace to support iTunesU.
    • Shall we look at including this in 1.8.0?
  • Modules Discussion (from dspace-devel thread: http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg06479.html)
    • Should we reorganize our SVN Modules area before 1.8.0?
    • Suggestions of minimally splitting out "sandbox" modules from "supported" modules.
      • Is there also a category for "third-party" modules?
      • See this particular email message for details of older modules or third party modules: http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg06485.html
  • Any Updates or Topics to discuss for DSpace 1.8.0 Release?
    • Reminder: Feature Freeze is August 19
    • DCAT seems to have interest in seeing an "Easy Upgrade Scripts" (DS-456) for DSpace 1.8: DCAT Feature review of DS-456 Create easy upgrade scripts
  • Other Topics for Discussion?

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?
    • Restructure Trunk Projects
    • Refactoring the DSpace Domain Model
    • Others listed under Development Proposals
  • 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

Meeting Transcript

• Full IRC Transcript is available at - http://irclogs.duraspace.org/index.php?date=2011-07-13