Versions Compared

Old Version 93

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version Current

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

Info
titleDSpace Meeting Notes

Community Notes page: http://piratepad.net/or11dspacemeetingImage Removed

Agenda: (NOTE: This agenda is flexible, and based on discussions throughout day is subject to change)

...

...

Info
titleInitial Meeting Notes

Most of the below notes are just copied from this Community Notes page: http://piratepad.net/or11dspacemeetingImage Removed During the meeting we had encouraged everyone to take notes on that PiratePad page.

...

  • SKOS Authority Controls
    • SOLR Based authority control plug for DSpace. Term completion against stuff you put in your SOLR.
    • Always lacking: authority control is always a list, but controlled vocabularies are graphs/networks. Usecase Nescent: SKOS Hive (built on sesame) authority source, now exposing this through SOLR in DSpace submission forms.
    • Feedback on enhancing authority control in DSpace:
  • WebMVC (Freemarker UI development) - Talk on this Saturday
    • Instead of newer features, project is mainly focussed on completing the existing UI functionality. (a modern JSP UI).
    • Feedback on WebMVC
  • Submission Enhancements in DSpace
    • In-browser interface to edit the submission interfaces
    • Feedback on submission enhancements in DSpace:
      • (Elin noted we need to be careful about our usage of the term "Workflow".. developers sometimes have a different interpretation to community)
    • Reviewer workflow - Talk on this Friday
    • Framework for more flexible workflows (different edit steps, etc)
    • Feedback on reviewer workflow:
      • Elin: need for a common terminology on Workflow vs Submission. Is Submission part of the workflow according to the developers?
  • New UI built over RESTful services
    • Yes, it's kind of a new UI. But more oriented over building widgets, over the REST API.
    • Aimed at better testing the REST API
    • Returning student (Bojan) now serving as mentor, which is a 'GSoC first' for DSpace
    • Licensing (strict GPL requirements) has become a big factor in decisions re: toolkits/frameworks/etc to use

DSpace with Fedora-Inside Brief Updates:

  • Long term project.
  • 1st step already passed: being able to move DSpace objects around. AIP exporter for the whole object (metadata, content, access rights, ...)
  • Goal: using these AIP packages to feed a fedora with.
  • Next step: how will this exported data be well represented in Fedora?
  • After that: how to put business logic of DSpace on top of Fedora. Problem: not enough technical staff in Duraspace, so it will take a long while. In addition, DuraSpace doesn't want to do this work alone, as individual institutions better know the needs/requirements. DuraSpace is looking for other stakeholders to jump in, participate and speed things up.

...

  • Background:
    • "DSpace 2" as a concept/version number has been floated for ~5 years
    • The definition's changed over time
    • Are we moving towards Dspace 2? Fedora-inside-DSpace == DSpace 2?
  • Some Possible Version Numbering Options:
    • 1.8, 1.9, 1.10, 1.11 .... 2.0 (we decide when to make the major version shift to "2")
    • 8, 9, 10, 11 ... (drop the "1.", like Java)
    • YY.MM (eg. 12.11), like Ubuntu
    • YY or YYYY (e.g. DSpace 11 = 2011, or DSpace 2011)
  • Scott: What's the problem we're trying to solve?
  • Richard R: Expectations around 2.0, how close we are to it (as we approach 1.9, etc.), what we do to make it clear where 1.x is in relation to "2.0"
  • Richard J: Shouldn't this be a marketing issue, not an issue for developers to figure out?
  • Bram pointed out that encouraging sites to upgrade to the latest versions, and making those upgrades easy and painless, will result in more feedback and more interest from developers, and therefore more good code.
  • Scott pointed out that even though 2.0 was "revolutionary" in its initial conception, in practice we've been evolutionary/incremental when it comes to actually releasing new features, versions, etc.
  • Stuart pointed out that in recent years, we've been getting much better in terms of how often we release, restricting 1.x.1 releases only to bugfixes, etc.
  • Over half the room raised their hand to "We don't ever want to release a 2.0". A good alternative being floated is to jump straight to 3.0 and then continue as normal, with major version reflecting major architectural change, and we know for the future that if we're planning big projects, we should use codenames instead of numbers!
  • People who are currently happy users of DSpace and following current release will not care about new versioning schemes, and will upgrade in any case.
  • There's a major opportunity in winning people again, who decided in the past that the DSpace product didn't fit their usecase.
  • The Final Vote:
    1. 3 people voting for going from 1.x --> 3.0 (i.e. Skip over '2.x' version)
    2. 11 people voting for dropping major, eg. DSpace 3, 4, 5, 6 OR 9, 10, 11
      • By "dropping major" we mean moving from a "x.y.z" versioning to just a "y.z" versioning. So, rather than a 1.9.0, we'd just potentially call that "9.0" or we'd name it "3.0" instead
      • There was some indecision whether we should move to "3.0" after 1.x is done, or just drop the "1." and move right to "9.0", "10.0", etc.
    3. 4-5 people voting for date-based versioning (either YY or YY.MM)
    unmigrated-wiki-markup
  • Results: 2.0 is gone, and we will move to a "\[major\].\[minor\]" numbering scheme (instead of \ [major\].\[minor\].\[subminor\]).
    • Do a strawman poll to find out exactly how the branding will work, whether we co-brand date and major number. (e.g. DSpace 3.0 (2012))
    • Feedback from others: We need to document our version numbering very well. What does it take to reach a "major" release, or do we just release a new "major" release each year. Needs to be clear to users what these version numbers "mean".
    • But the 1.x.y will definitely go, at some point. And 2.0 is definitely gone. RIP 2.0
