forwarding on Jeff Trimble's response -- which he accidentally only sent to me...
-------- Original Message -------- Subject: Re: [Dspace-tech] How to actually get an item embargoed? Date: Thu, 09 Sep 2010 11:55:41 -0400 From: Jeffrey Trimble <[email protected]> To: Tim Donohue <[email protected]> It is always easier to UNable something than to ENable it in the DSpace-world IMHO. Sometimes getting something to work is more difficult than turning it off. So I would agree with Tim that it's better to ship something already working and just turning it off instead of getting frustrated by the configuration. As for the documentation, sometimes we all miss the boat. Since this was one feature I didn't really play with, I will take the hit in going over the documentation to see if it made/makes sense or not. Richard was phenomenal in writing the initial documentation. I just gave it some lipstick to look pretty. (Language style consistency, look, feel.) Now that embargo is in the current release, the time has come to upgrade the docs for this. My $.03 worth. --Jeff On Sep 9, 2010, at 11:29 AM, Tim Donohue wrote: > I'd actually go one further and say: > > (1) We should update the manual to make clearer (like Mark suggests) > > AND > > (2) We should work to ship 1.7 with a default embargo already setup > (i.e. pre-configured) -- so that all you need to do is update > input-forms.xml and uncomment the pre-configured embargo field(s). If > an institution doesn't like the pre-configured version, they can > always > modify it to use different fields or have different values, etc. > > What do others think? Should a pre-configured version be in 1.7? > > It seems like this question keeps popping up over and over again in > different forms (e.g. "how do I enable it?", "how does it work?", > etc.) > Might be best to make this easier for everyone with a pre-configured > version -- and let them decide if they want to extend it or not. > > - Tim > > On 9/9/2010 10:10 AM, Mark H. Wood wrote: >> I worked over the Javadoc in the embargo package, to improve my >> understanding and (I hope) to fill in the overall process and >> requirements a bit. Committed revision 5342. >> >> The new package comments might serve as an appropriate starting >> point for >> expanding the manual in this area. >> >> >> >> >> ------------------------------------------------------------------------------ >> This SF.net Dev2Dev email is sponsored by: >> >> Show off your parallel programming skills. >> Enter the Intel(R) Threading Challenge 2010. >> http://p.sf.net/sfu/intel-thread-sfd >> >> >> >> _______________________________________________ >> DSpace-tech mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/dspace-tech > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > DSpace-tech mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-tech Jeffrey Trimble System LIbrarian William F. Maag Library Youngstown State University 330.941.2483 (Office) [email protected] http://www.maag.ysu.edu http://digital.maag.ysu.edu ""For he is the Kwisatz Haderach..." ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
