Timestamps are in GMT/BST.
[0:54] * kdweeks (~Adium@2001:468:c80:a103:2c6e:b697:2b79:f318) Quit (Quit: Leaving.)
[6:48] -verne.freenode.net- *** Looking up your hostname...
[6:48] -verne.freenode.net- *** Checking Ident
[6:48] -verne.freenode.net- *** Found your hostname
[6:48] -verne.freenode.net- *** No Ident response
[6:48] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:48] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:48] * Set by cwilper!ad579d86@gateway/web/freenode/ip.22.214.171.124 on Fri Oct 22 01:19:41 UTC 2010
[8:41] * pbecker (~email@example.com) has joined #duraspace
[11:46] * helix84 (~firstname.lastname@example.org) has joined #duraspace
[11:47] * helix84 (~email@example.com) has left #duraspace
[11:47] * helix84 (~firstname.lastname@example.org) has joined #duraspace
[12:18] * kompewter (~email@example.com) Quit (Ping timeout: 255 seconds)
[12:23] * mhwood (firstname.lastname@example.org) has joined #duraspace
[13:02] * tdonohue (~email@example.com) has joined #duraspace
[14:16] * peterdietz (uid52203@gateway/web/irccloud.com/x-tapghkicuunxnyac) has joined #duraspace
[15:03] * cknowles (~firstname.lastname@example.org) has joined #duraspace
[15:07] * kdweeks (~Adium@2001:468:c80:a103:1c71:b989:545e:cb89) has joined #duraspace
[15:27] * cknowles (~email@example.com) has left #duraspace
[16:10] * awoods (~firstname.lastname@example.org) Quit (Read error: Connection reset by peer)
[16:20] * pbecker (~email@example.com) Quit (Quit: Leaving)
[16:22] * awoods (~firstname.lastname@example.org) has joined #duraspace
[16:38] * hpottinger (~email@example.com) has joined #duraspace
[16:48] * kompewter (~firstname.lastname@example.org) has joined #duraspace
[16:48] * kompewter (~email@example.com) Quit (Remote host closed the connection)
[16:49] * kompewter (~firstname.lastname@example.org) has joined #duraspace
[17:20] * dabaker (4b827d02@gateway/web/freenode/ip.126.96.36.199) has joined #duraspace
[17:20] * dabaker (4b827d02@gateway/web/freenode/ip.188.8.131.52) has left #duraspace
[18:42] * hpottinger (~email@example.com) Quit (Quit: Leaving, later taterz!)
[19:19] * hpottinger (~firstname.lastname@example.org) has joined #duraspace
[20:00] * KevinVdV (~KevinVdV@d5153d041.access.telenet.be) has joined #duraspace
[20:01] <tdonohue> Hi all, welcome. It's time for our weekly DSpace Developers Meeting. https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-04-15
[20:01] <kompewter> [ DevMtg 2015-04-15 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-04-15
[20:02] <tdonohue> We'll kick off today with another "status check" on DSpace 5.2 and high-priority tickets which have been scheduled for that upcoming release
[20:03] <tdonohue> I know our *highest* priority ticket to resolve in DSpace 5.2 is Solr issues regarding Statistics, namely DS-2486 and its DSPR#894
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-2486 ] - [DS-2486] Missing fields in solr statistics data from previous DSpace versions - DuraSpace JIRA
[20:03] <kompewter> [ https://github.com/DSpace/DSpace/pull/894 ] - Ds 2486 reindex solr by aschweer
[20:04] <tdonohue> whoops, I mean DSPR#905 (the new version)
[20:04] <kompewter> [ https://github.com/DSpace/DSpace/pull/905 ] - Ds 2486 reindex solr by aschweer
[20:04] <mhwood> Looks like Andrea is reworking it slightly to address memory issues with large volumes of statistics.
[20:05] <tdonohue> Yes, I know Andrea is working on further improvements for scalability. I think it'd also be good though to find some additional testers out there...again, this issue will affect everyone who upgrades to DSpace 5.x and uses Solr Stats
[20:06] <tdonohue> So, if there's anyone else in that scenario (wanting to upgrade to DSpace 5 + Solr Stats), then if you could chip in on testing, we'd appreciate it. Thus far, hpottinger has been the primary tester, and aschweer the primary developer
[20:07] <tdonohue> But, the more eyes on this, the more stable the upgrade of your Solr Stats data will be in 5.2
[20:07] <peterdietz> scouts honor, I'll clone an instance and test it out today
[20:07] <mhwood> At last I have been able to start trying it out. I built a 5.1 + cherry-picked the PR. Now I need to work out how I'm going to create the starting point for a test.
[20:08] <tdonohue> Thanks peterdietz...and mhwood!
[20:08] <tdonohue> The "starting point for a test" is *any* older Solr Stastistics index. They all loose their geographic info when you upgrade to DSpace 5
[20:08] <mhwood> 1.8 is not too old?
[20:08] <tdonohue> "lose" not "loose"
[20:09] <hpottinger> correct, and word of advice, if you're testing this, once you have a stats core upgraded by 5.x, save a copy of that data dir around, for backtracking, no reason to have to wait for ant update to do its thing all over again
[20:09] <tdonohue> mhwood: no, it shouldn't be. If you point DSpace 5 at an index created by DSpace 1.8, then it will upgrade that index to the latest version of Solr. But, your data will be missing all geographic info, as a full "reindex" is required
[20:10] <tdonohue> (and that PR above is what does the full "reindex")
[20:10] <hpottinger> specifically, you can't change Solr schemas without a reindex
[20:10] <mhwood> But I'll have to 'ant update' to get the index upgraded, so I need something I can update. I'll work it out.
[20:11] <peterdietz> Sorry to be out of loop. I should test with a 1.8 instance, or 3, or 4, or all?
[20:11] <tdonohue> mhwood: right, you need an old index to update from
[20:11] <hpottinger> doesn't matter, any version, whatever is easiest
[20:11] <mhwood> I mean: I need a copy of an old DSpace (not just the index) to run update against.
[20:11] <tdonohue> peterdietz: you can test from any old version (>=1.8) of DSpace. Just upgrade it to DSpace 5, and watch the geographic info disappear. Then run the PR to test if it "comes back"
[20:12] <hpottinger> right, I don't think the stats core will make much sense unless it lines up with a site's handles
[20:14] <hpottinger> tdonohue's description is a good one, I would add "after you're done, before you test the reindex, save a copy of the stats data dir, it will make your life slightly easier as you re-test newer reindex code
[20:14] <mhwood> Good idea.
[20:15] <tdonohue> you *might* be able to test with just an index (no old db)....but, you may only see the "geographic" info at the site-wide level (i.e. stats from homepage), since as hpottinger notes your handles won't match up elsewhere
[20:16] <mhwood> Well, I can copy the database too.
[20:16] <tdonohue> (but that's just a bit speculative...I think the site wide stats though aren't driven by handles, so you may still be able to view them with an empty DB)
[20:16] <tdonohue> In any case, thanks peterdietz & mhwood for offering to help test!
[20:16] <hpottinger> Indeed, thank you!
[20:17] <tdonohue> Are there any other PRs or tickets we'd like to discuss for inclusion in 5.2? Anything else needing more eyes / help / discussion?
[20:18] <hpottinger> https://github.com/DSpace/DSpace/milestones/5.2
[20:18] <kompewter> [ Issues · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/milestones/5.2
[20:18] <tdonohue> (thanks hpottinger, I was just looking for that link)
[20:18] <hpottinger> DSPR#888
[20:18] <kompewter> [ https://github.com/DSpace/DSpace/pull/888 ] - DS-2418: Incompatible oracle sql method on collection.java by ctu-developers
[20:19] <hpottinger> DSPR#850 has been on our list for a long time
[20:19] <kompewter> [ https://github.com/DSpace/DSpace/pull/850 ] - [DS-2131] SWORDv2 ingestion fails with NullPointerException when replacing a non archived item by KevinVdV
[20:19] <hpottinger> SWORD people? want to test that one?
[20:20] <mhwood> Do we have SWORD people here today?
[20:20] <peterdietz> PR888 / 2418 looks good to me
[20:20] <tdonohue> that PR #888 (Oracle one) looks like an "obvious fix" to me...we wrote the "DatabaseManager.applyOffestAndLimit()" method specifically for that purpose
[20:21] <tdonohue> I haven't tested it (888) though
[20:21] <hpottinger> tdonohue: want to give it a +1?
[20:22] <tdonohue> Just did
[20:22] <mhwood> I agree that that looks like the way to go.
[20:22] <hpottinger> re: DSPR#850, KevinVdV (the author) is here
[20:22] <kompewter> [ https://github.com/DSpace/DSpace/pull/850 ] - [DS-2131] SWORDv2 ingestion fails with NullPointerException when replacing a non archived item by KevinVdV
[20:23] <KevinVdV> Would be great if anybody could test it…. it seeems like a sensible fix :)
[20:23] <hpottinger> KevinVdV: want to maybe see if you can round up a SWORD tester for DSPR#850?
[20:23] <kompewter> [ https://github.com/DSpace/DSpace/pull/850 ] - [DS-2131] SWORDv2 ingestion fails with NullPointerException when replacing a non archived item by KevinVdV
[20:24] <hpottinger> or, you know, anyone want a good excuse to play with this? https://github.com/CottageLabs/dip
[20:24] <kompewter> [ CottageLabs/dip · GitHub ] - https://github.com/CottageLabs/dip
[20:24] <KevinVdV> Do you have anybody in mind ?
[20:25] <tdonohue> 850 also looks like a pretty "obvious fix" just reading the code. But, again, haven't had any chance to test it
[20:25] * aschweer (~aschweer@2406:e000:518e:1:2d5f:13b3:829d:9efb) has joined #duraspace
[20:26] <mhwood> Good morning.
[20:26] <hpottinger> KevinVdV: there are a few people who are notorious SWORD users, and DSpace commmitters, you can start with them
[20:26] <aschweer> hi all, sorry I'm late, dst change
[20:26] <tdonohue> Hi aschweer, just a note that we found you a few more "testers" for your Solr Stats re-indexing PR (#905), peterdietz & mhwood
[20:27] <aschweer> everything said here today about pr 905 testing is correct
[20:27] <aschweer> cool thanks peterdietz and mhwood
[20:27] <tdonohue> thanks for verifying :) Anything else you wanted to add around 905, aschweer?
[20:27] <aschweer> looks like you will need to give your tomcat lots of memory or it will die during export
[20:28] <aschweer> ive been deleting all pre 2015 hits before doing reindex while testing, just to have less data to deal with
[20:28] <aschweer> sorry about typos and speed, I'm on my tablet while having breakfast
[20:29] <hpottinger> aschweer: are you still thinking that sorting is the culprit for the OOM errors?
[20:29] <aschweer> yes
[20:29] <tdonohue> aschweer no problem. I will mention that I have heard before that *sorting* in Solr can be very memory intensive. So, your note about the sorting being the cause seems right
[20:30] <aschweer> not that Ive had much time to think about it, being asleep much of the time after we last spoke hpottinger ;)
[20:30] <aschweer> yeah i just couldnt thinmk of a clean way to get a deterministic ordder of the solr docs otherwise
[20:30] <tdonohue> For example...this blog post has some Solr "Golden Rules", including "Avoid using sort": http://blogs.alfresco.com/wp/lcabaceira/2014/06/20/solr-tuning-maximizing-your-solr-performance/
[20:31] <hpottinger> if only we could reindex before we reindex...
[20:31] <aschweer> so now I'm hoping it will help to add date based filter queries so that it only needs to sort those docvs that match the fileter
[20:32] <KevinVdV> Needs to run, until next time (I’ll try to find a tester for my sword stuff)
[20:32] * KevinVdV (~KevinVdV@d5153d041.access.telenet.be) Quit (Quit: KevinVdV)
[20:32] <aschweer> i ran eclipse memory analyser on hpottinger's heap dump and it pointed to comparators etc as culprits. so im pretty sure it is the sorting
[20:33] <mhwood> That sounds good. It should be sorting samples of roughly the same, smaller size.
[20:33] <tdonohue> Your idea of a workaround sounds reasonable enough...hopefully it helps
[20:33] <hpottinger> oh, yeah, thanks for reminding me, I owe mhwood for reminding me that I could ask Tomcat to leave that heap dump on OOM errors
[20:33] <hpottinger> so, thanks, mhwood
[20:33] <aschweer> abnyway, ive had a success report from someone else in NZ after upping memory. I'll see if i can get him to comment publicly..
[20:34] <hpottinger> how many docs in that index?
[20:34] <aschweer> thanks tdonohue, i just hope i have time soon to put that in code. anyone else wants to jump in, be my guest.
[20:34] <tdonohue> Good to hear. Thanks aschweer for your hard work here. And, thanks hpottinger for your detailed testing & memory reports
[20:34] <mhwood> You're welcome.
[20:34] <aschweer> 6.5M i believe
[20:34] <aschweer> thank you :) Terry Brady deserves some credit too, I built on his approach
[20:35] <hpottinger> my test index is 17M, I'm willing to add more memory to the fire, but I'm not exactly hopeful :-)
[20:35] <aschweer> yeah fair enough! though tbh, the index in question had some extra fields on top of what stock dspace stores
[20:36] <aschweer> i think tomcat at 2gb was enough for that index, but I may be misremembering and it may have been 4gb
[20:39] <hpottinger> If you can get your colleague to comment publicly, I'll try whatever they suggest.
[20:39] <tdonohue> Or have them email hpottinger if they are shy ;)
[20:39] <aschweer> cool, hopefully he will
[20:40] <hpottinger> +1 I take suggestions via e-mail, too
[20:40] <tdonohue> So, stepping back again to 5.2 in general. Anything else to discuss around tickets needing attention / help / etc. ?
[20:41] <aschweer> if someone could have a quick look at the im thumbnailing stuff, that'd be great. it's a very mall change
[20:41] <hpottinger> again: https://github.com/DSpace/DSpace/milestones/5.2
[20:41] <kompewter> [ Issues · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/milestones/5.2
[20:41] <aschweer> sorry, not sure i can dig up the link quickly on the tablet
[20:41] <tdonohue> aschweer: yep, I glanced at it (just haven't had time to spin up my test environment). It looks sane to me, and small. I give it a +1 (though with no testing)
[20:42] <tdonohue> it's DSPR#917
[20:42] <kompewter> [ https://github.com/DSpace/DSpace/pull/917 ] - [DS-2544] Improve temp file handling for IM thumbnailer by aschweer
[20:42] <aschweer> thanks :)
[20:43] <tdonohue> any other tickets/PRs folks want to discuss here?
[20:43] <aschweer> I've run it on 150 items and kept an eye on /tmp using watch - much improved behaviour for cleaning up after it
[20:43] <tdonohue> aschweer: that's good to hear. As noted (in the related ticket), I do see this behavior as well...some temp files do end up sticking around seemingly forever, and they just keep eating space
[20:44] <aschweer> thanks tdonohue
[20:45] <tdonohue> Ok, so, it sounds like in general DSpace 5.2 still cannot be "scheduled" quite yet. Still more work to do here, and some memory stabilization of the Solr reindex work. So, seems like the best we can do is touch base again next week
[20:45] <aschweer> agreed
[20:46] <mhwood> Yes.
[20:46] <tdonohue> As the final topic for today, I had added to the Agenda some notes on the kickoff of the "Strategic Planning" / "Technical Roadmap" work that has begun on the Wiki (An email was also sent to Steering Group, Leadership Group, DCAT, and Committers)
[20:46] <tdonohue> Here's a link to that email on the publicly viewable DCAT list: https://groups.google.com/forum/#!topic/dspacecommunityadvisoryteam/7ZJ9-nJgRFo
[20:46] <kompewter> [ Google Groups ] - https://groups.google.com/forum/#!topic/dspacecommunityadvisoryteam/7ZJ9-nJgRFo
[20:47] <tdonohue> Oh wait, that's not publicly viewable...hmm
[20:47] <tdonohue> Well, the jist is that the work has begun here: https://wiki.duraspace.org/display/DSPACE/Strategic+Planning
[20:47] <kompewter> [ Strategic Planning - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Strategic+Planning
[20:48] <tdonohue> There's a schedule for the coming weeks, and what the "working group" plans to achieve. We've also begun drafting a 3-year "Strategic Plan for Technology" here: https://wiki.duraspace.org/display/DSPACE/DSpace+2015-18+Strategic+Plan+-+Technology
[20:48] <kompewter> [ DSpace 2015-18 Strategic Plan - Technology - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+2015-18+Strategic+Plan+-+Technology
[20:48] <aschweer> i need to go to work, just wanted to say thanks a lot tdonohue for keeping us in the loop
[20:49] * aschweer (~aschweer@2406:e000:518e:1:2d5f:13b3:829d:9efb) Quit (Quit: aschweer)
[20:49] <tdonohue> All of this is *very much* in flux / work in progress (and it's moving very rapidly). But, I wanted to be sure to point you all to *where this work is happening*, so that you can follow along ("watch" the pages if you wish) and even add your own immediate feedback/comments/questions
[20:50] <tdonohue> If there are any questions though or immediate comments, I'd be glad to answer them (here or elsewhere)
[20:51] <tdonohue> Oh, and as a "bonus", in prepping for this work, there has been some *major* Wiki reorganization. If you haven't seen the new sections/categories on the left-hand sidebar, take a look and let me know what you think
[20:53] <tdonohue> Not hearing any immediate questions/comments on all this. Mostly, I just wanted to point you all at the ongoing work. If you do have questions/comments or suggestions, please do feel free to comment on any page, or send me a note, etc.
[20:53] <mhwood> Thanks.
[20:54] <tdonohue> Any last thoughts for today? Other discussion topics?
[20:55] <hpottinger> Agility is really a whole process, that's just an observation, I like where you're going with the wiki, but you're proposing a big change
[20:56] <tdonohue> hpottinger: could you expand on that? Which part do you feel is the "big change"? The wiki reorg?
[20:56] <tdonohue> (just want to be sure I understand your observation here)
[20:59] <hpottinger> no, no, making agility/flexibity a priority
[20:59] <hpottinger> you have to engineer processes to make that happen
[21:00] <mhwood> You mean "Agile(tm)", or "not fat and stiff"?
[21:00] <hpottinger> good point, mhwood
[21:01] <tdonohue> Oh, I see, you're referring to the Strategic Plan for Technology (which is still really rough)
[21:02] <hpottinger> it really does depend on what we mean when we say "agility and flexibility" in goal 2
[21:02] <tdonohue> "agility" there means more "not fat & stiff". We are not guarranteeing "agile" processes by that. Plus, to be fair, those 5 "goals" are more long term, and the "actions" (some still need full approval) are the things we want to move towards in the next 3-5 years to move towards those goals
[21:03] <mhwood> Another way to look at that is that we are able to make reasonable progress and keep up with user needs, with the available developer cycles.
[21:04] <mhwood> Which may mean making choices, spinning off some alternatives as separate projects, etc.
[21:05] <hpottinger> one way to do that is to take the work in smaller chunks, less monolithic releases, but, anyway... a discussion of processes might come along with that word "agile"
[21:05] <hpottinger> and I am happy for that
[21:05] <tdonohue> Those 5 overaraching "goals" were actually borrowed directly from the 2013 "Vision Document". They are more the "themes" we want to work towards with regards to DSpace. The *actions* though are the things we feel might help us move towards those goals in the next 3 years or so
[21:06] <tdonohue> (If you notice, the "goals" are not really "achievable" in any real sense...they are more like our "values" with regards to DSpace)
[21:06] <mhwood> Yes, I see.
[21:07] <tdonohue> and, as noted, one of the "values" is to make DSpace more "agile" and "flexible"...but we didn't necessarily mean "Agile (tm)", though that is obviously also up for discussion as part of that
[21:07] <hpottinger> makes sense
[21:08] <peterdietz> okay. So then does this get translated at some point to developer action items?
[21:08] <mhwood> So "agile" here means being able to provide what people ask for in a reasonable amount of time, unimpeded by unnecessary weight or constraint.
[21:08] <tdonohue> But, that is good feedback / obvervations. One thing this makes me realize is that "Goals" may not be the best terminology for these statements
[21:08] <hpottinger> one thing I think we might want on the radar screen is the notion of a "business logic" layer
[21:08] <mhwood> "directions"?
[21:09] <hpottinger> "values" maybe rewrite like a manifesto? :-)
[21:09] <tdonohue> peterdietz: Yes, the "Strategic Plan for Technology" is being drafted first...we are also analyzing all the "Use Cases" (and prioritizing/ranking them). Finally, comes the "Technical Roadmap" which will be *developer action items* (or at least our proposed developer action items)
[21:09] <tdonohue> peterdietz: the schedule for this work is laid out here: https://wiki.duraspace.org/display/DSPACE/Strategic+Planning
[21:09] <kompewter> [ Strategic Planning - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Strategic+Planning
[21:10] <tdonohue> yea, "directions" or "values" may be better than "goals" here
[21:10] <mhwood> Sorry, must go. Will check the log.
[21:10] * mhwood (email@example.com) has left #duraspace
[21:11] <hpottinger> I just think that whatever we build, somebody somwhere will have an opinion about a business logic rule, and want it changed. It would be nice if DSpace would let them do that easily.
[21:12] <peterdietz> I've got a near-term project to crack S3 bitstream storage. Fingers crossed this will be a manageable piece of work
[21:12] <tdonohue> Though, to be clear about the "Technical RoadMap", it may not include *all* developer action items, as it'll only span 1-2 years. We are going to suggest the highest priority development projects (and likely timeframes) and then we'll need to find the staffing (from volunteers, service providers, others) to make those development projects happen. We'll also want to list other things we feel are important, but may not necessarily f
[21:14] <tdonohue> Any other thoughts or questions for today? (Noticing we are well "over time" here)
[21:16] <peterdietz> Not much. Just we'll continue to get ad-hoc enhancements from myself / community. Whatever random feature that solves a use case. It would be helpful to have some document for guidance that says, yeah, that fits in, or no, that is likely outside the scope of dspace, as defined here
[21:17] <peterdietz> And something to push more emphasis on portions that do matter, but aren't getting the attention. preservation / curation. Better fixity. Access documents in myriad of dissemination formats...
[21:17] <peterdietz> Anyways, I'll wait for this process to continue
[21:17] <peterdietz> ...and go test Andrea's SOLR code
[21:18] <tdonohue> ad-hoc work would fit in, in my opinion. But, yea, a lot of this has just begun. Thanks though for the comments & observations here
[21:18] <hpottinger> it would be useful as a tool for developers, too, so people don't build something just for their own use case, but have the larger used case in mind
[21:19] <hpottinger> +1 test that reindex
[21:20] <tdonohue> And we definitely are trying to still gather Use Cases....some could very easily be met in a more "ad-hoc" fashion (as they currently are)...others may require more collaboration / group effort. Feel free to review the Use cases though & enhance or add your own: https://wiki.duraspace.org/display/DSPACE/Use+Cases
[21:20] <kompewter> [ Use Cases - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Use+Cases
[21:21] <tdonohue> With that though, I'm going to close up this meeting (as I need to step away shortly anyways). Please do feel free to keep the comments/observations/questions coming though (on wiki, via email, via future mtgs, etc)!
[21:21] <hpottinger> crazy idea: offer a prize for a dev challenge entry that delivers on one of the action items?
[21:21] <tdonohue> hpottinger: that is an interesting idea..hmmm
[21:22] <tdonohue> maybe, we'll have to see if we have some that seem partially achievable in light of a dev challenge
[21:28] <hpottinger> prizes don't have to be money, BTW
[21:29] * hpottinger would code his heart out for a mechanical keyboard.
[21:30] <peterdietz> I'd be interested in seeing a designer competition for DSpace. Have UX/UI designers come up with a modernized logo for DSpace. Come up with a 1 paragraph descriptive blurb for DSpace. A one-line motto for DSpace. Even designs/mockups for what you WANT an item page to look like. What you want a submission form to look like
[21:31] <tdonohue> right, yea, I agree, hpottinger. More just pondering right now if any of these would be mostly/partially achievable in a few days time (i.e. a dev challenge). Some may be...may just need to wait and see as we work towards finalizing this doc (it's still very rough & in progress as-is)
[21:32] <tdonohue> peterdietz: interesting ideas as well... it would be nice to find some UX/UI designers
[21:34] <peterdietz> Longsight's hired a marketing/design/odd-job company. They create website graphics, templates, videos, conference boothes and so on. Its expensive, but it gives you a fresh look in people's eyes when you've got a modern coherent message
[21:35] <peterdietz> but.. if people came out of the woodwork, similar to metadata / use case / visioning / developers, that would be good too
[21:35] <hpottinger> I have a feeling that a new UI might be a few pizzas away from PoC
[21:36] <peterdietz> Brazil just built a new ui, for their "open courseware" / lecture capture thing
[21:36] <peterdietz> anyways. I'm going to focus on one last batch load, and then syncing an instance to local
[21:36] <peterdietz> to #dspace
[21:38] <hpottinger> I'm serious about the UI thing, I think it's closer than we collectively think
[21:39] <hpottinger> dev challeng is more of a "show your work" and less of a "work here and now" thing anyway, I bet there's some interesting stuff people have been kicking around without talking much about
[21:41] <tdonohue> unfortunately, I have to leave now...but, yea, I would love to get a better UI and hire some UX folks to help design it / mock it up. I'm not sure I'm convinced we are that "close" to it, but I'd love to believe that :)
[21:42] <tdonohue> until later though...bye!
[21:42] * tdonohue (~firstname.lastname@example.org) has left #duraspace
[21:56] * hpottinger (~email@example.com) Quit (Quit: Leaving, later taterz!)
[23:39] * Disconnected.
[23:39] -card.freenode.net- *** Looking up your hostname...
[23:39] -card.freenode.net- *** Checking Ident
[23:39] -card.freenode.net- *** Found your hostname
[23:39] -card.freenode.net- *** No Ident response
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.