Note

Although a decision was made to retire the name "2.0", this has not yet been announced publiclyin a more public fashion (on mailing lists, etc). The reason is that DSpace 1.8.0 will still be called 1.8.0. After the 1.8.0 release, we will make a decision on what the following 2012 release will be named (likely either DSpace 3.0 or 9.0). At that point in time, we will announce the retirement of the name "2.0" , and announce the next version of DSpace(though many features of the DSpace 2.0 Prototype will continue to be added to DSpace little by little), while also announcing the new version of DSpace.

So, in summary: DSpace will likely change its version numbering scheme after 1.8.0 is released in Oct 2011. At this point in time, we are undecided what that new version numbering scheme will be. However, we will likely skip over the number "2.0", as that version has too much past history and assumptions built up around it. In the end, we hope to simplify and clarify our numbering scheme. As always, DSpace will continue to release at least one new major version each year – it's just that after 1.8.0 the DSpace version numbers may look slightly different than in the past.

DCAT Update / Feedback

  • They've been taking new feature requests from JIRA, members pick issues that are of interest to their institution or that they've heard interest for, figure out prioritisation that way
  • They've been through about 5 new feature requests this way so far
  • Feedback from committers/developers is useful – coming back with further requirements, etc.
  • Some issues require participation from the broader community, DCAT will be working to enable this
  • Also working with DSpace ambassadors to try and reach repository managers that might not follow dspace-tech or be involved via usual channels
  • Has been a bit slow to start, but it has been really helpful having Robin (in capacity as 1.8 release coordinator) and Tim join in the DCAT discussions
  • Encouraging members with a particular interest in new features/issues to join in on IRC committer meetings
  • Robin: One benefit has been giving repository managers a voice and making sure developers don't just follow their own pet projects, remind them of real-world priorities
  • Tim: gives us a perspective outside of our own institution
  • Stuart: Can we get a new flag or status in JIRA so we can get DCAT review of issues we've written code for
    (or issues we don't feel are clearly defined... instead of them ending up stale because we couldn't figure out how to move on them in a committer meeting)
    • TODO: Tim will investigate ways to "flag" an issue in JIRA as "needing a DCAT Review"
  • Bram: How many of the 1000+ repository managers are involved in meetings/conferences/any kind of communication where they can express their requirements, issues, ideas? Eg. I use MS Word but I don't turn up to MS focus groups on word processor design. Would be really cool to cross-ref the list of dspace.org listed instances, and people registered on the mailing lists, to find out about those listed on dspace.org who are NOT on the mailing lists. They might need some extra attention to get involved.

...