All (especially Committers),
+1 to what Mark Diggory states below about bringing in progress DSpace
projects (especially major ones) to a more public space.
I'd like to see us all get in the habit of working more publicly,
especially when it comes to redesign of core features of DSpace.
So,
+1
I think some of this becomes easier if / when we move to Git - particularly
with the more 'sandbox' type developments, where forking to prototype of a
set of changes to the existing code and merging back in at a later date is
required.
But I wouldn't advocate accelerating making that kind of
I'm also +1 on having some documentation describing the project you're
working on, and how to get started. Which is why I made a getting started
guide for
Discoveryhttps://wiki.duraspace.org/display/DSPACE/DSpace+Discovery+HowTo
and
I think we are all in agreement here: for example, that's exactly the pattern I
followed for the curation task work (code branch in scm, wiki doc, request for
community feedback, etc) back in Sept 10.
And I'll certainly do so with CGI. There really isn't any code yet, but my
design thinking has
Dear Dspace Developers,
A couple of weeks ago there was a discussion at the developers meeting about
what to call the Beta release.
In one of the discussions in the dspace-devel list (I believe
about Asynchronous release) someone mentioned in passing something about
DSpace11 to represent the core
Currently we've got 1.8.0-SNAPSHOT available, which corresponds to trunk.
Since the target audience of feedback on the pre-release beta's is
just the developer community, we can just announce in developer
channels, and update the demo.dspace.org server every month and say
here are three cool
Hi all,
I am Mahesh Gondi, pursuing B-Tech. Computer Science Part-III from Institute
of Technology, Banaras Hindu University, India This year I've submitted
proposal on RTMP A/V integration and Usage statistics reports.
I had a query, how does the idea sound of integrating DSpace with
