Date: Thu, 28 Mar 2024 06:14:43 -0400 (EDT)
Message-ID: <1630328402.27386.1711620883965@lyrasis1-roc-mp1>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_27385_571186728.1711620883965"
------=_Part_27385_571186728.1711620883965
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
DevMtg 2011-07-13
DevMtg 2011-07-13
Agenda
General Reminders
- GSoC General Reminders:
- GSoC's Weekly Update m=
eeting immediately after this meeting (21:00 UTC)
- New GSoC Public Mailing List this year (sh=
ared with Fedora & DuraCloud):
- Important Dates (full timeline)=20
- 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)=20
- Do we want to schedule a meeting to go over proposed Modularization / R=
efactoring work in near future?=20
- Discuss improving how DSpace handles Metadata. Several ideas mentioned =
recently:=20
- Updating to current DCMI standards: DS-805
- Creating a new "dspace" internal usage schema (for administrative, or n=
on-DC metadata)? Formalize the "dc" schema to be strictly valid QDC/DC?
- Metadata on all DSpace objects (not just Items)
- Per discus=
sion at OR11, DCAT is going to make recommendations on Metadata Schemas=
that DSpace should support.
- Discuss forming a "Documentation Management Team"? Or reworking our pro=
cedures 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 d=
space-devel or dspace-commit).
- Followup on some Async Discussions (both from last week and from recent=
email threads):=20
- Tim & Mark D had a discussion about potentially reorganizing the SVN "Modules" area into more specific "groupings", to m=
ake it more clear which modules/projects are "supported" and which may be e=
xperimental, etc. Would like to consider possibly reorganizing into these g=
eneral 'groupings':=20
- "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 mod=
ules 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 se=
parately 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 li=
kely managed more like current SVN TRUNK (where you need to be a "Committer=
" or "Highly Trusted Developer" to commit code there).
Meeting Notes
JIRA Reviews (DS-842 to DS-845), Discussion of Modularization & Asyn=
c (and still creating a dspace-src-release)
Meeting Transcript
------=_Part_27385_571186728.1711620883965--