Page History
...
- Topic Suggestions for OR11 Developer Meeting?
- Rough Outline:
- Introductions & Overview of day
- Brainstorming exercise (TBA)
- Discussion & Final Decision on whether we want to change our version numbering scheme (i.e. Do we want to continue with incrementing version numbers or move to something else?)
- Brief updates on current work:
- 1.8.0 Updates & Discussion
- GSoC Updates & Discussion
- DCAT + Committers interactions
- "UnConference" style discussions? (Or would we rather have the below topic discussions scheduled out more formally?)
- Some topics worth discussing / making decisions on:
- Creating a Common Business Logic Tier
- Metadata Support
- Modularization activities & Async discussions
- Documentation Planning/Approval TeamManagement Team & ongoing Documentation mgmt in general
- Anything "annoyingly obsolete" (technology wise) we really need to address soon?
- REST API ? or other projects that may need "one last push" for official release.
- Summarizing & Bringing it all together: What do we see as our Technology RoadMap/Goals for next few years?
- Rough Outline:
...
- 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 (From past meetings discussions, this seems popular). 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)
- Discuss forming a "Documentation Management Team"? Or reworking our procedures for managing/reviewing/approving Docs on the Wiki.
- UPDATE: Jeff Trimble will lead a discussion on this in April or May. Still working on date.
- More discussion of Proposed RoadMap to 2.0 before OR11
- 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':
- "Sandbox" - all modules which are still experimental (or very outdated?) should likely move to existing SVN Sandbox area
- "Core Modules" (may need a better name) - These are fully supported modules which actually are released as part of out-of-the-box DSpace.
- "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).
- 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':
Meeting Notes
Excerpt |
---|
JIRA Review, 1.7.2 Updates, GSoC Updates, OR11 face-to-face planning, GSoC Student Update Meeting |
Meeting Transcript
- Full IRC Transcript is available at - http://irclogs.duraspace.org/index.php?date=2011-05-25
Overview
Content Tools