Page tree
Skip to end of metadata
Go to start of metadata

Developers Meeting on Weds, June 22, 2011

Agenda - Documentation Mgmt Discussion

  • General Announcements:
    • Notes from OR11 Developer Meeting now posted: DevMtg 2011-06-06 - OR11 Meeting
      • Also our brainstorms around the "Modern Repository": Modern Repo Brainstorming Activity
  • Discuss forming a possible "Documentation Management Team". Or reworking our procedures for managing/reviewing/approving Docs on the Wiki.
    • Jeff Trimble will lead this discussion
    • Background: A few issues to be aware of in regards to Documentation:
      1. Obviously, primary docs are now on Wiki at: DSpace Documentation
      2. Currently we have no place to start to build Docs for 1.8.0 (as above wiki link is also the official 1.7.2 docs)
      3. Also worth noting that Documentation for 1.7.0 was a "mad scramble" (i.e. not well organized) where it was mostly barely completed in time for release (due to a lack of prior organization around where people could contribute their docs). We'd like to avoid this "mad scramble" for 1.8.0 (as it isn't fun for Jeff nor Tim nor the Release Coordinator)
  • One possible way to organize our Documentation on Wiki: Similar to how DuraCloud handles their Wiki Documentation?
    1. DURACLOUDDOC Space – Always includes the latest official documentation (for the latest release of software)
    2. DURACLOUDDEV Space – Is a place to actively write new documentation for the next release. Once that next version of software is released, the contents of DURACLOUDDEV are copied to DURACLOUDDOC space.
    3. DuraCloud also keeps around Wiki Docs for previous (major) releases: e.g. DURACLOUD08 space for 0.8 release (in this case, the 0.8 DURACLOUDDOC space was copied to DURACLOUD08 before the new 0.9 release docs were moved to DURACLOUDDOC)
  • Time Permitting: JIRA Catch-Up – starting with issue DS-819
    • (NOTE: JIRA CATCH-UP WILL MOVE BACK TO BEGINNING OF MEETINGS NEXT WEEK – Just want to be sure we have enough time to discussion 1.8.0 Documentation)
    • We will continue "Quick Review" format (2 minutes per issue, with extensions only as necessary), as we need to try to review JIRA issues more quickly. (More details on "Quick Review" format at JIRA Cleanup Sessions)
    • Search for all Unresolved Issues (since DS-819)

General Reminders

  • GSoC General Reminders:
    • New GSoC Mailing Lists this year (shared with Fedora & DuraCloud):
      • duraspace-gsoc : Public list (anyone can join), but mostly for Mentor & Student discussions, public feedback, cross-project collaboration opportunities, etc.
      • duraspace-gsoc-mentors : Private List (Mentors/Admins only) for GSoC administrative purposes only
    • 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 (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
      • 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

Documentation Mgmt Discussion, small JIRA review

  • Documentation Mgmt Discussion
    • Developers decided that we need to have an "In Development" space for Documentation
    • General release plan for Documentation:
      1. Docs which are unreleased will be written in DSDOCDEV space.
        • Review of documentation should also likely happen in DSDOCDEV space.
      2. During Release Process, we will copy docs from DSDOCDEV to DSDOC (official documentation) space. We will also generate PDF and/or HTML.
      3. Immediately after Release, DSDOCDEV is again for the next "unreleased" documentation (in preparation for following release)
        • DSDOC is always officially released documentation.
    • Developers also noted that we need to be better about creating our own Documentation. We also need to ensure that we are completing Documentation at least two weeks before Release (to ensure enough time for editing/reviewing of docs).

Meeting Transcript

  • No labels