Timestamps are in GMT/BST.
[1:31] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Remote host closed the connection)
[6:26] * kostasp (02553771@gateway/web/freenode/ip.2.85.55.113) has joined #duraspace
[6:49] -leguin.freenode.net- *** Looking up your hostname...
[6:49] -leguin.freenode.net- *** Checking Ident
[6:49] -leguin.freenode.net- *** Found your hostname
[6:49] -leguin.freenode.net- *** No Ident response
[6:49] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:49] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:49] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:25] * kostasp (02553771@gateway/web/freenode/ip.2.85.55.113) Quit (Ping timeout: 246 seconds)
[9:50] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[12:21] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has joined #duraspace
[12:21] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:22] * peterdietz (~peterdiet@server112.longsightgroup.com) has joined #duraspace
[12:24] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Client Quit)
[13:05] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[14:01] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Quit: Ex-Chat)
[14:02] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[14:04] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has joined #duraspace
[14:20] * kdweeks (~Adium@2001:468:c80:a103:b135:a83a:9cb7:b79c) has joined #duraspace
[14:24] * kdweeks1 (~Adium@2001:468:c80:a103:6860:79c4:61e2:5ff0) Quit (Ping timeout: 272 seconds)
[14:35] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Quit: Ex-Chat)
[14:38] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[14:49] * peterdietz_ (~peterdiet@162-231-22-3.lightspeed.clmboh.sbcglobal.net) has joined #duraspace
[14:50] * peterdietz (~peterdiet@server112.longsightgroup.com) Quit (Ping timeout: 250 seconds)
[14:50] * peterdietz_ is now known as peterdietz
[16:52] * mlilenium_ (~mlilenium@178.251.136.142) has joined #duraspace
[16:53] * mlilenium_ (~mlilenium@178.251.136.142) has left #duraspace
[18:16] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[18:55] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[19:30] * kstamatis (2ebe51fc@gateway/web/freenode/ip.46.190.81.252) has joined #duraspace
[19:54] * robint (5eaf588c@gateway/web/freenode/ip.94.175.88.140) has joined #duraspace
[19:58] * pbecker (~anonymous@55d43b82.access.ecotel.net) has joined #duraspace
[19:58] * KevinVdV (~KevinVdV@d5153D041.access.telenet.be) has joined #duraspace
[20:00] * bollini_ (~chatzilla@host221-236-dynamic.42-79-r.retail.telecomitalia.it) has joined #duraspace
[20:00] <tdonohue> Hi all, welcome! It's time for our DSpace Developers meeting. Agenda for today: https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-10-15
[20:01] <kompewter> [ DevMtg 2014-10-15 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-10-15
[20:01] <tdonohue> Before we do get started (and get into the main topic), I did want to add a quick reminder
[20:01] <tdonohue> 5.0 Feature FREEZE is Monday (Oct 20)!
[20:02] <tdonohue> (Or at least, that's the current deadline...we may need to determine later in this meeting if we need to push back or make exceptions for some features)
[20:03] <tdonohue> In any case, we'll move along into the big topic for today :)
[20:04] <tdonohue> As Committers are well aware, there's a bit of a backchannel discussion going on right now around @mire's "Author Profiles" feature (DS-2169) and CINECA's 'dspace-cris' plugin (https://cineca.github.io/dspace-cris/features.html)
[20:04] <kompewter> [ https://jira.duraspace.org/browse/DS-2169 ] - [DS-2169] Author Profiles - DuraSpace JIRA
[20:05] <bollini_> I'm here. I have already express my opinion about dspace-cris vs author profile
[20:05] <bollini_> summarizing, I think that it is a too important change to make a fast decision just to meet the DSpace 5 deadline
[20:05] <tdonohue> Namely, from my understanding, these two features directly conflict and have differing backends. So, we have a decision in front of us
[20:06] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:06] <hpottinger> a minor quibble: DSpace-CRIS is not a feature of DSpace itself, though it could be some day
[20:07] <tdonohue> So, we may as well start with bollini_'s concerns about "Author Profile" then, and whether we should even consider it in 5.0
[20:07] <tdonohue> bollini_ : do you want to explain your views in a bit more detail here, so we can ask questions as needed?
[20:07] <helix84> hpottinger: it's not so much about the CRIS functionality, it's about the underlying data model of objects (potentially new ones) and theire relations
[20:08] <bollini_> ok. INHO the question here is are we going to change the dspace data model?
[20:08] <bollini_> exactly... if we are thinking about the data model we should talk at 360 degree
[20:08] <bollini_> it doesn't really matter if you call that new entity cris or not
[20:09] <tdonohue> But, I guess the changes to the DSpace data model that went into "Metadata for All Objects" feature were OK? Just wanted to point out that we've already changed our data model in 5.0
[20:09] <aschweer> I think it's also about the feature set of DSpace, either of these contributions changes the feature set of DSpace quite a bit. Metadata for all (however implemented) by itself doesn't
[20:09] <bollini_> no, we are extended the existent data model to use something that already was in place for item
[20:09] <mhwood> That's one of the things that makes it ".0"
[20:10] <bollini_> justo to be more clear. Metadata for all is ok for me
[20:10] <hpottinger> I just wanted to be sure we keep in mind that we're talking about a PR of a feature to be added to DSpace, and a conflict with a fork of DSpace
[20:10] * kohts (~kohts@ppp91-78-164-247.pppoe.mtu-net.ru) has joined #duraspace
[20:11] <tdonohue> aschweer: good point. Metadata for All Objects was backwards compatible...it was more of a "refactor" to support new features that the previous data model couldn't really handle
[20:11] <bollini_> I think that we are talking about something slighly different
[20:11] <bollini_> we are talking about making a change to the domain data model, without previous discussion
[20:12] <bollini_> I just want to get the big picture here
[20:12] <helix84> hpottinger: merging author profiles to DSpace is not going to 'hurt' the DSpace-CRIS fork. It is going to cost us an extra migration from the ad-hoc author profiles model, should we decide to adopt the universal object relation data model used in DSpace-CRIS.
[20:13] <bollini_> if we are ready to talk about the need of new entity in dspace to meet modern requirements we should evaluate what is available for the community
[20:13] * lievend (~lievend@cpe-76-176-128-229.san.res.rr.com) has joined #duraspace
[20:14] <bollini_> and dspace-cris is available. Cineca is available to work to make the merge easier, the license is compatible
[20:15] <bollini_> it is just surprising for us to know that author profiles are a big requirement for dspace, and the PR just happen few days before the PR freeze
[20:15] <lievend> I wanted to point out that DSpace is not a CRIS system, and should not have to support a full CRIS data model.
[20:15] <tdonohue> So, the first I heard of @mire's Author Profiles was actually several months ago (at or around the time of OR14). At that point, it wasn't clear what the underlying data model looked like, but @mire was talking about it then with developers.
[20:15] <bollini_> without previous notice
[20:15] <aschweer> I can see the perspective of "DSpace-CRIS is a fork and there is no PR, hence no official request to integrate it with DSpace". However, I can also see the point of keeping new developments completely separate if it appears that they are not a core requirement of DSpace functionality
[20:15] <tdonohue> I will agree though that the PR for Author Profiles did come in a bit late...but still prior to our deadline
[20:15] <helix84> Don't misunderstand me, I want author profiles yesterday. But I already know there I will later want to extend the currently proposed author profiles functionality - and it doesn't give you the systematic model for extending it.
[20:15] <lievend> I had also talked a bit about author profiles at OR, and it was also presented by the World Bank
[20:16] <tdonohue> Oh, hi, lievend. Welcome. Yes, thanks for the reminder about the World Bank presentation. I knew there was some talk at OR14
[20:16] <bollini_> lievend: do you know that we are asking to talk with you about dspace-cris from several months but this has been impossible
[20:17] <bollini_> and we have had no notice that you are working on a such project
[20:17] <hpottinger> Kevin did menion the contribution was coming after Metadata For All...
[20:17] <lievend> Please keep this to the point
[20:17] <lievend> I don’t see any point in passing the blame around the table
[20:17] <tdonohue> I honestly think we need to avoid blame here too
[20:17] <lievend> We have a contribution ready that I am sure of that most people will like it and willwant to use it
[20:17] <bollini_> anyway, this is not about @mire or cineca
[20:17] <lievend> good
[20:18] <bollini_> this is about how to improve in the long run the dspace data model
[20:18] <lievend> Any my only point is that DSpace is not a CRIS system, and should not need to support a full CRIS data model, but rather a simplified data model, that allows people that don't have a CRIS system to offer basic author profiles to their users.
[20:18] <lievend> Integration with a CRIS system (or a CRIS addon) should of course be possible, as we also have quite a few clients that use a fully fledged CRIS system
[20:18] <bollini_> dspace-cris is not a cris system
[20:19] <lievend> I mentioned CRIS add-on as well
[20:19] <helix84> lievend: the point of confusion is that it's not a CRIS specific data model. It's a model for objects (items, authors, journals, organizational units, projects, whatever) and their relationships. CRIS is just one application of the model.
[20:19] <bollini_> it allows easy integration of dspace with cris system, one use case of dspace-cris is CRIS system but it is not limited to that
[20:19] <lievend> And we have no problem making any changes to support integration with CRIS systems or add-ons in DSpace 6.
[20:19] <bollini_> helix84: exactly
[20:20] <bollini_> trying to see things from a different point of view
[20:20] <bollini_> some features that we can have with the dspace-cris implementation:
[20:21] <bollini_> - unlimited additional entities
[20:21] <tdonohue> So, is there no way to potentially *start* with "Author Profiles" in 5.0, but then migrate to something more flexible (dspace-cris data model) in 6.0? I guess I'm trying to understand why it's easier to avoid Author Profiles altogether instead of taking "smaller steps" towards different types of data in DSpace (in this case Authors)
[20:22] <tdonohue> Or is the argument that DSpace should *not* have an Author object at all? (Cause that stretches our data model)
[20:23] <lievend> As always, we are more than willing to make changes needed in DSpace 6 to support further development of adding new objects.
[20:23] <hpottinger> +1 tdonohue: I also am not quite sure why we need to make this PR wait
[20:23] <lievend> I just dont see the point in holding back a feature that is in faily high demand;
[20:24] <bollini_> IMHO dspace needs entities to better describe items
[20:24] <mhwood> Or turn it around: if a feature PR freeze extension were granted by the RT, could DSpace-CRIS be ready for 5.0 by next Monday? Would it give us approximately what Author Profiles does? Could it be used only for author profiles, if that's all that a site wants?
[20:24] <helix84> tdonohue: it's just that author profiles is adding the author profile table and a table for its relationship with bitstreams. With the DSpace-CRIS data model, this would be implemented a bit differently - in a way that makes adding any new entities and relationships easier (and make no mistakes, we will want other entities). So it's just that we would need to do a migration step.
[20:24] <bollini_> authors are one of that but not the only one
[20:24] <lievend> Right but authors is the first step, and most requested by users as far as we know
[20:25] <bollini_> author profiles is only for XMLUI do we really want not parity between the two UI around the core data model?
[20:25] <tdonohue> helix84: but, wouldn't we need to do some form a migration anyways if we moved to dspace-cris data model? I can understand it may complicate a migration slightly.
[20:25] <lievend> But to be honest, I wouldn’t mind of our contribution will be cancelled, I just don’t think that doing that would be the best way forward to encourage upgrades and a wider asaption of DSpace as a platform
[20:25] <helix84> bollini_: I think it would help if you again briefly describe the data model used in DSpace-CRIS (because this is not about CRIS functionality, it's about the concept of easily adding entities)
[20:26] <mhwood> I like the sound of that flexibility.
[20:26] <bollini_> ok I will try to summarize
[20:27] <bollini_> I want also to say that the flexible datamodel of dspace-cris has not replaced the dspace metadata model for items also in our EE CRIS solution
[20:28] <bollini_> this because if you are describing a "publication", or an object of a catalogue it is no so bad to rely on a flat schema
[20:28] <bollini_> if you start to model anything else authors, organizations ,project etc. this will be not enought
[20:28] <bollini_> so the two model can live togheter
[20:28] <lievend> It can be if you keep it simple
[20:29] <bollini_> now, just few features of the data model
[20:29] <bollini_> you can define new entities from the UI, say journals, awards, classification, etc.
[20:30] <lievend> We see the author profiles as a quite simple and easy to manage feature that allows institutions to expose more information about authors without the complexity of having to define a data model.
[20:30] <bollini_> dspace-cris comes out-of-box with a basic data model already defined
[20:31] <bollini_> that includes author profiles
[20:31] <bollini_> and we can provide different out-of-box setup to meet the need of different domains
[20:31] <pbecker> Was there any attemp to add dspace-cris to DSpace? What is the reason it is an addon on its own and not included into DSpace?
[20:32] <bollini_> it is an addon because when we have developed it
[20:32] <bollini_> it was perceived as too much and not necessary to the whole dspace community
[20:32] <lievend> Right, and I still think that that is the case
[20:33] <helix84> lievend: think of it this way - if I get author profiles in 5.0, great, but next thing I will want (in 6.0) will be to put them into a tree of organizational units. Link items to sources of funding. Link items to conferences. And that's just the top of the list.
[20:33] <bollini_> but as far as I have understand it looks as this is changing
[20:33] <lievend> What if an institution has a CRIS system like Symplectic Elements for example
[20:33] <bollini_> institution whit a CRIS system want to public information on the web
[20:33] <bollini_> so now the use dspace and put publication in dspace
[20:34] <bollini_> next time they could decide to purchase a commercial module for the research portal
[20:34] <tdonohue> helix84: not sure I agree. Many USA institutions (which aren't really into CRIS's in general...it's not a thing over here) just want the idea of "researcher pages" that faculty can list their publication on. I don't think everyone wants or needs the complexity of grants/funding/organizations/research units
[20:34] <bollini_> and we will lose the cris community
[20:34] <lievend> correct, symplectic has a module to integrate with DSpace for that (developed by Graham Triggs)
[20:34] <lievend> Right, and the CERIF data model is also very Europe-centric
[20:35] <lievend> And quite complex to learn and manage
[20:35] <bollini_> dspace-cris data model is not cerif
[20:35] <bollini_> can be mapped to cerif as it is very flexible but it is not the CERIF data model
[20:36] <bollini_> CERIF is not really only an european standard
[20:36] <bollini_> please check the partnership of euroCRIS... with the vivo community for example
[20:36] <bollini_> or with CASRAI
[20:37] <bollini_> we already have a lot of issue and blame because we invite people to use a poor data model to describe things
[20:37] <helix84> tdonohue: OK, a different example. Another long requested feature is to let authors edit their items. IOW, to make epersons and authors the same object - a person. And then to link a single author with multiple items. No need to duplicate the person's information (whatever you want them to be). No need for an ad-hoc authority feature. All part of the data model.
[20:37] <tdonohue> It's hard to say right now if "dspace-cris" would be more widespread interest in our community in a year or two...it very well might. But, I guess I just still fail to understand why a migration from "Author Profiles" -> dspace-cris would stand in the way? Isn't it better to get people used to the idea of "author profiles" so they *want* "dspace-cris"?
[20:38] <bollini_> think about the link between publication and project
[20:38] <mhwood> Could you have a PR for DSpace-CRIS against DSpace master, known to be mostly working, by next Monday?
[20:39] <tdonohue> I fully understand migration from "Author Profiles" -> DSpace-CRIS is migrating between two data models....so maybe it's not easily possible in plan old SQL scripts. But, maybe it's scriptable in Java?
[20:39] <tdonohue> +1 mhwood (if that's plausible/possible)
[20:40] <bollini_> mhwood: I will be very happy to receive this request one or two months ago
[20:41] <bollini_> now it is a little hard for us to schedule a such big contribution in short time
[20:41] <bollini_> also because we probably don't want the whole dspace-cris
[20:41] <bollini_> we can make a PR... but it will be unmanageble
[20:42] <mhwood> So there's this somewhat simple feature that people have been requesting for years, and now it's been offered, and instead we should wait a year?
[20:42] <lievend> But why is it so difficult to expand on what we have in the PR towards DSpace 6. Technically author profiles is a single table to store author profiles identifiers. These identifiers are used to link to metadata/authorizations/profile picture.
[20:42] <pbecker> tdonohue if I understand it correctly the problem is that dspace-cris uses the author in other relationships as well. if that’s right it might be hard to update dspace-cris to be compatible with a version of dspace containting the „author profiles“ as it would have an entity author as well that cannot be used in relation to other entities of dspace-cris. bollini, helix: is that correct?
[20:43] <lievend> So it’s quite simple, and refactoring it to support the CRIS addon should not be that difficult. And we are more than happy to provide support with that
[20:44] <mhwood> I think that "update DSpace-CRIS to be compatible with Author Profiles" will turn out to be "remove Author Profiles in 6.0 and make it possible to use the DSpace-CRIS author entity the same way."
[20:44] <bollini_> sorry but why it is not appropriate share the author profile contribution as an addon for dspace 5
[20:44] <bollini_> and in dspace 6 build a migration path from author profile and dspace-cris to the solution that we will choose?
[20:44] <helix84> pbecker: I'd say that's more or less correct. DSpace currently doesn't have a real representation of an author as an entity which can have relations to other entities.
[20:45] <lievend> That would be fine with us, but I assume that there are quite some users who would like to see some basic author profile functionality in DSpace 5.
[20:45] <pbecker> helix84: thanks, now I understand the conflict much better.
[20:45] <tdonohue> what if we made "Author Profiles" optional in some way? (similar to XML Workflow)... is that plausible? Let those who want the feature have it....but if folks using dspace-cris and others don't want it, leave it disabled?
[20:45] <lievend> That would also be fine with us
[20:45] <aschweer> In terms of having functionality sooner vs getting it right first time -- I don't think there is a right way, but I'm sure some people would prefer not to enable something this year and then having to change all the settings again next year
[20:46] <pbecker> tdonohue: I see a problem with having a lot of optional features that are realized for one of both UIs only.
[20:46] <pbecker> Some weeks ago there was the question if we could make xmlworkflow default until I mentioned that it is not ported to the JSPUI.
[20:46] <lievend> I think we should try to keep the 2 UIs problem out of this discussion.
[20:47] <tdonohue> yes, UI parity is an ongoing issue, which we unfortunately won't be able to solve with this. Even 'dspace-cris' is only for JSPUI
[20:47] <lievend> That would lead us to far away from finding a solution for the problem that Andrea voiced with our contribution
[20:47] <bollini_> exactly
[20:47] <bollini_> and this is the reason why I'm not asking to put it in dspace 5 also if we can made a PR
[20:48] <lievend> I am sorry but I don’t understand that sentence
[20:48] <hpottinger> lievend: would @mire be able to make DSPR#668 optional by October 20 (feature freeze)?
[20:48] <kompewter> [ https://github.com/DSpace/DSpace/pull/668 ] - [DS-2169] Author profiles for XMLUI by KevinVdV
[20:49] <tdonohue> I think the point is that 'dspace-cris' is currently JSPUI-only, and "Author Profiles" is currently XMLUI-only. Neither is cross-UI compatible...and bollini_ is suggesting neither therefore should be accepted as a PR for 5.0
[20:49] <lievend> Yes we would be able to do that
[20:49] <bollini_> sorry but I'm not happy also with an optional solution
[20:49] <bollini_> this is a different scenario than xmlworkflow
[20:50] <bollini_> xmlworkflow is an improvement, with change to the datamodel that has been agreed
[20:50] <bollini_> so it traks the route also for the jspui
[20:50] <helix84> lievend: Andrea says that they didn't push for inclusion of DSpace-CRIS because the model currently has interface only in JSPUI
[20:50] <bollini_> and if we decide that xmlworkflow need to be the default or the only model for workflow I will be favour
[20:51] <bollini_> but we need to give to the jspui community enough time to work on it
[20:51] <bollini_> the same thing happen for that
[20:51] <bollini_> we want author profile, give time to the community to reach an agreement about a common data model
[20:51] <tdonohue> we're not really talking about xmlworkflow today though...I just mentioned it as an example of a "optional" feature which requires DB tables
[20:51] <lievend> There are many features that are only written for one UI. We have ported a number of jspui-only features to xmlui in our conrtributions for DSpace 5.
[20:52] <kohts> From the not_so_long_ago_new_dspace_user perspective: DSpace optional features list looks huge. The first idea which came to my mind when I was turning on the features was: why aren't they turned on by default? Even the language switch is turned off by default (which I then thought was a sign of mostly english speaking user base).
[20:52] <bollini_> it is not about features... it is about data model
[20:53] <tdonohue> kohts: yep, I agree it's a long list, which we are gradually shortening over time... if there's any you see as probably should be "enabled by default", feel free to send a ticket / PR our way and we can review it
[20:53] <bollini_> if we want to implement a new feature say in jspui and we put extra columns in item , bitstream, etc. without a previous reflection probably we will discuss about the opportunity of that contribution
[20:53] <helix84> kohts: language switching is not 'off', you just need to provide a list of languages you want to switch.
[20:55] <hpottinger> bollini_: a while ago, you said that making DSPR#668 optional would not make you happy... can you explain?
[20:55] <kompewter> [ https://github.com/DSpace/DSpace/pull/668 ] - [DS-2169] Author profiles for XMLUI by KevinVdV
[20:55] <lievend> I would like to summarize at this moment. I see a few different opinions here. From our side we don’t really need to push this contribution to DSpace 5. We have a lot of other contributions going in for DSpace 5 but I do think that a lot of people would prefer to see the author profiles go into DSpace 5. Removing it from an installation is a simple as dropping a table, and we can provide a switch to turn it off in the UI as well (al
[20:55] <lievend> that is not really needed since it would not conflict with the jspui CRIS addon).
[20:56] <bollini_> hpottinger: technically we can make dspace-cris option, should we include in dspace?
[20:56] <tdonohue> bollini_: Author Profiles just adds two new tables & some indexes...it doesn't add new columns in existing tables. It's actually much more simplistic than XMLWorkflow (which requires adding 6+ tables and indexes and migrating all existing workflows to the new tables)
[20:57] <bollini_> if it is part of dspace, it means that it is supported by the committer group. And it is perceived as "stable" a trust route
[20:57] <lievend> But it can evolve over time
[20:58] <helix84> Whatever the conclusion may be, we should discuss the data model used in DSpace-CRIS in January so that any new functionality may be based on it (if we decide to adopt it in DSpace 6)
[20:58] <lievend> I agree with that
[20:59] <mhwood> So then: do we wait *another* year to have author entities in DSpace; or do we adopt Author Profiles now, and probably take them out and transform the data to fit a new more flexible framework in 6.0?
[20:59] <tdonohue> So..I'm starting to feel we are at an impasse / deadlock with this discussion. Wondering about next steps. Should we call a vote of Committers? (Where I'd likely recommend both @mire and CINECA Committers refrain from voting)
[21:00] <tdonohue> (To be clear...if we call a vote of Committers, I'd recommend doing so via Email so that all could take part)
[21:00] <peterdietz> Author Profile adds to org.dspace.Constants type "AUTHOR_PROFILE". You can browse by author profiles. I see the value of the profile page, but does the DSpace data model need to take a moment to support this richer metadata value. Where dc.contributor can be metadata of type Author. And an Author is name, Institution, picture, etc.. and/or does Author Profile move us towards wanting to make richer metadata types
[21:00] <helix84> tdonohue: I'd make such vote on the list to give all commiters the opportinity to vote, even if it takes only 3 days.
[21:01] <tdonohue> helix84: yea, that's actually what I meant..the vote would be via our mailing list
[21:01] <tdonohue> (not here, as we don't have all Committers in attendance)
[21:01] <bollini_> do you feal confortable with a huge PR that will add author profile using the dspace-cris data model for both jspui and xmlui?
[21:02] <hpottinger> so... rutes of voting are...
[21:03] <lievend> Tim, I am more than fine with a vote, but I would hope that we can avoid a vote. I don’t think that this is such a big issue that it requires a vote from committers. In addition, it will take some time to present a objective description of the “problem” to the committers.
[21:03] <mhwood> It sounds like that PR will come after 5.0 feature freeze, so there is plenty of time to study and work on the code.
[21:03] <hpottinger> (I only ask becuase there's clearly a veto ready to be cast)
[21:04] <mhwood> (Unless it comes 11 months after the freeze. :-/ )
[21:04] <tdonohue> hpottinger: I was merely asking if we *wanted* to call a vote (on -commit list)....wasn't suggesting we vote now
[21:05] <hpottinger> understood, but if it's standard rules voting, I think I already know the outcome
[21:05] <tdonohue> lievend: If there's a way around a vote, I'm cool with that. It just sounds like we are at a deadlock to me (unless I've misread). bollini_ definitely doesn't want "Author Profiles" in....but @mire definitely does. We either need a compromise, or a vote.
[21:05] <robint> hpottinger: tim suggested Cineca and @Mire abstain
[21:06] <tdonohue> hpottinger: yes, I suggested both CINECA and @mire abstain from a vote...otherwise @mire would have an unfair advantage since it has more committers
[21:06] <bollini_> I like more proposal of collaboration....
[21:06] <peterdietz> I'm of the feeling that we might not want to be touching our data model right now, since this feature could be too volatile
[21:06] <hpottinger> robint: understood, which is why I asked for an explicit rules for the vote
[21:06] <robint> +1 to a vote on the list. Voting is the normal procedure, albeit it is normally done in IRC rather than on the list
[21:07] <lievend> The normal procedure says that one negative vote is enough to stop the contibution from getting into DSpace 5
[21:07] <tdonohue> lievend: actually, it depends on the *type* of vote
[21:07] <lievend> I am not sure if those rules would have the desired outcome, being a represenatation of the majority of DSpace users.
[21:07] <lievend> ah ok, my bad
[21:08] <tdonohue> My thought here was that what we are voting on is this...
[21:08] <helix84> bollini_: in your opinion as a DSpace commiter, not CINECA member, what do you think would be best for DSpace right now?
[21:08] <bollini_> what about delay the 5.0 release?
[21:08] <mhwood> How many days?
[21:09] <helix84> bollini_: I was thinking of suggesting that. About a month would do, right?
[21:09] <lievend> Delay for this? That would be a very bad idea in my opinion
[21:09] <lievend> Then Iwould be happy to cancel our contribution.
[21:09] <bollini_> it is an important feature or not? I'm missing the point
[21:09] <peterdietz> ..or we could have dspace 6 come out sooner, like before OR15. Where addressing this data model concern could be primary roadmap event
[21:10] <pbecker> bollini asked if we would feel comfortable with a huge PR that will add author profile using the dspace-cris data model for bot UIs. I’m not sure whether I understood the following. Is it possible to get such a PR in 5.0 or is this impossible do to time problems?
[21:10] <helix84> We still haven't really talked whether we want the model used in DSpace-cris in the long-term
[21:10] <aschweer> what would the purpose be in delaying the release? (as in, what should the state of things be at the end of the delay?)
[21:10] <bollini_> my problem here is that I don't want change the data model to adopt something that we are alredy saing to want change in a big way
[21:11] <lievend> Who is daying that we want to make that huge change to the data model
[21:11] <aschweer> helix84++ (but same applies to author profiles)
[21:11] * kohts (~kohts@ppp91-78-164-247.pppoe.mtu-net.ru) Quit (Remote host closed the connection)
[21:11] <KevinVdV> <= needs to run, until next time
[21:11] <lievend> I think most users would just like to see a simple addition to make authors more visible in DSpace.
[21:11] * KevinVdV (~KevinVdV@d5153D041.access.telenet.be) Quit (Quit: KevinVdV)
[21:11] * kohts (~kohts@ppp91-78-164-247.pppoe.mtu-net.ru) has joined #duraspace
[21:11] <aschweer> lievend: granted, but most users would also not like to enable something now and then make huge settings changes again next time (I think)
[21:12] <bollini_> all people want simple things... but if we do all they want we will have a mess
[21:12] <bollini_> we need a roadmap, and we need to make decision
[21:12] <bollini_> to make decision we need understanding and this requires time
[21:12] <robint> Worth bearing in mind that very few sites upgrade on an annual basis
[21:12] <lievend> Please keep is civilized andrea, please don’t imply that we are trying to make a mess of things
[21:12] <tdonohue> I think I'm finding this discussion a bit difficult as the "assumption" seems to be that we'd *definitely* move to dspace-cris later on... While that *might* be the case, I'm worried we are planning for an "unknown" that may or may not happen
[21:13] <helix84> lievend: The point is we had about 2 years to talk about whether we want the big change (the code is out there) but then your last-minute PR uses a different model (I'm not trying to blame you, sorry if it sounds that way)
[21:13] <bollini_> lievend: no, I'm not talking about the author profile
[21:13] <bollini_> I'm talking in general, but the simpler way not always is the best way or the easier way
[21:14] <tdonohue> And I think it's hard for me to balance the fact that we have a simpler PR (Author Profiles) which seems popular.....but, yea, there's the *risk* that we'd migrate to something else later on
[21:14] <bollini_> sorry if my english looks more aggressive than what I want
[21:14] <pbecker> helix +1
[21:14] <hpottinger> robint: not sure if it helps this discussion at all, but my repository is planning to roll out with a DSpace:master-based upgrade soon-ish, and author profiles is on our wish list
[21:14] <lievend> apologies accepted
[21:14] <peterdietz> I think everyone is fine, I'm happy to see so much debate
[21:15] <aschweer> I'm not sure "seems popular" is good enough for me at this point. I thought there would be a roadmap discussion on where DSpace is headed -- both DSpace-cris and author profiles make DSpace go into a new direction functionality-wise but the discussion now seems to be more at the data model level
[21:15] <lievend> Look, we at @mire are only doeing this PR because many of our users have expressed interest in a simple way to provide more exposure for their authors.
[21:15] <hpottinger> so, I think we'll probably vote with our cherry-pick :-)
[21:16] <tdonohue> aschweer: regarding a "roadmap"...there are "use case" discussions ongoing in DCAT which will eventually feed into a larger roadmap discussion (likely post-5.0 at this point). DCAT is gathering use cases from repo mgrs to help shape the longterm roadmap
[21:17] <aschweer> tdonohue: thanks for the reminder. But doesn't this mean a decision of this size (functionality-wise) should be deferred?
[21:17] <hpottinger> thanks for bringing that up, tdonohue, we're used to thinking in terms of the committers setting the road map, but... the organization model has changed a bit
[21:17] <tdonohue> We *could* ask DCAT their thoughts on this feature
[21:17] <aschweer> It'd be a shame to go for a quick fix now just to realise in half a year that we don't want this functionality as a part of DSpace (and then what? rip it out?)
[21:18] <lievend> I really did want to repeat again that our contribution is not a big change in my mind, and “ripping” it out is not difficult at all.
[21:18] <lievend> aking it optional is also possible before the feature freeze
[21:18] <helix84> my impression at this point is that short-term, it would be best to have author profiles in 5.0 as optional, not default, and to have the data model discussion ASAP in the 6.0 cycle
[21:18] <bollini_> I'm more concerned about the community perception than from the technical issue
[21:18] <hpottinger> helix84++
[21:18] <aschweer> I'm with bollini_ on this one
[21:18] <bollini_> it is easy to drop one or two table
[21:19] <bollini_> but it is not easy to say to the community that we have released something that we don't want anymore
[21:19] <aschweer> lievend, it might not be hard to rip the author profiles out of the code base, but adding that feature in now feels to me like we'd be pre-empting the roadmap discussion
[21:19] <bollini_> it is easy to migrate data from a table to a more complex structure
[21:19] <bollini_> but issues will happen
[21:20] <bollini_> and users will wait to upgrade
[21:20] <tdonohue> aschweer & bollini_ guess I'm not fully understanding the argument that we shouldn't add new features to 5.0 cause of pending roadmap discussions..
[21:20] <mhwood> Why should we say that we don't want the feature any more, rather than say that we are now working on making it even better?
[21:20] <lievend> I agree, than we shouldn’t add any features?
[21:20] <bollini_> we are not talking about an idea or something to explore
[21:20] <lievend> As there is no formal roadmap, that argument can be used to block any feature
[21:21] <bollini_> we are talking about code that is around since 3 year
[21:21] <aschweer> It feels to me that the author profiles are _quite_ different from what DSpace offers at the moment. Maybe that's just me. So no, this same argument couldn't be used to block other new features that are closer to the core of DSpace.
[21:22] <mhwood> Sorry, but I have to go. I will read the log later.
[21:22] <pbecker> lievend: we are discussion a feature that obviously runs into a data model descision. I don’t think we can genarlize that to all features. ;-)
[21:22] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:22] <pbecker> s/discussion/discussing
[21:22] <kompewter> pbecker meant to say: lievend: we are discussing a feature that obviously runs into a data model descision. I don’t think we can genarlize that to all features. ;-)
[21:23] <tdonohue> Ok..we are well over time here... still feels like we haven't made much of a decision here & are at an impasse
[21:24] <bollini_> my proposal is... to get the time to think about this disccussion 1 or 2 day
[21:24] <lievend> And then resume the discussion?
[21:25] <bollini_> think about how much time we can accept as delay, if it is a possibility
[21:25] <lievend> I dont want to delay the release
[21:25] <lievend> If that’s the case we will simply cancel the contribution
[21:26] <tdonohue> So, I think we take two steps...
[21:26] <bollini_> for the community I think that it will be a great signal to say that dspace is looking to extend the data model
[21:26] <bollini_> and we can have two solution, one for jspui and one for xmlui
[21:26] <tdonohue> (1) I'll email DCAT. I honestly want their feedback here on whether this feature is highly important or not.
[21:26] <bollini_> that can be download and evaluated
[21:27] <bollini_> and we are working to summarize these solutions
[21:27] <lievend> Tim, I agree
[21:27] <tdonohue> (2) If DCAT says they'd want it...THEN, the Committers team will need to vote on the current implementation suggestion (Author Profiles PR)
[21:27] <robint> tdonohue +1
[21:27] <tdonohue> But, if DCAT says is "medium or low" priority, we'd immediately reschedule for 6.0
[21:27] <pbecker> tdonohue +1
[21:28] <aschweer> tdonohue it would be great to get a feeling from DCAT on getting things in soon and possibly changing again vs getting things in later but they'll be more settled/stable then
[21:28] <aschweer> tdonohue++ apart from that :)
[21:28] <helix84> aschweer++
[21:29] <bollini_> aschweer +1
[21:29] <hpottinger> and, erm, feature freeze is MONDAY
[21:29] <tdonohue> aschweer: I don't think we should make any assumptions on that.... I honesty don't know that we can guarrantee that any one "piece" of DSpace will be more or less "stable" even a year or two from now
[21:30] <aschweer> lievend I think "I don't want to delay the release" is a bit strong, I do think a short delay wouldn't be a catastrophe. I'd rather delay by a week and get the decision sorted.
[21:30] <tdonohue> aschweer: in other words, who's to say we won't have *other* massive changes in DSpace necessary to support new use cases / roadmap.
[21:30] <bollini_> stable for me mean not only more robust as software
[21:30] <pbecker> should we rethink our schedule for dspace 6 to have more time between the point prs have to be created and the feature freeze?
[21:30] <bollini_> but also more accepted as solution, with more committer that thing it could be the right solution
[21:30] <peterdietz> I'd want DSpace to be able to support richer objects: Dates, Authors, Institutions... And those values can be re-used / shared. I do like that the Author Profile could get people thinking in that direction, but it's not really the foundation of further work. Maybe you could migrate your author profile data to richer author object in future.
[21:30] <bollini_> and want to work on it
[21:30] <aschweer> tdonohue fair enough but if we already know that things are likely to change, that may make a difference. I've heard "why can't this be right first time" a few times recently about new contributions
[21:30] <tdonohue> aschweer: to limit the scope of possible "big changes" just to this one feature is just too presumptuous
[21:31] <tdonohue> aschweer: I can understand that...but things are just so in flux right now (with our new model for decisions in DSpace), this is difficult to predict.
[21:32] <helix84> coming soon: DSpace 6 in PHP (just trying to lighten the mood) :)
[21:32] <tdonohue> (by "new model for decisions", I mean the governance model, etc)
[21:32] <aschweer> tdonohue again fair enough but I think this would still be useful to know -- again maybe that's just me. And I wouldn't limit this to this one feature, I'd imagine this is something that could be brought up in the roadmap discussions.
[21:33] <tdonohue> haha..don't joke too loudly, helix84 :)
[21:33] <pbecker> helix84: I thought you’re working on a python version? ;-)
[21:33] <peterdietz> you can build a REST client in PHP. Plus there is the skylight.
[21:33] <helix84> pbecker: shhhh!
[21:33] <lievend> especially since Googling DSpace and PHP might bring up the log of this discussion ;)
[21:34] <tdonohue> OK. So, we have a direction now. I'll email DCAT, we'll get their feedback. Then we'll take it from there. Hopefully they can give us some "relatively quick" feedback.
[21:34] <peterdietz> Also, everyone who can, please review the existing PR's if you can. We might be stuck here, but there's other features to still make a decision on: https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+label%3Afeature+-label%3A%22work+in+progress%22+
[21:34] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+label%3Afeature+-label%3A%22work+in+progress%22+
[21:34] <lievend> Tim, thank you for moderating this difficult discussion. Have a good evening/day everyone.
[21:34] <pbecker> I want to bring up this question again: should we rethink our schedule for dspace 6 to have more time between the point prs have to be created and the feature freeze? This would give us some time to bring different new features together. G.e. it would be good to have some more time to bring metadata for all and lod support together.
[21:35] <helix84> yeah, especially the relatively large ones like REST CRUD and Linked Data could use eyeballs
[21:35] <kohts> as a side note, our repository would contain works of deceased authors; it might have some implications both on the implementation of author profile and on the underlying data model (not sure what's the relation of a deceased person to cris in general, but there might be some)
[21:35] <peterdietz> linked data got merged in today. I feel like REST CRUD will go in this week. Could use eyeballs too
[21:35] <pbecker> helix: lod went i today. :-)
[21:35] <tdonohue> I'd agree with what peterdietz said. Please help review PRs for 5.0! We especially need some help / support in reviewing JSPUI tickets as much of the reviewers thus far have been folks who primarily use XMLUI
[21:36] <tdonohue> thanks for joining us, lievend
[21:36] <helix84> peterdietz: I go AFK for a couple of hours and you beat me to the punch!?
[21:36] <peterdietz> yeah. had to stall so you wouldn't pressure me on batch import ui
[21:36] <robint> Good discusion, got to run. Cheers all
[21:36] <tdonohue> peterdietz / hpottinger...do we need to schedule another "IRC review session" for PRs? Especially since we have Feature Freeze on Monday?
[21:36] * robint (5eaf588c@gateway/web/freenode/ip.94.175.88.140) Quit (Quit: Page closed)
[21:36] <helix84> peterdietz: we can talk about it shortly in #dspace
[21:37] <aschweer> gotta go too, thanks everyone
[21:37] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[21:37] <hpottinger> pbecker: the schedule has been tight for years...
[21:37] <tdonohue> I'm wondering primarily if we need to potentially delay the "freeze" (not much...maybe just till end of week or one week)?
[21:38] <pbecker> hpottinger: maybe, but why not rethink if it would be better to have some extra time?
[21:38] <hpottinger> I'm OK with extending to 10/24, as long as it doesn't push testathon back
[21:38] <helix84> tdonohue: I guess that will be up to the RT, depending on how much more can be merged
[21:39] <tdonohue> Right, I actually meant to ask that directly to hpottinger & peterdietz ;) I'm just noting we have 20+ feature PRs left to merge before Monday...otherwise many will just be "rescheduled"
[21:40] <peterdietz> yeah. still a lot of work to do
[21:40] <tdonohue> So, if anyone has a PR they really care about that is NOT yet merged...either make some noise, or help out or both!
[21:40] <helix84> call Max to the rescue...
[21:41] <hpottinger> helix84: Max is ready, just need to be sure which buttons we want pressed
[21:41] <tdonohue> peterdietz / hpottinger: as I see it, we may need to schedule another PR Review Session (either late this week or early next) and announce on dspace-release. Otherwise, I worry we're going to leave a lot of PRs behind "by default"
[21:41] * kohts (~kohts@ppp91-78-164-247.pppoe.mtu-net.ru) Quit (Quit: good night)
[21:42] * kdweeks (~Adium@2001:468:c80:a103:b135:a83a:9cb7:b79c) Quit (Quit: Leaving.)
[21:42] * kstamatis (2ebe51fc@gateway/web/freenode/ip.46.190.81.252) Quit (Ping timeout: 246 seconds)
[21:42] <hpottinger> I wasn't kidding about cherry-picking DSPR668, however, I just tried and found a merge conflict with DSPR#612 (already cherrypicked into my repository's master branch)
[21:43] <kompewter> [ https://github.com/DSpace/DSpace/pull/612 ] - DS-2049: DSpace ORCID (proper pull request) by KevinVdV
[21:43] <hpottinger> 612 is looking good in testing, I'll probably cast my +1 soon
[21:44] <hpottinger> as far as testing other things go, DS-2195 is getting in the way
[21:44] <kompewter> [ https://jira.duraspace.org/browse/DS-2195 ] - [DS-2195] importing AIPs with DSpace:master throws an NPE - DuraSpace JIRA
[21:44] * tdonohue is going to "close up" the official meeting. I'll ping peterdietz & hpottinger over on #dspace to figure out next steps on reviewing these 5.0 PRs that are still "waiting".
[21:45] <helix84> hpottinger: I'm going to take a look at #612 soon, too. Let's switch back to #dspace.
[21:48] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) Quit (Remote host closed the connection)
[21:48] <bollini_> hi all, I'm going to sleep. Thanks for the discussion. If you have the time please take a look to the dspace-cris documentation http://cineca.github.io/dspace-cris/doc/technical-documentation.pdf page 7-8 are about the physical and logical data model
[21:49] <bollini_> pag 26 will give you some information about how all the new relation and entities can be used
[21:50] <bollini_> pag. 42 too
[21:53] <bollini_> bye
[21:53] <kompewter> bye!
[21:53] * bollini_ (~chatzilla@host221-236-dynamic.42-79-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.91 [Firefox 32.0.3/20140923175406])
[22:04] * pbecker (~anonymous@55d43b82.access.ecotel.net) Quit (Quit: pbecker)
[22:27] * awoods (~awoods@c-67-165-245-76.hsd1.co.comcast.net) has joined #duraspace
[22:28] * tdonohue (~tdonohue@c-98-215-0-161.hsd1.il.comcast.net) has left #duraspace
[22:28] * hpottinger (~hpottinge@mu-161174.dhcp.missouri.edu) has left #duraspace
[22:38] * lievend (~lievend@cpe-76-176-128-229.san.res.rr.com) Quit (Quit: lievend)
[23:45] * hpottinger (~hpottinge@216.106.51.118.reverse.socket.net) has joined #duraspace
[23:46] * hpottinger (~hpottinge@216.106.51.118.reverse.socket.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.