What is a Special Topic?

"Special Topics" definition: Special topics are those which often address in-depth issues, large scale redesigns or large scoped projects within DSpace software or the community as a whole. Although these larger scale topics come up during discussions from time to time, often they are set aside as they require more in-depth analysis or discussion before a decision can be made.

"Special Topics" versus "Proposals"

Special Topics are higher level topics/questions/problems which need to be addressed or discussed. They may include some details or background about the problem domain, but should not suggest any solutions to the problem.
Development Proposals should present potential solutions to the problem. One Special Topic (e.g. "How can we better handle Preservation Metadata?") may result in many Proposals (e.g. "Option #1", "Option #2", "Combo of Option #1 and #2", etc.)

Special Topics Meetings

Special Topic Meetings: Just after the DSpace Committer's meeting on 2009-Nov-04 (discussion archives) a proposal was made to occasionally designate Committer's meetings as "Special Topic Meetings", in order to begin to tackle these in-depth topics. It was proposed that Special Topic Meetings be held on the following schedule:

The first Committer Meeting of the month (see Developer Meetings) will be devoted towards special topics.
As with all Committer Meetings, Special Topic Meetings are open to the public. This means that anyone and everyone is welcome to attend, speak their opinions or just listen in on the discussions.

Special Topics To Be Discussed

Below are a list of "Special Topics" (requiring more detailed discussion) which have come up in various Developer Meetings, conference discussions, etc. This list will and should change. Feel free to add to it, add comments, etc. If comments or discussion becomes more detailed, please create a new wiki page devoted to that topic's discussion.

Runtime Reconfiguration / DSpace Services

(Last Updated: 2010-May-17)

Placeholder for discussing ability to reconfigure DSpace while running (i.e. via an Administrative UI). DSpace Services is mentioned as its ConfigurationService could be setup to listen for configuration changes and act accordingly. See this Runtime Reconfiguration email thread on dspace-devel starting on May 14, 2010.

Asynchronous releases / Continued Modularization

(Last Updated: 2010-Mar-24)

This is mostly a placeholder for topics that have come up in recent DSpace Developer Meetings. Both Mark Diggory & Graham Triggs have suggested potentially moving towards asynchronous releases of our various DSpace "modules".

How would this affect our current release strategies? Would asynchronous module releases just be for the "early adopters" who want the latest/greatest code/features/bug fixes in their DSpace install? How would these asynchronous releases be tested/vetted – or would they be primarily for quick releases of bug fixes, with new major features waiting for the next DSpace Testathon?

(Feel free to add thoughts / comments / suggestions)

What is 2.0, really? How do we get there?

(Last Updated: 2010-Mar-10)

In the past, DSpace 2.0 has been talked of as a "dream" DSpace system – we had a list of all these amazing features/ideas that would be possible in 2.0. We were able to start to bring that dream down towards reality with the recent 2.0 Prototype work, but we still don't have a true path to get to 2.0. All this while other similar open repository systems (notably Fedora & EPrints) have moved quickly on to 3.x versions. DSpace lingers still in 1.x world as we've been unable to live up to these enormous 2.x expectations.

I'd like to suggest we should begin to rethink everything we've come to expect from a 2.0. What is it we really need out of a 2.0 version? How "major" do the architectural changes really need to be before we call something "2.0"? Are we attempting to implement the entire 2.0 Prototype, or just some of its main features/ideas? How can we get there (relatively) quickly and begin to move beyond all these 2.0 expectations that hang over our heads?

Added by Tim Donohue (feel free to add your own comments/questions if you wish)

DSpace UI Development / Support

(Last Updated: 2010-Mar-26)

This is a placeholder for a March 2010 dspace-devel email thread, in which discussion began around a potential replacement to the current JSPUI as another competitor to the XMLUI. The current JSPUI is becoming more and more out-of-date with latest web technologies. Do we attempt to find a replacement for it, or do we work to build more ways for others to build new custom UIs on DSpace (e.g. via a REST API or similar)? Do we want to continue supporting multiple primary UIs (e.g. JSPUI & XMLUI) at the committer level, or do we want to allow for more community-built UIs to develop in various web languages (PHP, Ruby on Rails, etc.) with their own support/development models. What is our plan for UI development going forward – continue to keep things centralized (i.e. supported mostly by a "central" team of Committers) or allow for more third-party, externally built/supported UIs?

Developer Guidelines / Best Practices

(Last Updated: 2010-Feb-10)

Question #1: What are our best practices for coding practices? Should we write up more clear guidelines for what DSpace considers "good code" (e.g. DS-351 suggests banning empty catch statements)?

Question #2: Is it worth revisiting the current DSpace Contribution Guidelines to make sure they (1) accurately describe our current best practices and (2) are clearly stated?

Question #3: Should we have best practices for DSpace exception handling?

Question #4: Should we be using some sort of Testing Framework for unit testing (e.g. JUnit)?

Question #5: Should we have a CI service like Hudson be setup for the community to package more official interim build releases. But the largest hurdle there is someone allocating the resources to support it (I.E. server with Hudson, Continuum or Bamboo running on it)

Internationalization (i18n)

(Last Updated: 2010-Feb-11)

Question #1: Can we find a way to limit ourselves to one messages format? Currently we have two (Messages.properties and messages.xml), and unfortunately the XMLUI uses both, while the JSPUI uses just Messages.properties.

Question #2: How can we make the process of translations easier on people? Two messages formats is a bit confusing. It's also difficult to determine what keys have changed between versions of DSpace. Are there any tools (e.g. Pootle) we can recommend?

Persistent Identifiers / Handles

(Last Updated: 2009-Nov-06)

Question #1: Should DSpace continue to require usage of Handles for persistent identifiers (i.e. permanent URLs) to items, collections or communities? Or should we revisit the Persistent Identifiers prototype work?

Provenance Metadata