Timestamps are in GMT/BST.
[6:51] -hitchcock.freenode.net- *** Looking up your hostname...
[6:51] -hitchcock.freenode.net- *** Checking Ident
[6:51] -hitchcock.freenode.net- *** No Ident response
[6:51] -hitchcock.freenode.net- *** Found your hostname
[6:51] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:51] * Topic is 'Welcome to DuraSpace IRC. This channel is used for formal meetings and is logged - http://irclogs.duraspace.org/'
[6:51] * Set by tdonohue on Thu Sep 15 17:49:38 UTC 2016
[12:37] * tdonohue (~tdonohue@dspace/tdonohue) has joined #duraspace
[13:11] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[14:48] <DSpaceSlackBot> <tdonohue> Reminder that at the top of the hour (~12mins) is our weekly DSpace DevMtg here. Agenda at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2017-12-13 (This will be our last Developer Meeting of the year. So, if we miss you, have a happy holiday & wonderful new year!)
[15:01] <DSpaceSlackBot> <tdonohue> <here>: It's DevMtg time! Agenda is above :point_up: Let's do a quick roll call to see who is able to join us today?
[15:01] <DSpaceSlackBot> <mwood> Hi there!
[15:01] <DSpaceSlackBot> <tom_desair> :wave:
[15:02] <DSpaceSlackBot> <tdonohue> While I'm waiting on the roll call, if you haven't heard...just announced, OR2019 will be in Hamburg, Germany! http://or2019.blogs.uni-hamburg.de/?p=23
[15:02] <DSpaceSlackBot> <jcreel256> I'll be lurking
[15:02] <DSpaceSlackBot> <mwood> The announcement came across email this morning.
[15:03] <DSpaceSlackBot> <tdonohue> (I'm just excited...haven't been to Germany, yet. We'll all be in @pbecker's "neck of the woods")
[15:04] <DSpaceSlackBot> <tdonohue> Ok, so, to the agenda
[15:05] <DSpaceSlackBot> <tdonohue> As noted in the agenda and elsewhere, this will be our final, official DevMtg of 2017. I'm out of the office from Dec 18-Jan 2. I will run a (likely brief) meeting on Weds, Jan 3 for anyone who is back by then
[15:06] <DSpaceSlackBot> <tdonohue> With regards to DSpace 7 updates...not much status to report. The work is progressing, but as it's a holiday time of year, things have slowed down a bit. We are working on getting Search functionality ready & Submission functionality. Both look to be getting close, and likely will be demoable sometime in January.
[15:07] <DSpaceSlackBot> <tdonohue> In the meantime, latest updates on DSpace 7 can be found in meeting notes at https://wiki.duraspace.org/display/DSPACE/DSpace+7+Working+Group
[15:08] <DSpaceSlackBot> <tdonohue> I'm going to jump down to topic #3 briefly...as it's more in relation to DSpace 7. Yesterday was the monthly DCAT meeting. During that meeting, DCAT approved our proposal in DS-3708
[15:08] <DSpaceSlackBot> <tdonohue> https://jira.duraspace.org/browse/DS-3708
[15:08] <DSpaceSlackBot> <tdonohue> This is the proposal to standardize DSpace DOIs in a "dc.identifier.doi" field, likely in time for DSpace 7
[15:09] <DSpaceSlackBot> <tdonohue> So, I've added feedback from DCAT to that ticket. It's now simply waiting for a volunteer to move it forward. I've also tentatively scheduled it for DSpace 7 (hopefully we'll find a volunteer based on that timeline)
[15:11] <DSpaceSlackBot> <tdonohue> I didn't have anything specific to discuss regarding this DS-3708 ticket. Feedback was quite positive. But, there was a request to find a way to represent DOIs from publishers (or external entities) differently (in UI) from DSpace generated (or locally generated) DOIs. Obviously, the UI may wish to promote/highlight the latter, while not necessarily the former (may depend on local policies)
[15:11] <DSpaceSlackBot> <tdonohue> (That's all noted in the ticket as a comment as well)
[15:12] <DSpaceSlackBot> <mwood> I see that some sites want to mix DSpace-controlled DOIs with others in the same field. Ugh, I was hoping to prevent that. Such mixing should happen in the presentation layer IMHO.
[15:13] <DSpaceSlackBot> <tdonohue> yes, I don't think we can avoid that. Some folks noted they *already* created/use a "dc.identifier.doi" field for externally created DOIs.
[15:13] <DSpaceSlackBot> <tom_desair> We have clients that request us to only mint a DOI if there is no DOI given in dc.identifier.doi.
[15:14] <DSpaceSlackBot> <tdonohue> So, I think getting the DOIs away from Handles (not sharing the same field) is a good concept. But, we'll have to realize that we have at least two types of DOIs here (externally and internally created)
[15:14] <DSpaceSlackBot> <tom_desair> (+ only mint for certain types of items, e.g. dataset, journal article…)
[15:14] <DSpaceSlackBot> <mwood> @tom_desair that is a reasonable desire, and could be implemented even if the code has to check a different field.
[15:15] <DSpaceSlackBot> <tdonohue> @tom_desair: I'm fine with that idea too.. Though, I think that sounds like a separate (related) feature request. It's not really to do with moving all DSpace-generated DOIs to "dc.identifier.doi"
[15:16] <DSpaceSlackBot> <tdonohue> So, I'd encourage a separate ticket. We don't have to lump all DOI-related features together ;)
[15:16] <DSpaceSlackBot> <tom_desair> Ok
[15:16] <DSpaceSlackBot> <mwood> OK.
[15:17] <DSpaceSlackBot> <tdonohue> Moving along, it sounds like we've wrapped up this discussion
[15:17] <DSpaceSlackBot> <tdonohue> Jumping back to topic #2 on agenda... DSpace 6.3 release planning: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.3+Status
[15:18] <DSpaceSlackBot> <tom_desair> I’m still doing DSpace 7 work, but I hope to start with DSpace 6.3 “soon”.
[15:18] <DSpaceSlackBot> <tdonohue> I know @hpottinger merged a recent PR for 6.3: https://github.com/DSpace/DSpace/pull/1896 But, otherwise, it seems we're all just looking to get back to 6.x
[15:20] <DSpaceSlackBot> <tdonohue> Ok, so we'll leave it at that then. If anyone has time, the checklist is quite detailed on that 6.3 "Status" page. There's plenty of ways to chip in, if you want to see 6.3 get out the door early in 2018.
[15:20] <DSpaceSlackBot> <tdonohue> Moving along...
[15:21] <DSpaceSlackBot> <tdonohue> The only other topic I had on the agenda was time for discussion of the Code Style proposal at: https://github.com/DSpace/DSpace/pull/1895 There's been a good amount of comments already on the PR (thanks all!) But, I wanted to leave time for more detailed discussion, questions or additions to the proposal, etc
[15:23] <DSpaceSlackBot> <tdonohue> One question I have (out of the comments), is where we'd like to "draw the line" in terms of code styling. I think @tom_desair had some good suggestions of ways we could enhance this, but I'm hesitant to get too strict (immediately), as even a less strict code style will be a huge benefit (and might be less painful to get started on)
[15:23] <DSpaceSlackBot> <mwood> I need to try out the NetBeans plugin and see how it compares with the native hinting.
[15:24] <DSpaceSlackBot> <tdonohue> I had purposefully tried to keep the style "less strict" initially (mostly concentrating on brace alignment & indentations), but I can see benefit to some of these other suggestions
[15:24] <DSpaceSlackBot> <mwood> I mentioned in the PR that we might do well to distinguish code-quality rules from style rules. For one thing, we might want to use a different tool for code-quality checks if it is better.
[15:25] <DSpaceSlackBot> <tom_desair> I think most rules are there to prevent human errors
[15:25] <DSpaceSlackBot> <mwood> I would be happy just to get all of the indentation fixed up.
[15:25] <DSpaceSlackBot> <tdonohue> We do already have a few code-quality tools...namely "findbugs" (not enabled by default, but is in our Maven POM) and ErrorProne (enabled by default recently)
[15:26] <DSpaceSlackBot> <tdonohue> As an example: In enabling ErrorProne, I know i had to fix up some of the `switch` fallthroughs (that were mentioned here too). https://github.com/DSpace/DSpace/pull/1861
[15:27] <DSpaceSlackBot> <tdonohue> But, that said, I'm not against having two tools do some of these checks
[15:27] <DSpaceSlackBot> <tom_desair> The advantage of checkstyle is that the IDE will warn you as you write the code
[15:27] <DSpaceSlackBot> <tdonohue> true, good point
[15:28] <DSpaceSlackBot> <tom_desair> I think the naming conventions are important to prevent confusing code like ``` public class MyClass<MyCustomType> { public void doSomething(MyCustomType type) { ... } } ``` -> Here `MyCustomType` is not a class or interface.
[15:28] <DSpaceSlackBot> <mwood> We might still want to keep the style and quality rules segregated even if we have Checkstyle apply them all.
[15:29] <DSpaceSlackBot> <tdonohue> The naming conventions are the one thing I was less certain about myself. I'm a tad worried about making the effort of bringing our code "in alignment" with this new style *to difficult*
[15:29] <DSpaceSlackBot> <tom_desair> I’m not sure I understand the difference between style and quality.
[15:29] <DSpaceSlackBot> <tdonohue> When we get into the realm of fixing naming conventions, that's a lot more than fixing alignment, braces or imports...it's essentially *refactoring code*
[15:30] <DSpaceSlackBot> <tom_desair> I think most of the code is inline with the naming conventions. But I must admit that I did not validate that.
[15:31] <DSpaceSlackBot> <tdonohue> So, myself, I'm leaning towards the first pass being about fixing the basics (alignment, braces, imports, obvious bugs). Then, we could do a second pass and look at naming conventions, etc
[15:31] <DSpaceSlackBot> <mwood> Style is about helping someone who didn't write the code to understand how to use or modify it. Quality is about whether the code does what was wanted. The former is a matter of opinion among coders; the latter is about the compiler's opinion.
[15:31] <DSpaceSlackBot> <tdonohue> (By obvious bugs, I mean adding in the checks for `switch` fallthroughs, and similar)
[15:33] <DSpaceSlackBot> <tdonohue> I do like the other basic checks that @tom_desair mentioned (switch ones, OneStatementPerLine, alphabetizing imports)...and the ones mentioned by @cwilper. Those all seem like things we could do in the first pass. We'd just leave out naming conventions for later
[15:33] <DSpaceSlackBot> <tdonohue> So, if everyone feels OK with that direction, I can update this PR per those suggestions?
[15:33] <DSpaceSlackBot> <tom_desair> Ok, no problem.
[15:34] <DSpaceSlackBot> <mwood> Yes, how many thousand lines do we want to fix all at once?
[15:34] <DSpaceSlackBot> <tdonohue> we already have 41K lines we need to fix in dspace-api alone :(
[15:35] <DSpaceSlackBot> <tdonohue> So, I'll work to update the PR with a new commit (taking into account the suggestions that fit well into this first pass), and we can give it another look. I'd encourage everyone here (or listening later) to add a :+1: next to any suggestions you feel are worth adding in
[15:36] <DSpaceSlackBot> <tom_desair> I wonder if an IDE can do some “automatic” fixing.
[15:37] <DSpaceSlackBot> <tdonohue> @tom_desair: Yes, IntelliJ IDEA can do some "automatic" fixing...I've played with that a bit, and plan to utilize it. But, it's a several step process...it seems like you have to fix code first, then imports...and I'm not sure it catches everything yet (need to do more testing)
[15:37] <DSpaceSlackBot> <mwood> Those I've used can, but if you tell one to format a big block of code then it may undo some deliberate formatting that was done with additional constraints in mind.
[15:40] <DSpaceSlackBot> <mwood> I find that often its best (for me, anyway) to let the IDE point to what it thinks is a problem and then accept the change or not as needed.
[15:40] <DSpaceSlackBot> <tdonohue> Yes, any automatic fixing would have to be checked pretty closely...I'd lean towards fixing things module-by-module (likely in separate PRs, even).
[15:40] <DSpaceSlackBot> <mwood> Or do a different change that satisfies the rules but "looks better".
[15:41] <DSpaceSlackBot> <mwood> A formatter asks "does this follow the rules?" I ask myself, "is this easy to read?" The answers are not always the same.
[15:42] <DSpaceSlackBot> <tdonohue> Right, though I don't know we want to do this line by line (it'll take forever). I suspect we may need to automate and do a scan/double check of what changed (plus ensure it all still builds/passes unit tests, obviously)
[15:43] <DSpaceSlackBot> <tdonohue> Ok, so, any other comments on this Code Style? Otherwise, we can open up the floor to other topics/comments/questions
[15:43] <DSpaceSlackBot> <mwood> Well, usually the worst that automatic formatting does is make a hunk of code "less horrible".
[15:45] <DSpaceSlackBot> <tdonohue> Not hearing further code style comments. Let's open up to other topics. Anyone have pressing topics they want to discuss today?
[15:46] <DSpaceSlackBot> <tdonohue> Ok, one other topic I should mention. As a friendly reminder, OR2018 proposals are due on Jan 5 (just after the holidays): http://www.or2018.net/call-for-papers/
[15:47] <DSpaceSlackBot> <tdonohue> So, if you want to propose a talk/workshop on DSpace (and I encourage you to do so!), please start working on them before you leave for the holidays!
[15:49] <DSpaceSlackBot> <mwood> I wanted to just take note of a recent posting to dspace-tech about "DSpace 7 and Accessability." I think we don't have any serious problem here but this is something to keep in mind. I was recently told that US institutions receiving Federal grants and such, are obliged to meet some particular level of the WCAG 2.0 recommendations....
[15:51] <DSpaceSlackBot> <tdonohue> @mwood: yes, we definitely *do* want DSpace 7 to be fully accessible. As I noted in a response to that thread, would could use some help here. We did some accessibility testing of Angular (as a platform) and it meets some guidelines automatically. But, we could use more testers as we get further along with the UI to provide feedback, log bugs, etc
[15:51] <DSpaceSlackBot> <tdonohue> So, if anyone is keenly interested in web accessibility testing, please do get in touch. We'd like you to start testing our DSpace 7 demo site: https://dspace7-demo.atmire.com/ and help us locate any existing bugs, etc
[15:52] <DSpaceSlackBot> <mwood> We ought to have some idea of what is required of sites in various jurisdictions, so that we can merge these requirements.
[15:53] <DSpaceSlackBot> <mwood> Then we can have a formal statement of what we're trying to accomplish w.r.t. accessibility.
[15:54] <DSpaceSlackBot> <tdonohue> Agreed. I'd like to look to those "on the ground" to help us define these rules, i.e. a working group or similar. But, that thread on dspace-tech hasn't had much response as of yet
[15:54] <DSpaceSlackBot> <tom_desair> Maybe the angular team can look into some automated checks? I found this https://www.npmjs.com/package/grunt-wcag-accessibility but it looks unmaintained.
[15:55] <DSpaceSlackBot> <tom_desair> This one looks better https://www.npmjs.com/package/grunt-accessibility But I’m not sure it is compatible with the current UI tool set
[15:57] <DSpaceSlackBot> <tdonohue> I'm not sure myself either. But, I can minimally create a ticket around this in the `dspace-angular` project to start gathering tools/ideas
[15:58] <DSpaceSlackBot> <tom_desair> I’m afraid if we don’t automate checks, we’ll forget it in the future.
[15:58] <DSpaceSlackBot> <tdonohue> I do know that Angular2 adds in things like ARIA properties automatically: https://www.w3.org/TR/wai-aria/ But, yes, we should try and find a way to automate checking that we are also building useful, accessible HTML, etc
[15:58] <DSpaceSlackBot> <mwood> Sounds well. How do we gather input on what our standard should be, so that we know when the code passes the right test?
[16:00] <DSpaceSlackBot> <tdonohue> @mwood: that is exactly what I had asked for in the dspace-tech thread. I'd personally like to see a working group established. But, that requires interest (and someone willing to chair it). Without that, we'd have to go to DCAT or similar to see if they have thoughts, etc
[16:00] <DSpaceSlackBot> <mwood> To a certain extent this will be driven by various governments.
[16:00] <DSpaceSlackBot> <tom_desair> I know it is not the correct way of doing things, but I would also look at the tooling available for a certain standard. It’s better to follow a standard that we can automatically check, then to follow a standard which we have to manually validate every couple of months.
[16:01] <DSpaceSlackBot> <tom_desair> I’m not saying it should be the only criteria
[16:01] <DSpaceSlackBot> <mwood> We could wire the checker to Github PRs....
[16:03] <DSpaceSlackBot> <mwood> So, we should create some more noise on the -tech posting, and look for a ticket regarding tooling.
[16:03] <DSpaceSlackBot> <tdonohue> Yes, I'd appreciate others responding on the -tech posting. I didn't mean for my response to squash all discussion..I had hoped to help move it along
[16:04] <DSpaceSlackBot> <tdonohue> I'm noticing here that we are now over time. And it seems like we are wrapping this up a bit
[16:04] <DSpaceSlackBot> <tdonohue> I will create a ticket in `dspace-angular` about finding ways to automate accessibility testing
[16:04] <DSpaceSlackBot> <mwood> My current condition on this issue is "that's important, if only I knew enough about accessibility to help move it forward."
[16:05] <DSpaceSlackBot> <tdonohue> Right, which is why we need experts to come forward, possibly even via a Working Group, and help us draft these requirements. I don't know enough either of the "best standard" to move towards other than it being based on WCAG 2.0
[16:06] <DSpaceSlackBot> <mwood> I'll find my notes and send something about government requirements in my jurisdiction.
[16:06] <DSpaceSlackBot> <tdonohue> In any case, we are now over time here. So, I'd like to wrap up today's meeting...and we can bring this to -tech and/or the `dspace-angular` ticket (which I will create)
[16:07] <DSpaceSlackBot> <tdonohue> I'd like to wish you all a happy holidays & happy new year! As mentioned, I'll be offline as of next week...but will be back on Weds, Jan 3. I hope you all also get some time to relax!
[16:08] <DSpaceSlackBot> <tom_desair> Enjoy the holidays everyone!
[16:08] <DSpaceSlackBot> <mwood> Yeah, what he said!:point_up:
[16:13] * dyelar (~dyelar@dyelar.mrb.ku.edu) has joined #duraspace
[16:15] * dyelar (~dyelar@dyelar.mrb.ku.edu) Quit (Client Quit)
[16:25] * dyelar (~dyelar@dyelar.mrb.ku.edu) has joined #duraspace
[16:26] <DSpaceSlackBot> <tdonohue> DSpace 7 accessibility ticket created: https://github.com/DSpace/dspace-angular/issues/209 Posting this to the -tech thread as well
[19:16] * misilot (~misilot@p-body.lib.fit.edu) Quit (Quit: Leaving)
[19:18] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[22:06] * mhwood (~mhwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[22:34] * tdonohue (~tdonohue@dspace/tdonohue) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.