Timestamps are in GMT/BST.
[4:23] * misilot_ (~misilot@p-body.lib.fit.edu) has joined #duraspace
[4:29] * misilot (~misilot@p-body.lib.fit.edu) Quit (*.net *.split)
[6:38] -karatkievich.freenode.net- *** Looking up your hostname...
[6:38] -karatkievich.freenode.net- *** Checking Ident
[6:38] -karatkievich.freenode.net- *** Found your hostname
[6:38] -karatkievich.freenode.net- *** No Ident response
[6:39] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:39] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[6:39] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[12:23] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:00] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[15:06] * AlexS[zedat] (~Alexander@home.zedat.fu-berlin.de) Quit (Ping timeout: 240 seconds)
[15:11] * AlexS[zedat] (~Alexander@home.zedat.fu-berlin.de) has joined #duraspace
[19:59] <DSpaceSlackBot> <tdonohue> <here>: (Late) Reminder that our DSpace DevMtg starts momentarily. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-09-27
[20:00] <DSpaceSlackBot> <terrywbrady> hello
[20:00] <DSpaceSlackBot> <tdonohue> Hi all, so, it's DevMtg time (per message above).
[20:01] <DSpaceSlackBot> <mwood> [waves]
[20:02] <DSpaceSlackBot> <tom_desair> hi
[20:02] <DSpaceSlackBot> <tdonohue> To kick things off today, I'd like to congratulate @pbecker (who just had to leave) and others on what sounded like a very successful DSpace German User Group last week! :clap:
[20:02] <DSpaceSlackBot> <tdonohue> @pbecker has also posted the talks/presentations (most of which are in German though) up at https://wiki.duraspace.org/display/DSPACE/DSpace+Anwendertreffen+2017
[20:02] <DSpaceSlackBot> <tom_desair> Too bad I couldn’t be there.
[20:04] <DSpaceSlackBot> <tdonohue> Also, because Pascal (I'm going to stop pinging him now) isn't able to attend this meeting, I've rescheduled the DOI field discussion for *next week* (agenda item #2)
[20:04] <DSpaceSlackBot> <tdonohue> Pascal will be here next week, and we can discuss DOIs then (Oct 4 @ 15UTC)
[20:05] <DSpaceSlackBot> <tdonohue> So, that rapidly brings us to #3 on the agenda... which is @terrywbrady's recent work on DSpace 6 + Codenvy: https://github.com/terrywbrady/dspace-on-codenvy/blob/master/README.md
[20:05] <DSpaceSlackBot> <tdonohue> @terrywbrady would you like to talk about this in a bit more detail?
[20:05] <DSpaceSlackBot> <terrywbrady> I am intrigued by what Codenvy seems to offer.
[20:06] <DSpaceSlackBot> <terrywbrady> In the tab of a browser you can edit code on a server, launch terminal commands, and serve up an instance of DSpace.
[20:07] <DSpaceSlackBot> <terrywbrady> I am curious if this could provide a ready-made solution for onboarding new developers to the platform
[20:07] <DSpaceSlackBot> <terrywbrady> Here is my running instance: http://node14.codenvy.io:46012/xmlui/
[20:08] <DSpaceSlackBot> <terrywbrady> I do not yet have a good handle on the limitations of the platform or the actual cost of using it for real work. I am curious to hear reactions from folks to the documentation and screenshots that I posted.
[20:08] <DSpaceSlackBot> <tom_desair> Especially if you combine it with “Workspace Factories” which allow you to generate a link that will deliver a pre-configured development workspace for any developer (in their own account). You can do something like “To start contributing now, click this link”.
[20:09] <DSpaceSlackBot> <terrywbrady> @tom_desair, can you make use of factories without purchasing a team plan?
[20:09] <DSpaceSlackBot> <mwood> Aha, that is what makes it different from "download, unpack, start hacking."
[20:09] <DSpaceSlackBot> <terrywbrady> Are you using a paid plan?
[20:09] <DSpaceSlackBot> <tom_desair> I’m using the free version
[20:10] <DSpaceSlackBot> <terrywbrady> The servers shutdown after X min of inactivity. In the free tier, that is 10 min which is way too short for doing concentrated work. I purchased a plan for this month to support a presentation that I gave.
[20:11] <DSpaceSlackBot> <terrywbrady> It provided a 4 hour window.
[20:11] <DSpaceSlackBot> <tdonohue> It definitely sounds interesting/useful. But, yes the shutdown after 10mins of inactivity seems like it could be annoying, unless spinning back up can be made pretty "seamless" (automated)
[20:12] <DSpaceSlackBot> <tdonohue> Still, I like the idea for new developers and/or possibly joint debugging of issues
[20:12] <DSpaceSlackBot> <tom_desair> I think it also offers powerful possibilities to test pull-requests. The pre-configured workspace could offer a script that pulls, builds and launches a PR of your choosing so you can easily test it. But then we also need to load some demo data.
[20:12] <DSpaceSlackBot> <mwood> What's the transition like when you get to "it works -- now we need to run it on our own iron"?
[20:13] <DSpaceSlackBot> <tdonohue> @tom_desair: If this could be used to test PRs (again in an automated way), that would be awesome. Even if you had to add in your own content initially
[20:14] <DSpaceSlackBot> <terrywbrady> @mwood There is an option to host the platform locally, but I think you would likely deploy the code to your own environment
[20:14] <DSpaceSlackBot> <mwood> Hmm. The difficult parts of PR testing for me are (a) content and (b) understanding what success and failure look like.
[20:15] <DSpaceSlackBot> <mwood> @terrywbrady I worry that we are just moving the hump in the learning curve from the beginning to the middle.
[20:15] <DSpaceSlackBot> <terrywbrady> One nice thing about using it for testing is that once you have configured code and data, it is easy to share an instance.
[20:16] <DSpaceSlackBot> <terrywbrady> @mwood that is a good concern to raise. I am not far enough into my evaluation to know.
[20:17] <DSpaceSlackBot> <terrywbrady> I keep presuming that every challenge would be easy to overcome if I understood Dockerfiles better :slightly_smiling_face:
[20:17] <DSpaceSlackBot> <terrywbrady> @tom_desair do you imagine using it in your current work?
[20:17] <DSpaceSlackBot> <tdonohue> I think the biggest sticking point is making this "automated". It looks like much of it is, but there's still a lot of "post-Docker" steps here: https://github.com/terrywbrady/dspace-on-codenvy/blob/master/README.md#post-docker-setup-tasks
[20:17] <DSpaceSlackBot> <mwood> Disclosure: I'm an old fossil and have a reflexive distrust of Cloud-[whatever].
[20:18] <DSpaceSlackBot> <tom_desair> For smaller development tasks you could use it. But once I have to do more coding, I think I would miss my IDE features. The browser is not always that responsive.
[20:19] <DSpaceSlackBot> <terrywbrady> @tdonohue some of that is definitely due to my inexperience with docker... but I am uncertain that it will be as automated as we hope.
[20:19] <DSpaceSlackBot> <terrywbrady> I was imagining it being particularly useful for trainings, hackathons, etc.
[20:20] <DSpaceSlackBot> <mwood> The IDE point is a good one. Java might have been designed with IDEs in mind, and tends to produce code that encourages leaning heavily on one.
[20:20] <DSpaceSlackBot> <terrywbrady> I might also choose to use it when I want feedback on a feature and need to expose an instance outside of our campus firewall
[20:21] <DSpaceSlackBot> <tom_desair> I think it is a good thing indeed to get people acquainted with DSpace development. But once you want to contribute more or do more complex development, you’ll have to setup your local development machine.
[20:21] <DSpaceSlackBot> <tdonohue> I still do think it's useful (as you mentioned, @terrywbrady). Just seems like a tool that could be even more useful if we can get others to chip in & help try and automate it more (via Docker). Automation is where it becomes easier to hand to a newbie and/or test PRs with it.
[20:21] <DSpaceSlackBot> <terrywbrady> My other hope was to find a way to support cloud instances of our active branches, but I am not sure Codenvy would be the right platform for a persistent test instance.
[20:22] <DSpaceSlackBot> <mwood> Yes, it's very good to have a low-setup option for *events*, but another environment might be better for extended development.
[20:22] <DSpaceSlackBot> <tdonohue> No, likely not as good for a persistent test instance. But, I could see it useful to test individual PRs (if we found a way to automate it and pass it a branch to spin up.
[20:23] <DSpaceSlackBot> <terrywbrady> If we identify someone with interest and with docker knowledge who would like to work with me, I will take this further and document the results.
[20:24] <DSpaceSlackBot> <terrywbrady> @tdonohue @mwood @tom_desair how easy is it for you to provide other developers with a URL to your dev instances?
[20:24] <DSpaceSlackBot> <terrywbrady> (another developer outside of your org)
[20:24] <DSpaceSlackBot> <pbecker> Is it possible to Code together using the same codenvy instance?
[20:24] <DSpaceSlackBot> <mwood> I'd have to check my host firewall.
[20:24] <DSpaceSlackBot> <tdonohue> These days, I don't have a "dev" instance other than vagrant-dspace ;)
[20:25] <DSpaceSlackBot> <terrywbrady> @pbecker there is a team option. It has a different cost structure that I do not fully understand
[20:25] <DSpaceSlackBot> <terrywbrady> I was also intrigued at the thought of collaborating on a shared instance.
[20:26] <DSpaceSlackBot> <tdonohue> https://codenvy.com/product/index.php#pricing (Seems to imply teams of 3 are free)
[20:26] <DSpaceSlackBot> <mwood> Like virtual pair programming: "here, you drive for a while and I'll kibitz."
[20:26] <DSpaceSlackBot> <terrywbrady> For the team option, you pay per team member and per compute resources. Those resources are shared.
[20:26] <DSpaceSlackBot> <terrywbrady> I do not know the extent of the team/collab features.
[20:27] <DSpaceSlackBot> <terrywbrady> The vendor has not been very responsive to my questions.
[20:27] <DSpaceSlackBot> <terrywbrady> We can move on to the next agenda item if you like.
[20:27] <DSpaceSlackBot> <tdonohue> I think this has been a good intro and given us some topics to think about here
[20:27] <DSpaceSlackBot> <tom_desair> @terrywbrady I’m willing to help with creating the Docker images
[20:28] <DSpaceSlackBot> <terrywbrady> Thanks @tom_desair. could we build up a DSpace 6 docker image and workspace factory?
[20:28] <DSpaceSlackBot> <mwood> I'm taking a 2-hr Docker training next month. Who knows, I might become an enthusiast.
[20:29] <DSpaceSlackBot> <terrywbrady> @mwood you will be coding with a chromebook in no time
[20:29] <DSpaceSlackBot> <tom_desair> I’ll see if I can build something next week
[20:29] <DSpaceSlackBot> <terrywbrady> Thanks!
[20:30] <DSpaceSlackBot> <tdonohue> I'll admit, the remainder of our agenda is "light" today. We have one "ongoing discussion topic" (around mgmt of database connections for DSpace 7 and beyond). Or we could discuss whatever else is if interest to those in attendance today. Thoughts?
[20:31] <DSpaceSlackBot> <tdonohue> No one has any interests / topics today, it seems :slightly_smiling_face:
[20:31] <DSpaceSlackBot> <pbecker> One question: did we decided about support of other RDBMS?
[20:32] <DSpaceSlackBot> <pbecker> I have in mind there was some proposition of adding support for mssql and maybe mysql/mariadb.
[20:32] <DSpaceSlackBot> <tdonohue> @pbecker: we decided to let the ticket sit until it "gained momentum" (i.e. requests). It's very unclear what other RDBMSes are of interest...and (more importantly) who would help support them
[20:32] <DSpaceSlackBot> <mwood> I recall that the response was tepid. There is the difficulty of finding people who can do ongoing support for each "supported" brand.
[20:33] <DSpaceSlackBot> <pbecker> I think TU Berlin is interested in MSSQL.
[20:33] <DSpaceSlackBot> <tdonohue> To be clear, even with our move to Hibernate, there is a lot of work in "supporting" any new RDBMS (primarily in the area of building/testing/debugging Flyway migrations)
[20:34] <DSpaceSlackBot> <terrywbrady> @pbecker, what is the driving interest in sqlserver?
[20:34] <DSpaceSlackBot> <tdonohue> So, without groups/people stepping forward with support, we had concerns that we'd end up with another Oracle. It's currently unclear how many sites use Oracle, and very few of us know enough to support it well.
[20:34] <DSpaceSlackBot> <pbecker> I'm not sure about my personal opinion as I already don't like to support oracle. ;)
[20:34] <DSpaceSlackBot> <terrywbrady> I think @hpottinger raised the interest in mysql
[20:34] <DSpaceSlackBot> <mwood> Any changes that change the use of the database have to be tested on N flavors.
[20:35] <DSpaceSlackBot> <mwood> Heh, I do some of the Oracle support and we don't use it at all.
[20:35] <DSpaceSlackBot> <tdonohue> And any PRs that change the database would have to have migrations that "work" on N flavors
[20:35] <DSpaceSlackBot> <pbecker> @terrywbrady our admins support MSSQL and some strange other RDBMS but neither Postgres, oracle or mysql.
[20:36] <DSpaceSlackBot> <pbecker> @mwood same here
[20:36] <DSpaceSlackBot> <pbecker> I think that is enough for me to answer the question. Thanks
[20:37] <DSpaceSlackBot> <terrywbrady> Fortunately DSpace does not seem to require active DBA support in order to run efficiently
[20:37] <DSpaceSlackBot> <mwood> I don't know about *efficiently*. "Well enough," yes.
[20:38] <DSpaceSlackBot> <pbecker> I'm more concerned about bitsream metadata and versioning currently. SCNR
[20:38] <DSpaceSlackBot> <tdonohue> I think this will definitely be an ongoing question. I just suspect it'd require a few larger institutions coming forward and saying "we want ___ RDBMS support, and we'll help maintain/support it for the community". Otherwise, we're just creating more work for ourselves
[20:38] <DSpaceSlackBot> <tom_desair> I think that for DSpace 8, we have to move to a “plug-in” system for DSpace. It would also solve a lot of the open PR discussions. That way we would have a DSpace core installation which is supported by the community and “vendor-neutral”. Any vendor specific functionality (MS-SQL, DataCite, Elsevier …) should go into a plugin (maintained by a subcommunity or by a service provider). That way the �
[20:38] <DSpaceSlackBot> people are freely to add (exotic) functionality by releasing a plugin for it.
[20:39] <DSpaceSlackBot> <pbecker> DataCite?
[20:39] <DSpaceSlackBot> <tom_desair> Yeah, it’s hard to test if you don’t have a DataCite account ;)
[20:40] <DSpaceSlackBot> <pbecker> There is a free account to be used by any DSpace developer. Credentials are in the wiki.
[20:40] <DSpaceSlackBot> <tdonohue> @tom_desair: it's a good idea (and one that's been mentioned many times before), provided it's still very "out-of-the-box" (i.e. like a Wordpress plugin system)
[20:40] <DSpaceSlackBot> <mwood> EZID has a test instance. I suppose that DataCite has one, or will have when they finish absorbing EZID.
[20:41] <DSpaceSlackBot> <mwood> More/easier modularity is good.
[20:41] <DSpaceSlackBot> <pbecker> They have.
[20:41] <DSpaceSlackBot> <pbecker> Cannot look up right now where i documented it, but it is in the wiki somewhere
[20:42] <DSpaceSlackBot> <tom_desair> I know, but I didn’t know about the DSpace account. But it’s just an example of functionality that could be a “vendor” specific plugin.
[20:42] <DSpaceSlackBot> <tom_desair> We’ve also done some work for CrossRef DOI's
[20:42] <DSpaceSlackBot> <tdonohue> Yes, modularity / plugin models are in our Strategic Goals (for 2015-18). Not sure we'll achieve them by 2018 though, but we should concentrate there after DSpace 7. https://wiki.duraspace.org/display/DSPACE/DSpace+2015-18+Strategic+Plan#DSpace2015-18StrategicPlan-TechnologyGoals
[20:42] <DSpaceSlackBot> <tom_desair> but that would be “another vendor” to support.
[20:43] <DSpaceSlackBot> <mwood> DOI support is in good condition to be "plugged out" as a separate project, if we do some work on packaging to make it easy to plug in.
[20:43] <DSpaceSlackBot> <tom_desair> Jira has plugins and is written in Java (I think). So it’s not impossible ;)
[20:44] <DSpaceSlackBot> <pbecker> I'd love to see those (CrossRef) things coming back to DSpace official versions.
[20:44] <DSpaceSlackBot> <mwood> That reminded me to worry about the modularity of the New UI....
[20:44] <DSpaceSlackBot> <tdonohue> Yes, JIRA is in Java. It's plugins are very hit or miss at times. But, that's not a fault of the model, which is a good one
[20:45] <DSpaceSlackBot> <mwood> One thing we'll need to do, I think, is sort out ServiceManager vs. PluginManager.
[20:45] <DSpaceSlackBot> <tom_desair> Yes just like Wordpress there will be a lot of unmaintained “garbage” plugins.
[20:46] <DSpaceSlackBot> <tdonohue> I think the challenge here will be balancing "out of the box" with enabling "third-party plugins". Those are sometimes opposing ideas. But, JIRA is decent at it...Wordpress is as well.
[20:46] <DSpaceSlackBot> <tom_desair> IMO the plugin system should be the next focus point after the new UI. And we should indeed make sure that the new UI doesn’t make introducing a plugin system harder.
[20:46] <DSpaceSlackBot> <mwood> Well, a few plugins will be "in the box."
[20:46] <DSpaceSlackBot> <tdonohue> @mwood: you mentioned worrying about modularity of the new UI. Did you have a specific worry/question there?
[20:47] <DSpaceSlackBot> <mwood> No, just generally how much of the code do I have to understand in order to stick a new feature on the page, that sort of thing.
[20:47] <DSpaceSlackBot> <mwood> Like: can my plugin include plugging new UI features in?
[20:48] <DSpaceSlackBot> <tdonohue> I'll note one of the reasons behind choosing Angular was its "modularity". It's also the reason we're building a REST API that uses HAL format to be "self-describing"...as if a module is "uninstalled" the REST API can stop describing that endpoint, and the UI can then disable views/links to that endpoint
[20:48] <DSpaceSlackBot> <mwood> Theoretically XMLUI makes that easy. In practice I spend a lot of time trying to figure out which XSL file things are in.
[20:49] <DSpaceSlackBot> <tdonohue> So, the entire concept of DSpace 7 is to have a UI & REST API that can "act" in a modular fashion. Whether we are doing it all "right" is yet to be proven (and we'd love feedback on it), but that's the intention.
[20:49] <DSpaceSlackBot> <mwood> My concern is more in the other direction: if the stock UI doesn't know about my feature, how can I just drop it in?
[20:51] <DSpaceSlackBot> <pbecker> I like the plugin idea.
[20:51] <DSpaceSlackBot> <tdonohue> @mwood: Your feature would likely have to include UI components (packaged in an Angular Module) that understood that extra REST API endpoint/data. So, it may require "dropping in" a JAR (for REST API endpoints) *and* and Angular module.
[20:51] <DSpaceSlackBot> <mwood> I'll have to try it and see what problems I run into.
[20:51] <DSpaceSlackBot> <tdonohue> @mwood: that said, there may be ways to make that "easier". that's just and off-the-top-of-my-head answer
[20:51] <DSpaceSlackBot> <pbecker> But I'd like think we need to keep the data model and the hierarchical metadata feature in mind.
[20:52] <DSpaceSlackBot> <tdonohue> Yes those are both very high priority as well
[20:53] <DSpaceSlackBot> <tom_desair> The DSpace 7 submission mockups already showed some hierarchical metadata features I think.
[20:53] <DSpaceSlackBot> <tdonohue> I don't know that DSpace 8 would be limited to necessary one big new feature (depends on resources and/or user needs). The three I've heard mentioned most frequently though are data model, hierarchical metadata, and plugins.
[20:54] <DSpaceSlackBot> <tdonohue> @tom_desair: those mockups are inaccurate slightly (working on them). That won't be in DSpace 7...but is more an "idea" for a possible future release
[20:54] <DSpaceSlackBot> <mwood> Presumably we want to get back to yearly releases, so we'd have to estimate how much of that work (and other stuff) we could get done in a year.
[20:55] <DSpaceSlackBot> <tdonohue> Yes, that's true @mwood. It's the great balancing act of "what can we really do in a reasonable amount of time" (presumably a year's time)
[20:55] <DSpaceSlackBot> <tom_desair> Ok, I thought that DSpace-CRIS has hierarchical metadata and that it would be ported to DSpace 7.
[20:57] <DSpaceSlackBot> <tdonohue> No, to clarify.... at this point in time, DSpace 7 is primarily about REST API + Angular UI. We have no current plans to update the data model / metadata from what is in DSpace 6.
[20:57] <DSpaceSlackBot> <tom_desair> Ok my apologies for the confusion then.
[20:58] <DSpaceSlackBot> <mwood> Some smaller stuff will probably get in, as time permits. But I don't think there is enough time for other big stuff.
[20:58] <DSpaceSlackBot> <tdonohue> That all said, there are *definitely* tensions to do "more". These discussions are going on in DSpace Steering right now. For instance, there likely will be a DSpace Working Group created very soon (look for it in next few weeks) to discuss Data Model changes for the future
[20:59] <DSpaceSlackBot> <tdonohue> That upcoming DSpace Working Group will be publicly announced soon (should have added this to the agenda, sorry). But, the goal is to plan out what we need, roadmap it, see if there are "small changes" achievable in DSpace 7 (there may not be), and then figure out next steps
[21:00] <DSpaceSlackBot> <tdonohue> So, if you are interested in data model changes (primarily around DSpace-CRIS, adding "authors" and similar objects), then keep an eye out and join the upcoming Working Group. But, at least right now, I'd anticipate the actual code would be post-DSpace 7
[21:00] <DSpaceSlackBot> <mwood> Authors +1
[21:01] <DSpaceSlackBot> <tdonohue> As for DSpace 7, I'm intentionally trying to keep the scope "small", as simply rewriting the REST API and a new, more user-friendly UI is a pretty massive job ;)
[21:02] <DSpaceSlackBot> <tom_desair> Good plan
[21:03] <DSpaceSlackBot> <tdonohue> And, I now realize we are at the hour. This has been a great discussion though. I honestly do appreciate the questions about DSpace 7 (keep asking them), as it helps give me feedback on the effort (and the message others are hearing too)
[21:04] <DSpaceSlackBot> <hpottinger> I do hope some attention can be paid to workflows in the next UI?
[21:05] <DSpaceSlackBot> <mwood> Probably nothing really new, but are there things that could be fixed within the confines of the existing implementation? (Like, get down to *one* implementation?)
[21:05] <DSpaceSlackBot> <hpottinger> (my apologies, I was in lurking mode for most of the meeting, I was double-booked)
[21:05] <DSpaceSlackBot> <tdonohue> Attention (at a UI or UX level) is being paid to *everything* in the new UI. But, if there's specific things you want to see out of it, you are welcome to join the meetings...or we have started creating "mockups": https://wiki.duraspace.org/display/DSPACE/DSpace+7+UI+Mockups
[21:06] <DSpaceSlackBot> <hpottinger> I personally don't have a concern with workflows, but I do know that many people do.
[21:06] <DSpaceSlackBot> <tdonohue> I will also note here that I'm starting to also give updates in the DSpace 7 Outreach Mtgs (see outreach). So, that's another place that folks can join. That tends to be a less techie group, and we are planning on presenting mockups to that group for feedback in future meetings
[21:07] <DSpaceSlackBot> <hpottinger> @aschweer is aware of the rough edges in the current workflow system, and likely has a few things to say about how the next gen should work
[21:07] <DSpaceSlackBot> <mwood> So we need a collation of what "many people" want to see in the workflow area.
[21:07] <DSpaceSlackBot> <tdonohue> The outreach meetings are every other Weds at 15:00 UTC (on the Weds when this meeting is at 20UTC)
[21:08] <DSpaceSlackBot> <mwood> Right now we have the same problem with workflow that we have with UI: too many.
[21:08] <DSpaceSlackBot> <hpottinger> welll... yes... and no way to see what objects are in what state
[21:08] <DSpaceSlackBot> <tdonohue> @hpottinger: to clarify, we really are concentrating only on UX/UI. So, if how it should "work" is how it should work in the UI, then that's possible. But, if you are talking configuration/code 'overhaul', that'd likely be something for post-DSpace 7
[21:09] <DSpaceSlackBot> <tdonohue> And we do have some Submission/Workflow related Mockups at: https://wiki.duraspace.org/display/DSPACE/DSpace+7+UI+Mockups
[21:09] <DSpaceSlackBot> <tdonohue> Feedback is more than welcome on those!
[21:09] <DSpaceSlackBot> <mwood> But the New UI will have to deal with all the workflow models that we still have...
[21:10] <DSpaceSlackBot> Action: tdonohue realizes we are "over time here". if folks need to leave, please feel free to do so. But, I'll stick around to continue this discussion as needed
[21:11] <DSpaceSlackBot> <tom_desair> Once the REST API is more mature and we can better estimate what the effort would be to expose two workflow systems through REST (and in the UI) vs removing and migrating one and only exposing the other, we can make that call.
[21:12] <DSpaceSlackBot> <mwood> That makes sense.
[21:13] <DSpaceSlackBot> <tdonohue> 4Science (@bollini and his team) has been concentrating on the Submission/Workflow designs/work for the new UI. I know they are planning some small enhancements (as they are getting some funding from U of Hasselt for that work), but primarily it will be "backwards compatible" with DSpace 6 (but with what we hope will be a better user experience, etc.)
[21:14] <DSpaceSlackBot> <tom_desair> But no single institution will combine the two workflow systems, they’ll either use basic or XML.
[21:14] <DSpaceSlackBot> <tdonohue> So, again, the main concentration is on a better REST API and better UI/UX. If you'd like to be more plugged into those discussions, I honestly do welcome any of you to join the DSpace 7 dev meetings (angular-ui , Thurs @ 15UTC) or DSpace 7 Outreach Mtg (outreach)
[21:16] <DSpaceSlackBot> <tdonohue> This discussion reminds me...I should add in a "general DSpace 7 updates" section to this meeting...just to pass along current status, etc
[21:16] <DSpaceSlackBot> <tom_desair> Interesting times are coming ;). I’ve got to get some sleep now. See you!
[21:16] <DSpaceSlackBot> <mwood> I have to run, too. Thanks, all!
[21:16] <DSpaceSlackBot> <terrywbrady> have a good evening
[21:16] <DSpaceSlackBot> <tdonohue> Thanks all!
[21:17] * mhwood (~mhwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:48] * tdonohue (~tdonohue@dspace/tdonohue) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.