All, As a Committer, I'm going to go ahead and step out on limb here, and admit that I agree with most of what has been put forth by both Dorothea and Christophe. That being said, I'm not claiming to speak on behalf of all the Committers :)
I would *love* a more beautified DSpace...a clean, "flashy", web-2.0 interface, a modular system that is easy to extend via plugins/add-ons, an *easy* way to share/install those plugins/add-ons between institutions, and an *easy* way to upgrade core DSpace (without merge nightmares between your local hacks/customizations and the features of the new version). I'm also in full support of working towards better needs assessment. But, at the same time, a part of me feels that different institutions will have some different needs based on how they are using of DSpace. So, in the end, allowing for easy extensions/modules, and easy sharing of these community-developed features is a great way to go. That being said, I'd like to mention just a few things to look forward to with 1.5 and beyond: 1) I believe there will be vast strides to beautifying DSpace UI, once we all get our hands on Manakin in 1.5 (many thanks to Scott P & all at Texas A&M). The modularity within Manakin should also allow us to all develop new an interesting Themes & Aspects, which should be much more shareable amongst institutions. (But, we also need to find a place to actually post these for sharing!) 2) I believe that our move towards the Maven build system (thanks to Mark D) with 1.5 will be a huge step in the right direction for better modularity within DSpace, and better separation between the core API and various Interfaces (Manakin, JSP, OAI-PMH, LNI, etc.). There are still a few kinks here, but we're learning quickly and attempting to make things easier to manage as separate modules (and also easier to upgrade!). The goal here is to hopefully help allow community-developed customizatins/add-ons to flourish and not be a continual pain in managing/updating. In addition, we want to make them more easily shareable between institutions (i.e. without the pain of merging local code, etc.). I'm not claiming this will all be figured out or 100% perfect in 1.5...but, it is a goal I'm hoping we can get to by 1.6 or 2.0 (or whatever comes after 1.5). As a Committer, I also feel obligated to mention that the Committers are all volunteers. We are working hard to make DSpace better for all of us, but there's only so much we can do (and largely our development work is defined by our the individual interests of the institutions which pay our salaries). Therefore, DSpace is still dependent on new features/ideas/functionality being proposed & developed/prototyped by an active user community. The Committers may be able to step in and help out (when their institutions allow), but I believe an active community is still necessary. Remember, the Committers are often just highly-active community members! Case in point: I was only asked to become a Committer after my giving back to the community (in the form of DSpace tutorials and Q&A on listservs), as well as the large amount of work in designing, re-designing & developing the Configurable Submission (which my institution allowed me the opportunity to take on). I'm really glad to see these discussions taking place! It means we do have people in the community who care strongly about DSpace and are willing to share their opinions and suggestions for moving forward. I encourage you to continue to help drive DSpace in the right direction! Ok...that's my diatribe or rather long $0.02 :) - Tim Christophe Dupriez wrote: > Hi ! > > At PoisonCentre.be, we use DSpace for scientific (medical) information > collection, organisation and internal re-publication, e.g. Knowledge > sharing (not ETDs)! > > I find rather funny that this discussion occurs in the technical thread > and not the general one. > The technicities are the reasons we meet, the subjects vary! > > I share most of Dorothea opinions. > > I strongly support the creation of a DSpace group for user needs assesment. > The output of this group should be: > 1) use cases, > 2) value of thoses use cases for the institutions we represent, > 3) essential "user side" characteristics of the corresponding > functionalities those uses cases imply. > > From there: > 1) a "designer board" could propose functionalities (no buzzwords!) to > fulfill those needs. > 2) developpers would be invited to find "mentors" within the users > groups and to produce a prototype. > 3) User group would then discuss prototypes results and would choose > those that must be worked further for inclusion in DSpace trunk. > 4) Committers would work on "mature prototypes" (user proof) to make > them 100% compliant to DSpace architecture and coding standards. > > IMHO, this process should be tightly driven by the Foundation and > financed by institutions taking advantage of DSpace know how, technology > and emulation. > > It seems to me that project IDEALS is an example of this: > https://services.ideals.uiuc.edu/wiki/bin/view/IDEALS/RequirementsProduction > > > An example of the "users requirements" challenges we could achieve for > DSpace: > http://www.vufind.org/ > http://zoombox.gmu.edu/vufind/ > > For my institution, I need now to fulfill the challenge of crosslinking > different DSpace instances (or collections) to have one serve as an > authority list for some fields of others (and to use those relations in > searches). > > Have a nice day! > > Christophe Dupriez > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > Dorothea Salo a écrit : >> On Nov 13, 2007 1:23 PM, Susan Teague Rector <[EMAIL PROTECTED]> wrote: >> >> >>> Our debate here is centered on future support of ETDs in DSpace. We've >>> had to do quite a bit of customization to support ETDs (thank goodness >>> for Tim Donahue's code :)! Does anyone know if there are future plans to >>> better support ETDs in DSpace? >>> >> >> With the understanding that I'm not a DSpace committer and not >> involved in any way with DSpace or the DSpace Foundation except as >> DSpace user and occasional bug or patch submitter... >> >> My sense is that DSpace development has only vaguely and loosely been >> guided by real-world use cases not arising from its inner circle of >> contributing institutions. E.g., repeated emails to the tech and dev >> lists concerning metadata-only deposits (the use case there generally >> being institutional-bibliography development), ETD management, true >> dark archiving, etc. etc. have not been answered by development >> initiatives, or often by anything but "why would you even want that?" >> incomprehension or "just hack it in like everybody else!" >> condescension. >> >> There are hacks for some of these uses, yes... but from a sysadmin's >> perspective, hacks endanger smooth upgrade paths, and from the >> perspective of many librarians, hacks are entirely out of reach >> because IT rather than the librarian controls the box DSpace lives on. >> >> When innovation has occurred around DSpace, it has generally died on >> the vine because of the aforementioned threat to smooth upgrade paths. >> TAPIR and Researcher Pages may serve as the requisite gruesome >> warnings here; they died not because the ideas underlying them were >> bad (they emphatically weren't! if we still had TAPIR, Susan wouldn't >> have had to ask the question she just did!), but because almost nobody >> dared adopt them. I see all kinds of nifty conference presentations >> involving DSpace mods -- but they provide me no practical benefit >> whatsoever, because the code isn't out there and I probably couldn't >> use it if it were! >> >> DSpace's lack of a plugin/mod API, coupled with the amazing spaghetti >> dinner under its hood, has stifled service innovation in the >> repository space for years, and will continue to do so until the >> defect is rectified. Neither EPrints nor Fedora is in a much better >> position just now, but in all honesty, I predict that the first >> platform to *have* a half-decent mod API (especially one that welcomes >> mods written in friendlier languages than Java) will experience an >> explosion of innovations that will eat the other platforms' lunch. >> Manakin assuredly helps, but not quite enough. >> >> SWORD may also help, rather backhandedly, by providing an ingest path >> that doesn't rely on the horrendous web UI or the awkward batch >> ingester. We'll see; I'm hopeful. I'd far rather build an ETD app that >> used SWORD to drop ETDs into DSpace than try to hack DSpace for ETDs >> myself, much less try to push the committer group to do so. >> >> It may be worth noting at this point that I put my votes where my >> mouth is; when the DSpace development survey came out, I put a mod API >> at the very top of my desiderata. I encourage other repository >> managers with unmet needs to speak up for this! It's vastly more >> important for the long-term health of DSpace and the services we are >> building around it than are (for example) controlled vocabularies. >> >> Dorothea >> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > DSpace-tech mailing list > DSpace-tech@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-tech -- ======================================== Tim Donohue Research Programmer, Illinois Digital Environment for Access to Learning and Scholarship (IDEALS) 135 Grainger Engineering Library University of Illinois at Urbana-Champaign email: [EMAIL PROTECTED] web: http://www.ideals.uiuc.edu phone: (217) 333-4648 fax: (217) 244-7764 ======================================== ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
