Timestamps are in GMT/BST.
[6:51] -rajaniemi.freenode.net- *** Looking up your hostname...
[6:51] -rajaniemi.freenode.net- *** Checking Ident
[6:51] -rajaniemi.freenode.net- *** Found your hostname
[6:51] -rajaniemi.freenode.net- *** No Ident response
[6:51] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:51] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:51] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:01] * kshepherd2 (~kim@121-99-147-19.bng1.nct.orcon.net.nz) has joined #duraspace
[12:14] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:35] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has joined #duraspace
[13:54] * kshepherd2 (~kim@121-99-147-19.bng1.nct.orcon.net.nz) Quit (Ping timeout: 252 seconds)
[14:19] * PeterDietz (~peterdiet@lib-css1pfw-krc.lib.ohio-state.edu) has joined #duraspace
[14:33] * PeterDietz (~peterdiet@lib-css1pfw-krc.lib.ohio-state.edu) Quit (Remote host closed the connection)
[14:53] * PeterDie_ (~peterdiet@lib-css1pfw-krc.lib.ohio-state.edu) has joined #duraspace
[14:53] * PeterDie_ (~peterdiet@lib-css1pfw-krc.lib.ohio-state.edu) Quit (Remote host closed the connection)
[14:54] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[14:56] * PeterDie_ (~peterdiet@lib-css1pfw-krc.lib.ohio-state.edu) has joined #duraspace
[14:58] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Ping timeout: 240 seconds)
[16:53] * edInCo (~smuxi@seta.coalliance.org) has joined #duraspace
[17:46] * Jeb (c6521fee@gateway/web/freenode/ip.198.82.31.238) has joined #duraspace
[17:46] * Jeb (c6521fee@gateway/web/freenode/ip.198.82.31.238) Quit (Client Quit)
[17:50] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has joined #duraspace
[17:53] * jschiefer (~jschiefer@nc6521fee.cns.vt.edu) has joined #duraspace
[17:57] * jschiefer (~jschiefer@nc6521fee.cns.vt.edu) has left #duraspace
[17:57] * jschiefer (~jschiefer@nc6521fee.cns.vt.edu) has joined #duraspace
[18:33] * PeterDietz (~peterdiet@dhcp-164-107-232-223.osuwireless.ohio-state.edu) has joined #duraspace
[18:34] * jschiefer (~jschiefer@nc6521fee.cns.vt.edu) has left #duraspace
[18:34] * jschiefer (~jschiefer@nc6521fee.cns.vt.edu) has joined #duraspace
[18:35] * jschiefer (~jschiefer@nc6521fee.cns.vt.edu) has left #duraspace
[18:36] * PeterDie_ (~peterdiet@lib-css1pfw-krc.lib.ohio-state.edu) Quit (Ping timeout: 245 seconds)
[18:37] * jschiefer (~jschiefer@nc6521fee.cns.vt.edu) has joined #duraspace
[18:38] * jschiefer (~jschiefer@nc6521fee.cns.vt.edu) Quit (Quit: Leaving.)
[18:42] * jschiefer (~jschiefer@nc6521fee.cns.vt.edu) has joined #duraspace
[18:45] * mdiggory (~anonymous@cpe-76-176-128-229.san.res.rr.com) has joined #duraspace
[18:46] * dspacedev (0cf896aa@gateway/web/freenode/ip.12.248.150.170) Quit (Ping timeout: 240 seconds)
[18:52] * PeterDietz (~peterdiet@dhcp-164-107-232-223.osuwireless.ohio-state.edu) Quit (Remote host closed the connection)
[19:45] * keithg (~keithgilb@2600:1003:b12c:3b70:60b6:5906:2c90:10e7) has joined #duraspace
[20:00] <tdonohue> Hi All, it's time for our weekly DSpace Developers Meeting. This week is another "Let's Talk about Features" meeting: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-04-30+-+Let%27s+Talk+About+Features
[20:00] <kompewter> [ DevMtg 2014-04-30 - Let's Talk About Features - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-04-30+-+Let%27s+Talk+About+Features
[20:01] <tdonohue> Before we get started though, just wanted to make sure to mention that I've just posted the details about the OR14 DSpace Developers Meeting. If you plan to attend, I'd like to ask you to sign up on our agenda page at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-06-09+-+OR14+Meeting
[20:01] <kompewter> [ DevMtg 2014-06-09 - OR14 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-06-09+-+OR14+Meeting
[20:03] <tdonohue> So, for the "Let's Talk about Features" meeting, I didn't get as many topics sent to me as last time. But, Anja Le Blanc emailed me this morning about a few small topics for discussion (both on the agenda)
[20:04] * kstamatis (2ebe4bcb@gateway/web/freenode/ip.46.190.75.203) has joined #duraspace
[20:04] <tdonohue> I'll admit, I don't have a lot of details about Anja's topics (didn't get to talk with her directly).. But, first she wanted to just update us on some REST API updates she's been working on (see #1 in agenda)
[20:05] <tdonohue> (oh, and Anja said she wouldn't be able to attend this discussion today, but she'd read the logs later on, for any feedback we had for her)
[20:05] <hpottinger> the stats addition looks cool and useful
[20:06] <tdonohue> Yes, I agree. The "Stats recording" idea (#2 in the agenda) sounds interesting to me as well. It would be useful to understand stats in UI vs REST vs [whatever].
[20:07] <hpottinger> I agree, both topics look interesting, I'd like to see the code, if there is a "pre PR branch" we can look at, Anja of the future (hi!) would you please send us a link to it?
[20:08] <mhwood> #1 seems like two separate things to me. The PR is for adding context to REST responses; the discussion is something about piling more stat. rendering code into DSpace.
[20:09] <mdiggory> Theres alot in that Pull request… Search, Context, Stats...
[20:09] <mhwood> My mistake, not rendering but RESTful access.
[20:10] <hpottinger> oh, hey, it's mdiggory!
[20:10] <tdonohue> oh, hey there mdiggory :) Nice to see you!
[20:10] <mdiggory> It might be better to break it up, I also see alot of work on METS Manfiests there too
[20:10] <mdiggory> :-)
[20:10] <mdiggory> I finally sliced out a little time in my schedule
[20:10] <tdonohue> I agree though, the PR might need to be broken up a bit...it's better to have multiple PRs (one per change) if possible...it makes it easier for us to review the code
[20:10] <hpottinger> yay, time-slicer!
[20:11] <hpottinger> a PR per issue is a good call, helpful if one needs to revert a change later
[20:11] <mdiggory> I have an a ulterior motive in regards tot he topic in the list
[20:13] <tdonohue> So, sounds like the basic feedback for Anja is that both ideas sound interesting...but the PR might be good to break up into its component parts (it's a bit large and hard to review, as-is, plus I notice the PR still needs some cleanup as it includes unrelated commits)
[20:13] <hpottinger> pulling it apart might help with the cleanup
[20:14] <tdonohue> +1 hpottinger
[20:14] <mdiggory> Per Context Management, there are two methods I can recommend, 1. like XMLUI/JSPUI, creat it in the filter prior to processing 2.) move it into ServiceManager / RequestService lifecycle
[20:15] <mdiggory> Using the latter allows for not having to pass it around through method parameters
[20:16] <mhwood> Are we talking about the same "context" here and in Ds-1854?
[20:17] <hpottinger> mdiggory, I think, might be refering to the recent mail list messages from PeterDietz
[20:17] <mhwood> Oh.
[20:17] <mdiggory> no, I was looking in the pull request...
[20:18] <hpottinger> DSPR#434
[20:18] <kompewter> [ https://github.com/DSpace/DSpace/pull/434 ] - DS-1854 by AnjaLeBlanc
[20:18] <mdiggory> mhwood comment above
[20:18] <mdiggory> mhwood: #1 seems like two separate things to me. The PR is for adding context to REST responses; the discussion is something about piling more stat. rendering code into DSpace.
[20:20] <mdiggory> Maybe your referring to @Context as opposed to actual dspace Context
[20:20] * PeterDietz (~peterdiet@dhcp-164-107-232-223.osuwireless.ohio-state.edu) has joined #duraspace
[20:21] <hpottinger> mdiggory: do you have a line number link you can share for the piece of 434 (re: context management) that you're talking about? (hoping the help people follow along)
[20:21] <mdiggory> https://github.com/DSpace/DSpace/pull/434/files#diff-c68045b7bb387a28c47be07536dcbdc1R80
[20:21] <kompewter> [ DS-1854 by AnjaLeBlanc · Pull Request #434 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/434/files#diff-c68045b7bb387a28c47be07536dcbdc1R80
[20:21] <mhwood> Referring to this:
[20:21] <mhwood> * In the reply to queries (except for queries for single items/collections/communities) part of the returned data is a meta data block like:
[20:21] <mhwood> <context>
[20:21] <mhwood> <limit>100</limit>
[20:21] <mhwood> <offset>0</offset>
[20:21] <mhwood> <query>http://localhost:8080/rest/items/search?author=burke&expand=metadata&title="Synagogue sanctuary"</query>
[20:21] <mhwood> <query_date>2014-01-07T15:40:13</query_date>
[20:21] <mhwood> <total_count>2</total_count>
[20:21] <mhwood> </context>
[20:21] <mdiggory> PeterDietz probibly has more context ;-)
[20:23] * PeterDietz (~peterdiet@dhcp-164-107-232-223.osuwireless.ohio-state.edu) Quit (Remote host closed the connection)
[20:23] <mdiggory> Pk, so its something completely different then….I would suggest a different terminology. context is a bit overloaded
[20:23] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) has joined #duraspace
[20:23] <tdonohue> So, this all sounds like good feedback for Anja. Anything else to touch upon? (I was just sent another Feature discussion topic which we can move along to once we are ready.)
[20:24] <PeterDietz> Hi All, sorry, kind of in a meeting right now :(
[20:25] <PeterDietz> ok, available now
[20:26] <mdiggory> So, I do just want to announce that we are hoping to contribute back in the REST area, we are implementing Tier 1 parts of the DataONE Member Node REST API http://mule1.dataone.org/ArchitectureDocs-current/apis/ for DSpace during this next quarter
[20:26] <kompewter> [ DataONE APIs — v1.2.0 ] - http://mule1.dataone.org/ArchitectureDocs-current/apis/
[20:26] <mdiggory> The architecture will use dspace-rest as a model
[20:26] <mdiggory> Jersey / Etc
[20:27] <PeterDietz> Awesome, I would love to have some development/collaboration on this space
[20:28] <mdiggory> Absolutely, there will be many synergies
[20:28] <tdonohue> sounds like a good collaborative opportunity? A way to really test-drive REST in some real-life scenarios
[20:28] <PeterDietz> I'll have a lot more time to devote to DSpace soon, as I'm changing positions, to work for Longsight. So I think I'll be able to do a mix of client work, and pure embetterment of DSpace
[20:29] <tdonohue> yes, and congrats again, PeterDietz.
[20:29] * hpottinger is giddy with joy, this all sounds great!
[20:29] <keithg> congratulations, Peter
[20:29] <mdiggory> sounds like a good opportunity PeterDietz
[20:29] <mhwood> Congratulations.
[20:30] <tdonohue> Ok, since it sounds like REST discussion is winding down a bit here (though please do keep us all updated!)...wanting to move along to the next topic (refresh the agenda if you have it up)
[20:31] <PeterDietz> I'll be all ears on REST, but we can move along I suppose. I want to take a peek at DatabaseManager/pool before I crank more on REST
[20:31] <tdonohue> Next topic: jschiefer (an undergrad at Virginia Tech) is working with another undergrad (Paul Sharma) and keithg. They have a project to enable Embargo from the commandline in DSpace 4.x: https://github.com/jebschiefer/DSpace/tree/cli-embargo-4_x
[20:31] <kompewter> [ jebschiefer/DSpace at cli-embargo-4_x · GitHub ] - https://github.com/jebschiefer/DSpace/tree/cli-embargo-4_x
[20:32] <jschiefer> Hello all
[20:32] <hpottinger> oh, hey, welcome, jschiefer!
[20:32] <tdonohue> Welcome jschiefer! Thanks for joining the discussion and bringing along your project
[20:32] <jschiefer> Thanks!
[20:33] <mhwood> Welcome. Your work sounds quite useful.
[20:33] <mdiggory> ah, define embargo in contents file for ItemImport
[20:33] <jschiefer> So this project was intended to bring the same embargo functionality in the webuis to ItemImport
[20:34] <tdonohue> I agree that this sounds like a generally useful project. I suspect there are many other DSpace users who would want the ability to manage embargoes from itemimport
[20:34] <jschiefer> currently we look for "\tembargo:<date>" in the contents file
[20:34] <mdiggory> One thought, may be also good to have CLI commands to set embargo dates on exisiting items/bitstreams.
[20:35] <hpottinger> mdiggory: via the itemupdate command?
[20:35] <mdiggory> probibly, yes
[20:37] <tdonohue> jschiefer: your approach to look for a "\tembargo:" sounds reasonable to me. I agree that, if it fits in your project's scope, it could be interesting to also find a way to update/change embargoes (via itemupdate or similar), but it probably isn't required of this contribution
[20:37] <PeterDietz> So, it would add to: https://github.com/peterdietz/SAFBuilder/wiki#advanced-usage, if that got into DSpace, I would update the SAFBuilder to support
[20:37] <kompewter> [ Home · peterdietz/SAFBuilder Wiki · GitHub ] - https://github.com/peterdietz/SAFBuilder/wiki#advanced-usage,
[20:37] <mdiggory> but maybe other areas? CSV Metadata Import,
[20:38] * PeterDie_ (~peterdiet@dhcp-164-107-232-223.osuwireless.ohio-state.edu) has joined #duraspace
[20:38] <tdonohue> jschiefer: I also should note that I'm betting it would *not* be hard to port this work to DSpace 5.x (even if you are targeting Dspace 4.x right now). Currently, there isn't too much committed for DSpace 5.x, so most any code that works for 4.x likely will work for 5.x
[20:38] * PeterDie_ (~peterdiet@dhcp-164-107-232-223.osuwireless.ohio-state.edu) Quit (Read error: Connection reset by peer)
[20:39] * PeterDie_ (~peterdiet@dhcp-164-107-232-223.osuwireless.ohio-state.edu) has joined #duraspace
[20:39] <jschiefer> tdonohue: I believe you are correct. I believe we only rely on code that has been present since 3.x
[20:40] <jschiefer> We also have two other ways of embargoing via itemimport that my partner added
[20:40] <jschiefer> -g <group name> to embargo against a group
[20:41] <jschiefer> And another text file which contains the date to embargo an entire item -- this feels clunky though
[20:41] * PeterDietz (~peterdiet@dietz72m1.lib.ohio-state.edu) Quit (Ping timeout: 240 seconds)
[20:42] <tdonohue> adding another text file just for a date does sound slightly clunky.
[20:42] <jschiefer> When using the contents file, in my testing I've found the entire item gets embargoed even though the resource policy reflects it was only set for the bitstream
[20:43] <jschiefer> So the extra file may be overkill
[20:43] <tdonohue> One thing that might help here would be to consider creating a Pull Request for us (even if it's against our 'dspace-4.x' branch). It's often easier for us to get a full picture of the code changes through a PR (plus it's easier to comment on individual lines, etc).
[20:44] <jschiefer> Sure thing, we can probably do that this weekend
[20:44] <mdiggory> bitsream level embargo should only impact bitstream.
[20:44] <tdonohue> We actually don't mind it if people create Pull Requests early on in the development process (you're welcome to even state that it's "not ready to be merged"), just cause PRs are much easier to visualize
[20:44] <mdiggory> not embargo entire Item
[20:45] <jschiefer> mdiggory: that was my understanding as well
[20:45] <tdonohue> mdiggory: yep, I agree. I wonder myself if it's a small bug in the custom work, but it's hard to say for certain right now
[20:46] <jschiefer> Should a jira ticket be opened for this as well?
[20:46] <mdiggory> I also think adding the metadata fields for embargoTerms to the dublin core metadata record should be able to trigger embargo of all bitstreams in Item.
[20:46] <tdonohue> So, is there any other feedback you'd want or questions you have for us, jschiefer (or keithg)? Honestly, it sounds like good work!
[20:47] <mhwood> Tangent: "new" embargo no longer uses pluggable "terms", right? I was concerned about the assumption that the embargo terms are just dates, but it looks like the new style always takes dates?
[20:47] <tdonohue> jschiefer: yea, a JIRA ticket also should be opened. We use JIRA as to plot out what goes in each release...so each PR needs to be associated with a JIRA ticket
[20:48] <mdiggory> one last thing, it would be really good to have something that verified/enfoced resetting of embargo policies int he event that a change in the item violates embargterm identified in the metadata (a consumer or something)
[20:49] <mdiggory> Embargo is a sensitive security / access control topic,
[20:49] <hpottinger> this is minor, but one of the first lines in the compare diff shows a commented out line:
[20:49] <hpottinger> +//import org.junit.runner.JUnitCore;
[20:50] <hpottinger> if it needs to go, it needs to go :-)
[20:50] <jschiefer> Certainly
[20:50] <jschiefer> Still a work in progress
[20:50] * PeterDie_ (~peterdiet@dhcp-164-107-232-223.osuwireless.ohio-state.edu) Quit (Remote host closed the connection)
[20:50] <mdiggory> When intended embargo terms arn't met by the repository, either through misconfiguration or user error, the repercussions impact organziations and stakeholders at very high levels.
[20:51] <tdonohue> mdiggory: I'm not sure I even fully understand how your comments play into this itemimport + embargo idea... but, maybe it'd be easier to understand once we have a PR to post comments against, or a JIRA ticket.
[20:51] <jschiefer> Could you give an example? I'm still pretty new to DSpace and how it works
[20:52] <tdonohue> yep, or an example or two could help :)
[20:52] <mdiggory> tdonohue: I'll differ till then
[20:52] <mhwood> Sounds to me like something deeper in the code. Like, Bitstream should always check for embargo compliance when rights are adjusted, or some such.
[20:52] <mdiggory> ok...
[20:53] <mdiggory> We have two mechanisms that "induce" embargo, 1. metadata fields, 2. resource policies
[20:53] <mdiggory> metadata fields identify a general embargo across all bitstreams in the item (dc.description.embargoterms / dc.date.embargountil )
[20:54] <mdiggory> resource policies have date range settings that actually control access on the bitstream independent of the above metadata fields
[20:55] <mdiggory> when the two are not aligned… issues happen such as embargo resourcepolicies not getting set on the bitstream
[20:56] <tdonohue> Are "metadata fields" ever even recommended in DSpace 4.x though? They are disabled by default in DSpace 4.x, and require extra configuration & and extra cron job to even enable them. The Documentation even talks about how to migrate 3.x embargoes to 4.x?
[20:56] <jschiefer> I see. We are only set resource policies right now so this is definitely something we need to look into
[20:56] <mdiggory> when DSpace default_bitstream_read policies on the collection are present that can create conditions that set the bitstream to be anonymous read as a default
[20:56] <keithg> jschiefer: i can show you how the metadata fields work for embargo next time we meet, if you're interested
[20:57] <jschiefer> keithg: That would be helpful
[20:57] <mdiggory> tdonohue: may be true, but they are still there… and some folks use them (us included) they are useful for embargoing through SWORD and MetadataImport
[20:58] <tdonohue> I realized I have my versions wrong..it was *pre-3.x" which used metadata field embargoes. Starting at 3.x, things mostly switched to resource policies (which is the default)
[20:58] <hpottinger> maybe we need to have a larger embargo discussion?
[20:59] <mhwood> Time to sunset "old" embargo code?
[20:59] <tdonohue> mdiggory: hmm...that's worrisome in general. My "assumption" here was that the pre-3.x embargoes would at some point "go away" (no longer be possible), or be replaced by something which is more compatible with resourcepolicies
[20:59] <tdonohue> +1 to a larger embargo discussion. I don't like the idea of maintaining two forms of embargo which can cause oddities if they are not "aligned"
[20:59] <mdiggory> tdonohue: that would be why jschiefer work is valuable
[21:01] <hpottinger> maybe a whole "special topics" meeting for embargo, prior to the PR deadline?
[21:01] <mdiggory> and why well defined mechanisms to set embargo through ItemImport contents files, and METS Manifests for METS/AIP packagers will reduce occurance of this previous approach
[21:02] <tdonohue> mdiggory: I agree. Though I wouldn't want to hold up jschiefer's work by adding extra requirements to it. :) I suspect we may need to get a PR up which we can start to look at, and then decide what other "embargo fixes/improvements" can be made to compliment jschiefer's work
[21:02] <hpottinger> tdonohue++
[21:02] <mdiggory> tdonohue:++
[21:02] <tdonohue> +1 to hpottinger's idea of scheduling a special meeting around embargo as well
[21:03] <mhwood> Yes, I think it will be complementary. There should be one enforcer, not one per UI.
[21:03] <jschiefer> Well my deadline for school is next week, but I definitely willing to continue work on it to get it into an acceptable state for DSpace in general
[21:04] <tdonohue> jschiefer: I wouldn't worry about this larger discussion in terms of your deadline. Honestly your work looks good enough (at a glance) to be worth considering on its own. But, you are obviously welcome to continue with the larger discussions if it is of interest to you!
[21:04] <hpottinger> so, jschiefer, is submitting a PR for this work part of your assignment? :-)
[21:05] <tdonohue> jschiefer: but, I think most importantly here...it's great that your work has brought these larger issues to light (made them visible)...but we won't expect you to have to solve *all* these issues :) Every little bit helps!
[21:05] <mhwood> So you're giving us *two* gifts. Outstanding!
[21:05] <jschiefer> hpottinger: No, it's not a requirement but I'd like to contribute the work
[21:06] <hpottinger> that's awesome, jschiefer.
[21:06] <jschiefer> The end of the semester is near, so that is my deadline as far as school is concered :)
[21:06] <tdonohue> Thanks for that, jschiefer. We appreciate the contribution! Honestly, I wasn't even this active in open source software as an undergrad, so kudos to you!
[21:07] <tdonohue> If there's any other questions you all come up with, jschiefer & keithg, feel free to let us know.
[21:07] <mhwood> Sorry, I've got to go. 'bye, all.
[21:08] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:08] <tdonohue> I'm noticing though that our meeting has already gone a bit "overtime" (which is the norm most weeks).
[21:08] <jschiefer> What is the preferred way for me to continue this embargo discussion after this meeting?
[21:08] <hpottinger> boring details: since you've named your branch something other than a JIRA issue, I'm assuming that a JIRA issue does not yet exist for this work (no problem, we do it all the time), you should probably make a JIRA issue for it, describing the new feature, and rename the branch with the issue number
[21:08] <tdonohue> jschiefer: via the JIRA ticket and/or PR is actually great. Any updates to the JIRA ticket automatically email our "dspace-devel" (developer) mailing list. So that's a good way to contact us
[21:08] <jschiefer> Correct, that's on my "todo" list
[21:09] <jschiefer> tdonohue: Sounds good. I'll try to create the JIRA ticket this weekend
[21:10] <tdonohue> thanks. sounds good
[21:10] <keithg> thanks all. take care
[21:10] <tdonohue> Ok, with that, I'm going to close the meeting for today. We didn't have any other topics anyways, plus we are ~10mins over already. I'll be lurking around for a bit longer though if other informal topics come up
[21:10] * keithg (~keithgilb@2600:1003:b12c:3b70:60b6:5906:2c90:10e7) has left #duraspace
[21:11] <mdiggory> good meeting
[21:11] <tdonohue> thanks again jschiefer & Anja Le Blanc for sending in some good discussion topics!
[21:11] <hpottinger> mdiggory: any chance you all have some features you want to talk about?
[21:11] <jschiefer> Thanks, nice meeting you all
[21:12] * kstamatis (2ebe4bcb@gateway/web/freenode/ip.46.190.75.203) Quit (Quit: Page closed)
[21:12] <mdiggory> too many to keep track of ;-) hpottinger
[21:12] <hpottinger> i hear ya
[21:13] <hpottinger> though keep track of 'em we shall
[21:15] <mdiggory> Theres a bit of stuff hidden in the User Cases work we've been contributing to on the wiki
[21:15] <hpottinger> link for the record?
[21:15] <hpottinger> (gosh I'm naggy today, sorry)
[21:16] <mdiggory> the existing usecases (under tdonohue's leadership)
[21:16] <mdiggory> https://wiki.duraspace.org/display/DSPACE/Use+Cases
[21:16] <kompewter> [ Use Cases - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Use+Cases
[21:16] <mdiggory> theres a bunch of ORCID stuff in there
[21:17] <hpottinger> I see 'em
[21:18] <mdiggory> I also have a client project to support editable authority control
[21:18] <mdiggory> types, langs, authors, subjects, etc via UI
[21:18] * jschiefer (~jschiefer@nc6521fee.cns.vt.edu) has left #duraspace
[21:19] <tdonohue> Just as a sidenote, for anyone reading along...those "Use Cases" are still very rough / work in progress. We plan on doing a formal call (in next month or two, likely post-OR14) to community members to contribute more "use cases" which DSpace should strive to meet
[21:19] <hpottinger> tdonohue: I like the format of them
[21:19] <tdonohue> (Just don't want anyone to assume they've missed a "call for use cases"...it's still coming, once we get some rough ones in place)
[21:19] <mdiggory> DB driven property management is also something recently done for CSU….
[21:20] * jschiefer (~jschiefer@nc6521fee.cns.vt.edu) has joined #duraspace
[21:20] <tdonohue> hpottinger: admittedly, I "borrowed" a lot of the use case format stuff from the Fedora folks. They have a similar wiki page which they worked from during their Fedora 4 redesign
[21:20] <jschiefer> who should I talk to about setting up a JIRA account?
[21:20] <mdiggory> tdonohue: sorry if I jumped the gun by referencing that page
[21:21] <tdonohue> mdiggory: no problem. It's a public page. Just wanted to make sure there was "context" around it :)
[21:21] <hpottinger> JISC has a really cool use case interface (and it's my fault, tdonohue, I made mdiggory do it)
[21:21] <tdonohue> jschiefer: will send you a signup link shortly...we had to turn off self-signup cause of spammers
[21:21] <hpottinger> http://obd.jisc.ac.uk/navigate
[21:21] <kompewter> [ Navigate Use Cases | Open Bibliographic Data Guide ] - http://obd.jisc.ac.uk/navigate
[21:22] <jschiefer> tdonohue: thanks
[21:25] <hpottinger> I'm adding a link to that use case document on our internal wiki, I'm trying to come up with the attribution...
[21:26] <hpottinger> DSpace Steering Group or DSpace Vision Group?
[21:27] * jschiefer (~jschiefer@nc6521fee.cns.vt.edu) has left #duraspace
[21:27] <tdonohue> hpottinger: it's actually an ad-hoc group right now. It's just 6 of us, all DCAT or Committers. We were "charged" by the Steering Group, and I've been kinda calling us a "Tech Planning Group", but we don't really have a formal name, as it's a "temporary" group
[21:28] <hpottinger> "work in progress, by an informal "Tech Planning Group" charged by the DSpace Steering Group"
[21:29] <hpottinger> Steering Group or Steering Committee?
[21:29] <tdonohue> good enough. yea, I've just been hesitant to "name" this group, as there are already too many "named groups" floating around... :)
[21:29] <tdonohue> Steering Group
[21:30] <mdiggory> The JPF, not to be confused with the PFJ
[21:30] <hpottinger> :-)
[21:30] <tdonohue> (although 1/2 the time I end up calling them the Steering Committee myself...but, formally they are named the DSpace Steering Group)
[21:30] <hpottinger> "who's he, then?"
[21:32] <hpottinger> hey, mdiggory, just so I don't forget to mention it, thanks for stopping in today
[21:32] <mdiggory> thanks! I do miss it!
[21:32] <hpottinger> oh, and, do you have an opinion on other meeting times?
[21:33] <mdiggory> being on the west coast, anything before 9am is a bit tought o pull off
[22:00] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has left #duraspace
[22:07] * edInCo (~smuxi@seta.coalliance.org) Quit (Remote host closed the connection)
[22:13] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has left #duraspace
[22:20] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has joined #duraspace
[22:22] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has left #duraspace
[23:44] * mdiggory (~anonymous@cpe-76-176-128-229.san.res.rr.com) Quit (Quit: mdiggory)
[23:56] * jschiefer (~jschiefer@nc6521fee.cns.vt.edu) has joined #duraspace
[23:56] * jschiefer (~jschiefer@nc6521fee.cns.vt.edu) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.