Timestamps are in GMT/BST.
[4:37] * ogres (uid159312@gateway/web/irccloud.com/x-tewvfbagyjvobhpw) Quit (Quit: Connection closed for inactivity)
[5:44] * ivdl (~ivdl@146.232.125.245) has joined #duraspace
[6:29] -orwell.freenode.net- *** Looking up your hostname...
[6:29] -orwell.freenode.net- *** Checking Ident
[6:29] -orwell.freenode.net- *** Found your hostname
[6:29] -orwell.freenode.net- *** No Ident response
[6:29] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:29] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[6:29] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[6:32] * DSpaceSlackBot1 (~DSpaceSla@ec2-50-17-201-82.compute-1.amazonaws.com) Quit (Read error: Connection reset by peer)
[6:32] * DSpaceSlackBot (~DSpaceSla@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[6:45] * kompewter (~kompewter@50.17.201.82) Quit (Read error: Connection reset by peer)
[6:45] * DSpaceSlackBot (~DSpaceSla@ec2-50-17-201-82.compute-1.amazonaws.com) Quit (Read error: Connection reset by peer)
[7:00] * DSpaceSlackBot (~DSpaceSla@ec2-50-17-201-82.compute-1.amazonaws.com) has joined #duraspace
[10:23] * kompewter (~kompewter@50.17.201.82) has joined #duraspace
[10:41] * ivdl (~ivdl@146.232.125.245) Quit (Quit: WeeChat 1.4)
[10:41] * ivdl (~ivdl@146.232.125.245) has joined #duraspace
[10:46] * ivdl (~ivdl@146.232.125.245) Quit (Quit: WeeChat 1.4)
[11:54] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[15:54] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[19:50] <DSpaceSlackBot> <tdonohue> <here>: Reminder that our DSpace DevMtg is at the top of the hour (in about 10 mins). Agenda at https://wiki.duraspace.org/display/DSPACE/DevMtg+2018-07-18
[19:50] <kompewter> [ DevMtg 2018-07-18 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2018-07-18
[20:00] <DSpaceSlackBot> <tdonohue> <here>: It's DevMtg time. Let's do a quick roll call to see who's able to join us today
[20:00] <DSpaceSlackBot> <mwood> Here!
[20:00] <DSpaceSlackBot> <terrywbrady> Hello
[20:00] <DSpaceSlackBot> <jcreel256> Hello everybody
[20:01] <DSpaceSlackBot> <hpottinger> lurking, but oh so busy elsewhere, ping me if you need me
[20:01] <DSpaceSlackBot> <tdonohue> Ok, looks like the usual suspects...welcome all.
[20:02] <DSpaceSlackBot> <tdonohue> Agenda is a bit light today, but I pulled over some topics that came up from last week's mtg. First we'll do a couple quick notes/reminders
[20:03] <DSpaceSlackBot> <tdonohue> Next week, I'm out most of the week (at a DuraSpace staff mtg). I won't be at this meeting, but I know @terrywbrady and @pbecker wanted to lead a discussion on DSpace + Docker
[20:03] <DSpaceSlackBot> <tdonohue> This will be based on notes here: https://wiki.duraspace.org/display/DSPACE/DSpace+and+Docker
[20:03] <kompewter> [ DSpace and Docker - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+and+Docker
[20:03] <DSpaceSlackBot> <tdonohue> I'll obviously catch up on that discussion after I return, but look forward to seeing the notes
[20:04] <DSpaceSlackBot> <terrywbrady> @tdonohue, I plan to review some of the Dockerhub account options. If I discover that a paid plan would be useful for the project (for builds) would that be possible to support?
[20:04] <DSpaceSlackBot> <mwood> Maybe if you also discover some money....
[20:04] <DSpaceSlackBot> <tdonohue> @terrywbrady: we'd have to ask DSpace Steering (they control all DSpace funds). And currently a new Steering Group will be elected over the summer
[20:05] <DSpaceSlackBot> <tdonohue> So.... maybe....but it likely won't happen until a new Steering is in place & can discuss it
[20:05] <DSpaceSlackBot> <terrywbrady> If it looks like a good option, I will create a proposal. I hope to run it by the group in our meeting next week.
[20:06] <DSpaceSlackBot> <tdonohue> But, prior to that, we'd need details on how much this would cost, benefits to project, etc. Obviously those would be immediate questions from Steering. Definitely a proposal is best way to start here
[20:06] <DSpaceSlackBot> <tdonohue> Back to our agenda for today...
[20:06] <DSpaceSlackBot> <pbecker> hi
[20:07] <DSpaceSlackBot> <tdonohue> DSpace 7 Sprint #2 is ongoing this week. If you want to follow along, join us in dev-sprint channel. As always, we could use more code reviewers / testers on either side (Angular or REST/Java)
[20:08] <DSpaceSlackBot> <tdonohue> If you are interested, get in touch. On the REST side, we basically need help reviewing all the PRs tagged with "REST API v7": https://github.com/DSpace/DSpace/pulls?q=is%3Apr+is%3Aopen+label%3A%22REST+API+v7%22
[20:08] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Apr+is%3Aopen+label%3A%22REST+API+v7%22
[20:09] <DSpaceSlackBot> <tdonohue> On the Angular side, we are pretty good right now (everything in progress has at least one review)...but additional testing is always welcome: https://github.com/DSpace/dspace-angular/pulls
[20:09] <kompewter> [ Pull Requests · DSpace/dspace-angular · GitHub ] - https://github.com/DSpace/dspace-angular/pulls
[20:09] <DSpaceSlackBot> <tdonohue> No other major updates there. Tomorrow, there will be a DSpace 7 Mtg (in our normal 16UTC timeslot). That's both a Sprint #2 wrapup, and a planning session for work over summer / fall.
[20:09] <DSpaceSlackBot> <terrywbrady> I reviewed 2 of the REST blockers earlier today. Thanks for sharing the list of additional ones.
[20:10] <DSpaceSlackBot> <tdonohue> Err. that DSpace 7 Mtg is in our normal *14UTC* timeslot..my mistake ;)
[20:11] <DSpaceSlackBot> <tdonohue> I think that's it on the DSpace 7 side. The DSpace 7 Entities WG is still yet to be reestablished. We may touch on that tomorrow -- as I'm leaning towards reestablishing in late August. August is looking like a very slow month (many folks out) for DSpace 7
[20:12] <DSpaceSlackBot> <tdonohue> On to DSpace 6.x...
[20:13] <DSpaceSlackBot> <tdonohue> The only update there is that we still need help "porting" 6.3 bug fixes to `master`. The list is here: https://docs.google.com/spreadsheets/d/1X-Zk56gz-wg6p7JaiuBzzUquqOvwwx_-o_ZDDvGPSQU/edit?usp=sharing
[20:13] <kompewter> [ Closed for 6.3 but still need port to master (search JIRA for 63_PORT_TO_MASTER) - Google Sheets ] - https://docs.google.com/spreadsheets/d/1X-Zk56gz-wg6p7JaiuBzzUquqOvwwx_-o_ZDDvGPSQU/edit?usp=sharing
[20:13] <DSpaceSlackBot> <tdonohue> I've been hoping to get back to this myself, but haven't had a chance this week afterall.
[20:14] <DSpaceSlackBot> <tdonohue> Help/volunteers welcome. I know it's not glamorous work, but we should simply merge any ports quickly -- as long as the code is the same, and test pass, merge it.
[20:14] <DSpaceSlackBot> <tdonohue> That's it for 6.x and 7.x updates. Any questions / comments / suggestions on either of those?
[20:15] <DSpaceSlackBot> <pbecker> Did we planned to release a 6.4 soon? Was there a follow-up to one of the bug fixes in 6.3? Or did we ended up with noticing that all was resolved with those fixes?
[20:16] <DSpaceSlackBot> <tdonohue> We have no immediate plans for a 6.4. There was a followup issue noted to one of the security issues in 6.3 -- but we realized it was only actionable if you already have *full admin* rights in the system. So, it doesn't seem to warrant an immediate 6.4
[20:17] <DSpaceSlackBot> <tdonohue> I imagine there *will be* a 6.4 at some point, but there's plenty of other work to be done right now. So, 6.4 is waiting until it becomes a priority for someone
[20:19] <DSpaceSlackBot> <tdonohue> Not hearing any other questions. So, we now have time for discussion. I had noted/linked to a few discussion topics that came up last week about brainstorming "Plumbing" changes... see agenda topic #3
[20:19] <DSpaceSlackBot> <tdonohue> https://wiki.duraspace.org/display/DSPACE/DevMtg+2018-07-18
[20:19] <kompewter> [ DevMtg 2018-07-18 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2018-07-18
[20:19] <DSpaceSlackBot> <tdonohue> We don't necessarily have to discuss these specific topics today. If there are other issues/discussions folks want to bring up, that's fine.
[20:20] <DSpaceSlackBot> <tdonohue> So, anyone want to suggest a topic to discuss first here?
[20:20] <DSpaceSlackBot> <terrywbrady> I am delighted with the progress I have made with Docker images.
[20:20] <DSpaceSlackBot> <terrywbrady> I have 5 published images: https://hub.docker.com/r/dspace/dspace/tags/
[20:20] <kompewter> [ None ] - https://hub.docker.com/r/dspace/dspace/tags/
[20:20] <DSpaceSlackBot> <tdonohue> I'm looking forward to trying Docker at some point :slightly_smiling_face:
[20:21] <DSpaceSlackBot> <pbecker> @tdonohue it’s a good time to go ahead with this plan
[20:21] <DSpaceSlackBot> <terrywbrady> And some compose files that make it easy to launch an instance.
[20:21] <DSpaceSlackBot> <terrywbrady> Next, I want to perform some PR testing through Docker to see if that generates any additional ideas for tools to share.
[20:22] <DSpaceSlackBot> <tdonohue> This looks great. I have to ask (and likely the answer is "not yet"), but is there a Docker image for DSpace 7 (Angular + REST) in the works?
[20:23] <DSpaceSlackBot> <tdonohue> I think it's awesome that you have one for all supported versions! 4.9, 5.9, 6.3
[20:23] <DSpaceSlackBot> <terrywbrady> I hope to create that as well (unless someone else creates it first).
[20:25] <DSpaceSlackBot> <tdonohue> So, here's a question for you all. Is there a way to better bring all of you into DSpace 7 discussions (I know some of you are lurkers...we just could use more "active" participants)? Any thoughts on how to make that step from this meeting...to Sprints / DSpace 7 meetings?
[20:25] <DSpaceSlackBot> <tdonohue> Is there anything you could use to help out? Anything we aren't doing but should be?
[20:26] <DSpaceSlackBot> <terrywbrady> Sprint 1 was helpful for me to feel connected to the DSpace 7 effort.
[20:27] <DSpaceSlackBot> <mwood> Just this morning I went looking for "how to introduce a new concept to dspace-spring-rest" and didn't find anything. There's a slide deck from OR that shows modifying the EPerson endpoint, but nothing for new construction.
[20:27] <DSpaceSlackBot> <pbecker> There is a docker imapge for angular already (https://github.com/DSpace-Labs/DSpace-Docker-Images/tree/master/dockerfiles/dspace-angular-dev). It uses the REST demo endpoint from 4Science.
[20:28] <DSpaceSlackBot> <tdonohue> @mwood: could we talk more about that? By a "new concept" do you mean you want to help add in a new endpoint/feature? Or you have an existing feature in mind but not sure where to start in designing/implementing?
[20:28] <DSpaceSlackBot> <tdonohue> Just trying to understand exactly what you are looking for in docs/guidance
[20:29] <DSpaceSlackBot> <terrywbrady> Fyi, the following exists for the REST code: https://dspace-labs.github.io/DSpace7RestTutorial/walkthrough/intro
[20:29] <kompewter> [ DSpace 7 REST Code Walkthrough | DSpace 7 REST API Tutorial ] - https://dspace-labs.github.io/DSpace7RestTutorial/walkthrough/intro
[20:30] <DSpaceSlackBot> <mwood> Specifically: we've found a use for Request Copy, I noticed that it's not in REST yet, I wrote a Jira issue for it, nobody's commented, so I thought I'd try implementing it.
[20:30] <DSpaceSlackBot> <mwood> @terrywbrady that looks useful. Thanks!
[20:32] <DSpaceSlackBot> <tdonohue> @mwood: aha, ok. I see. Well, the normal process is..(1) claim the ticket (2) craft some (rough) ideas on it (ask for feedback, and even join a mtg and ask directly) (3) draft up what the REST Contract might look like (as for more feedback), then (4) start implementing
[20:32] <DSpaceSlackBot> <tdonohue> For Sprints, we often do steps 1-3 ourselves...and only ask participants to do #4.
[20:33] <DSpaceSlackBot> <tdonohue> But, if we haven't gotten to that topic yet...there's more of a gap, and more opportunity to help shape what that'd look like
[20:33] <DSpaceSlackBot> <terrywbrady> Is there a place for Request a Copy in the REST contract? https://github.com/DSpace/Rest7Contract/ If not, it might also be useful to start a PR against the contract.
[20:33] <kompewter> [ GitHub - DSpace/Rest7Contract: Repository to discuss the new REST API contract for DSpace 7 https://wiki.duraspace.org/display/DSPACE/DSpace+7+UI+Working+Group ] - https://github.com/DSpace/Rest7Contract/
[20:34] <DSpaceSlackBot> <tdonohue> It's not in the contract yet, no. So, a REST Contact PR could be a good place to start brainstorming
[20:34] <DSpaceSlackBot> <mwood> OK, separate PR for the contract.
[20:35] <DSpaceSlackBot> <tdonohue> Yes, ideally, we try to draft the contract first. It's almost never perfect (and usually needs updates to bring it back in line with the final implementation). But, it gives us something to discuss as a sort of "proposal"
[20:35] <DSpaceSlackBot> <mwood> If I succeed in building something, I hope to be able to write the beginning of what I wanted to read.
[20:35] <DSpaceSlackBot> <terrywbrady> @mwood that was my inspiration for the walkthrough documentation!
[20:36] <DSpaceSlackBot> <mwood> It happens a lot. :-/
[20:37] <DSpaceSlackBot> <tdonohue> This sounds like a good way to "get your feet wet" a bit in DSpace 7, @mwood. I'd just suggest that you keep asking questions (especially in Slack or in DSpace 7 Mtgs). If you also find gaps in docs/tutorial, it's an opportunity for us to fix it for others
[20:37] <DSpaceSlackBot> <mwood> Will do. I just added "PR to the REST Contract" to my personal 'spring-rest.howto'
[20:38] <DSpaceSlackBot> <tdonohue> And maybe this should be a new section to the Tutorial (How to get Started in Contributing)...if it isn't there already in some form
[20:39] <DSpaceSlackBot> <tdonohue> So, I'll also note that we obviously will be having a Sprint #3. No specific dates yet, but I expect it'd be September sometime. I'll keep you all posted, as that's another way to dive in
[20:40] <DSpaceSlackBot> <terrywbrady> Not yet. https://dspace-labs.github.io/DSpace7RestTutorial/walkthrough/next-steps Pull requests are welcome for the tutorial pages.
[20:40] <kompewter> [ DSpace 7 REST API Tutorial | Learn the new interface for DSpace Client Apps ] - https://dspace-labs.github.io/DSpace7RestTutorial/walkthrough/next-steps
[20:40] <DSpaceSlackBot> <tdonohue> So, if no one else has other topics pressing in their mind...I have another (very rough) idea to run by folks.
[20:41] <DSpaceSlackBot> <mwood> Well, I did want some opinions on the bulk operations topic.
[20:41] <DSpaceSlackBot> <tdonohue> Ok, we can go to that if you want, first, @mwood.
[20:42] <DSpaceSlackBot> <tdonohue> This is Topic #3 a in the agenda
[20:44] <DSpaceSlackBot> <mwood> The storage layer has good interfaces for operating on single objects, clumps of related objects, and small batches, but can be troublesome if you have half a million objects that all need the same treatment. I suggest that, for bulk operations, the storage layer should drive the process, which it can do efficiently, and business logic can pass in an object which performs the bulk operation on a single instanc
[20:44] <DSpaceSlackBot> <tdonohue> Just a clarification, I realized just now... by "storage layer", are you talking *specifically* just the bitstream storage? Or are you including database bulk operations here too?
[20:45] <DSpaceSlackBot> <mwood> I'm actually talking about the database.
[20:45] <DSpaceSlackBot> <pbecker> I just read about the bulk operation topic in the agenda of today’s meeting. I especially like the direction of the point “so that business logic doesn’t need to know so much about the storage layer”.
[20:45] <DSpaceSlackBot> <tdonohue> Ok, we need to clarify that in the proposal. I read this initially as *bitstream storage*
[20:46] <DSpaceSlackBot> <mwood> Sorry, bitstreams and database are both under org.dspace.storage....
[20:46] <DSpaceSlackBot> <pbecker> @tdonohue I think @mwood is talking about the need to use context.setMode if you do a batch operation and the need to use context.uncacheentity.
[20:47] <DSpaceSlackBot> <tdonohue> Yes, and the bitstream layer is called "StorageService"....which is why I thought you meant that ;)
[20:47] <DSpaceSlackBot> <tdonohue> But, I now understand what you are talking about
[20:47] <DSpaceSlackBot> <pbecker> especially uncachEntity is hard to debug and often makes problems. But there are a lot of batch operations you cannot run without it.
[20:48] <DSpaceSlackBot> <pbecker> @mwood am I right? is that what you have in mind?
[20:48] <DSpaceSlackBot> <mwood> Anyway: what we mostly have is ways to get the database to return lists of things that match queries. When the query matches a million things, we have long-running transactions and hold a lot of objects which are only used briefly and then discarded.
[20:49] <DSpaceSlackBot> <mwood> Yes, @pbecker that is the sort of problem I had in mind. That, and the memory pressure of huge result sets.
[20:50] <DSpaceSlackBot> <tdonohue> Ok, so this is almost an extension of the problems/confusion we started documenting here: https://wiki.duraspace.org/display/DSPACE/DSpace+Database+Access (These docs are not complete though...there's a lot of gaps, but there's places for notes on "Batch Context" and "uncache entity", etc.
[20:50] <kompewter> [ DSpace Database Access - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Database+Access
[20:51] <DSpaceSlackBot> <mwood> Imagine being able to handle the uncaching in *one place*.
[20:52] <DSpaceSlackBot> <terrywbrady> @mwood, what is a sample query that you are running to initiate such a process?
[20:52] <DSpaceSlackBot> <terrywbrady> (an explanation, not SQL)
[20:53] <DSpaceSlackBot> <mwood> I'd have to look up the query. The inspiration was from a discussion of someone's need to run checksum calculations over a large repository, which was eating up enormous amounts of memory.
[20:53] <DSpaceSlackBot> <tdonohue> I think this is a good topic to be discussing...but, yes, it'd be good to understand the brainstorm/proposal here. I think there's still a lot of confusion about how to do this "best" within Hibernate, and I expect that we aren't doing it most efficiently right now.
[20:54] <DSpaceSlackBot> <mwood> But it's probably whatever query you would find in ItemService.findAll
[20:54] <DSpaceSlackBot> <mwood> Oops, BitstreamService.findAll.
[20:54] <DSpaceSlackBot> <tdonohue> And I'm not sure if this is solely about batch processing...or more generally about "memory/Context management" in Hibernate (which is mostly a pain during batch processing)
[20:55] <DSpaceSlackBot> <pbecker> @mwood Do I understand correctly: you’re suggesting a method that gets a call back and a list and runs the call back on every entry in the list, is handling the context mode and the cache on its own?
[20:55] <DSpaceSlackBot> <terrywbrady> This is similar to the types of iteration that are done in the Curation system except that the iteration is happening over the bitstream objects.
[20:55] <DSpaceSlackBot> <pbecker> So the call back must not keep any references between each run. right?
[20:55] <DSpaceSlackBot> <mwood> Yes, except that Hibernate provides the "list" in response to a query.
[20:56] <DSpaceSlackBot> <mwood> Right, it should operate on one list element and be finished.
[20:57] <DSpaceSlackBot> <pbecker> @terrywbrady we actually had these problems with curation tasks (see https://github.com/DSpace/DSpace/pull/1892)
[20:57] <DSpaceSlackBot> <tdonohue> @mwood: it sounds to me like you have some pretty specific ideas/brainstorms. I'm still not sure I'm fully grasping the idea. Is there a chance you could write these up in more detail in some way? This sounds interesting, just not sure I get the idea
[20:58] <DSpaceSlackBot> <tdonohue> And I'm also not sure if what you are talking about is an API layer change, or tweaks to Hibernate settings, or both?
[20:58] <DSpaceSlackBot> <mwood> I will try to write up something. Thanks, everyone, for the discussion so far.
[20:59] <DSpaceSlackBot> <tdonohue> FWIW, Hibernate itself also does have some Batch processing recommendations: https://docs.jboss.org/hibernate/orm/3.3/reference/en-US/html/batch.html And based on these, I think we have a BATCH_EDIT mode in Context object
[20:59] <kompewter> [ Chapter 13. Batch processing ] - https://docs.jboss.org/hibernate/orm/3.3/reference/en-US/html/batch.html
[20:59] <DSpaceSlackBot> <tdonohue> (Just noting those for reference...I'm not saying those solve this problem, likely they don't)
[21:00] <DSpaceSlackBot> <mwood> I think that these methods would use Hibernate differently but might not require different settings. Basically: how would we do things differently when we know that we don't need the list, only each element in turn.
[21:00] <DSpaceSlackBot> <pbecker> Is this more than some kind of helper method that deals with the mode, loads an object from the list, runs the callback and uncaches the object?
[21:00] <DSpaceSlackBot> <mwood> Perhaps so.
[21:00] <DSpaceSlackBot> <tdonohue> It would be nice to *not* have to worry about remembering to uncache or reload objects, etc
[21:01] <DSpaceSlackBot> <tdonohue> (i.e. if that did happen all in one place)
[21:01] <DSpaceSlackBot> <pbecker> I’m interested to see what you will come up with it.
[21:01] <DSpaceSlackBot> <pbecker> I think it might get complicated, if a helper method uses several objects from several lists combined in a specific order.
[21:01] <DSpaceSlackBot> <pbecker> Or maybe loads the owning community to an item from a list. And so on…
[21:02] <DSpaceSlackBot> <mwood> I think I have what I wanted for now. Nobody has said, "oh, that obviously won't work because [something I didn't understand about ORM]"
[21:02] <DSpaceSlackBot> <tdonohue> Sounds good, @mwood. Let us know how it goes, and definitely come back when you have more info/ideas/etc
[21:02] <DSpaceSlackBot> <mwood> Will do. Thanks again, all!
[21:03] <DSpaceSlackBot> <pbecker> :slightly_smiling_face:
[21:03] <DSpaceSlackBot> <tdonohue> So, I'm realizing we are now over time here. So, I'm going to wrap up today's meeting. I won't see you next week, but the DevMtg is still happening at 15UTC on July 25
[21:03] <DSpaceSlackBot> <tdonohue> And I look forward to reading the discussion on Docker out of that meeting!
[21:04] <DSpaceSlackBot> <tdonohue> Have a good one, all!
[21:04] <DSpaceSlackBot> <terrywbrady> Have a good vacation!
[21:04] <DSpaceSlackBot> <pbecker> good bye everyone!
[21:05] <DSpaceSlackBot> <mwood> @terrywbrady sorry I took up all the time and we didn't get to curation issues. And that we didn't hear @tdonohue’s topic yet.
[21:07] <DSpaceSlackBot> <terrywbrady> No worries @mwood. I will bring up the curation idea as a possible solution when we get there. I have had some of these ideas for years, so they can wait for another meeting.
[21:07] <DSpaceSlackBot> <tdonohue> My topic was a very rough brainstorm on finding better ways to encourage Code Reviews of PRs (we have 141 open PRs). I was playing with establishing a "Code Review" team or some way to encourage folks to help out & also to specifically credit their work.
[21:08] <DSpaceSlackBot> <tdonohue> It's a very rough idea though, and I'll add it as a future agenda topic. Feel free to brainstorm on your own on ways we can improve code reviews / PR backlogs in the meantime
[21:09] <DSpaceSlackBot> <mwood> OK, 'bye all.
[21:09] * mhwood (~mhwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:14] * tdonohue (~tdonohue@dspace/tdonohue) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.