Timestamps are in GMT/BST.
[6:54] -sendak.freenode.net- *** Looking up your hostname...
[6:54] -sendak.freenode.net- *** Checking Ident
[6:54] -sendak.freenode.net- *** Found your hostname
[6:54] -sendak.freenode.net- *** No Ident response
[6:54] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:54] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:54] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[10:29] * helix84 (~ctenar@195.178.95.132) Quit (Remote host closed the connection)
[12:06] * jonathangee (~jonathang@142.68.37.238) Quit (Ping timeout: 260 seconds)
[13:38] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:58] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has joined #duraspace
[14:40] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) Quit (*.net *.split)
[14:43] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has joined #duraspace
[18:57] * helix84 (~ctenar@195.178.95.132) has joined #duraspace
[19:01] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[19:47] * KRR (~krr@libdhcp080.library.uiuc.edu) has joined #duraspace
[19:49] * KRR (~krr@libdhcp080.library.uiuc.edu) Quit (Remote host closed the connection)
[19:59] * kstamatis (2ebe5803@gateway/web/freenode/ip.46.190.88.3) has joined #duraspace
[20:01] * bollini (~bollini@host111-17-dynamic.53-79-r.retail.telecomitalia.it) has joined #duraspace
[20:01] <tdonohue> Hi All, it's time for our weekly DSpace Dev Mtg. https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-01-08
[20:01] <kompewter> [ DevMtg 2014-01-08 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2014-01-08
[20:02] <tdonohue> Today's agenda is mostly just some followups on ideas/discussions that we had prior to the holiday break. By the way, happy new year to everyone!
[20:03] * hpottinger throws some confetti, weeeee!
[20:04] <tdonohue> My first agenda item for today. Mostly just a simple question to all of you. Now that 4.0 is out, based on our "Support Policy", we now only officially support DSpace 1.8.x, 3.x and 4.x. So, I was wondering whether we feel it'd be worth announcing that "DSpace 1.7 is now EOL" on lists? (I'm fine doing the announcement)
[20:04] <hpottinger> yes, and hands up who's still running 1.7?
[20:04] <mhwood> Yes
[20:05] <helix84> I've seen one or two of them in the wild :)
[20:05] <tdonohue> I actually suspect there are a lot of folks still on 1.7 or below (not Committers though, I hope ;). So, this 1.7 EOL message would also be a friendly "reminder" that folks really should upgrade
[20:06] <kstamatis> we are still running 1.5 in one of our repositories :)
[20:06] <hpottinger> I've got a dark archive around here that's a few versions back
[20:06] <hpottinger> 1.5, kstamatis, is what our dark archive runs, too :-)
[20:07] <kstamatis> hpottinger: ok, just stopped feeling lonely
[20:07] <tdonohue> Ok. So, I'll draft up a 1.7 EOL message... and get it sent out to lists sometime this week. I suspect this is something we may want to do on a yearly basis...e.g. every January or February (after the most recent major release) we announce the latest EOL
[20:07] <hpottinger> it's a vanilla JSPUI repository, I'm planning to upgrade it first, to wow the archivists with all the fancy JSPUI improvements
[20:08] <tdonohue> (that way it's a yearly reminder to folks to "catch up" and upgrade their DSpace instance)
[20:08] <mhwood> Maybe the current support list should be part of the x.0 announcement.
[20:08] <helix84> Why not just add it to the release announcement for next major versions? Do we have a checklist for those?
[20:09] <tdonohue> mhwood: yea, it could be. I just worry it'd get "lost" in the release announcement. I think EOL is a "big deal" and needs to be a targeted (separate) email in order for folks to fully realize the implications to their local install
[20:09] <mhwood> tdonohue: point
[20:09] <hpottinger> +1 separate notice
[20:10] <helix84> I'm not convinced but I'm not going to veto :)
[20:10] <tdonohue> ok, so I'll get this 1.7 EOL sent out this week. As a subpoint in that email, I'll also remind folks about 4.0
[20:11] <helix84> thanks, Tim
[20:11] <tdonohue> no problem.
[20:12] <tdonohue> Ok, so we had two other discussion started just before our two week hiatus. I mostly just wanted to remind us of them, and see if anyone has had new/different ideas: (1) Requiring Docs before a PR can be merged, and (2) The "Let's Talk about Features" meeting every 3rd week of the month idea.
[20:13] <tdonohue> I think with #1 (Requiring Docs for a PR), it sounds like committers seem mostly in favor. So, it likely just needs to be written up as a policy, run past committers, & put to a vote
[20:15] <tdonohue> #2 ("Let's talk about features") was brainstormed as a way to get us all communicating earlier on about what features we'd like to see or work on for 5.0. It still seems like it might be worth trying, unless others object or have other ideas
[20:15] <bollini> I'm just worried about add a barrier to contribution
[20:16] <mhwood> Documentation: if you need help, get help. Volunteers are standing by.
[20:16] <bollini> it is not really true...
[20:16] <tdonohue> I'd rather "add a barrier to contribution" (by requiring docs for a PR), than "add a barrier towards releasing" (by not having docs needed to actually describe the new features)
[20:16] <mhwood> tdonohue++
[20:17] <bollini> for 4.0 we have add documentation for at most anything after the feature freeze
[20:17] <kstamatis> maybe is shouldn't be a barrier, it should be a point for us to consider some contributions in priority than others
[20:17] <tdonohue> bollini: yes, but with 4.0, we also had a mad scramble (for those who aren't aware) the last few weeks when we noticed gaps in 4.0 docs (features which were added that were never documented)
[20:18] <tdonohue> with 4.0, it also seemed like it became overly difficult to track down which features had been documented vs. which had not.
[20:19] <helix84> There are still docs for some smaller 4.0 features missing. It's harder to add them after the fact by someone other than the contributor because I'm not familiar with the feature.
[20:19] <hpottinger> so, we have an additional PR management data point: has_docs?
[20:19] <tdonohue> essentially, the route of "waiting to add docs till after feature freeze" is very beneficial to contributors..but it puts added strain on the Release Team to determine which features still don't have docs
[20:19] <bollini> yes, there are something that are not yet documentated but personally I prefer to have some functionalities in without documentation that keep a PR stale for long time waiting for the next release
[20:20] <helix84> hpottinger: there already is such indicator in Jira, I'm just not sure wemeticulously keep an eye on it.
[20:20] <tdonohue> hpottinger: we actually already have a "has documentation" field in JIRA which is a selectbox of options. We just haven't used it well.
[20:20] <bollini> we just need to keep "some" lower and try to get the documentation sometime
[20:21] <mhwood> If it's not documented, how do we know it exists?
[20:21] <tdonohue> mhwood++
[20:21] <bollini> I want to try a positive approach, don't create barrier to merge create benefit to provide documentation
[20:21] <helix84> another point to consider: It's actually easier for the commiters to review a feature that is documented
[20:22] <tdonohue> helix84++
[20:22] <mhwood> helix84++
[20:22] <hpottinger> my point is, at some point in the release process the RT has a big pile of PRs to sort through, and we approve them based on the merits of the code and whether it has been tested/verified
[20:22] <helix84> so the incentive has always been there, yet the documentation is still lacking
[20:22] <bollini> no one is saying that documentation is a wrong thing
[20:23] <hpottinger> presence of documentation, unfortunately, hasn't yet fit into that process of PR review
[20:23] <bollini> if you give me an extra week or two after a feature freeze for new PR that have documentation I will write much more documentation
[20:23] <mhwood> Why should a need for documentation make code go stale? IIRC several of us volunteered to help contributors document.
[20:23] <helix84> let's be honest - it's not so hard to write two paragraphs of documentation. we don't have to require a full page, but IMHO we should require minimal documentation.
[20:24] <tdonohue> bollini: no one is saying the documentation needs to be *perfect* before a PR can be merged. My proposal was that "*Minimal* Documentation is required before a PR be merged". Docs can & should be enhanced later on.
[20:25] <bollini> have we some new functionalities that are not already minimal documentated in the PR or the JIRA comments?
[20:25] <helix84> as minimal documentation I'd see brief paragraph on purpose of the feature, location in the UI/command line and brief description of any configuration options
[20:26] <mhwood> PR or Jira often doesn't say *how to use* the feature.
[20:26] <tdonohue> bollini: yes. we do get features that sometimes fail to describe the new configs that have been added, or even fail to describe how to enable/disable the new feature (if that is possible).
[20:27] <tdonohue> bollini: as an example, see my recent questions to -commit about the "PDF Thumbnail rendering". It's configs are missing from dspace.cfg by default & are not explained well anywhere...it's unclear how to use or enable it
[20:28] <tdonohue> there are other features like that (mostly smaller features which added new configs) which are in a similar situation in terms of documentation
[20:28] <helix84> bollini: here's an example. I didn't know the answer. Luckily, you did: http://dspace.2283337.n4.nabble.com/Discovery-Spell-Checker-td4670052.html
[20:28] <kompewter> [ DSpace - Tech - Discovery Spell Checker ] - http://dspace.2283337.n4.nabble.com/Discovery-Spell-Checker-td4670052.html
[20:29] <bollini> Ok, I'm only guessing that in some point on the PR or in the jira issue we have said that there is a configuration properties, a batch class etc.
[20:30] <bollini> if we ask for documentation before merge most people will read it as a well written document
[20:30] <helix84> we have a label for issues that change configuration, so it's easy for the RT to check whether they're documented
[20:31] <mhwood> The sketch in the PR / Jira would still need to be copied to the Official Documentation and perhaps reorganized a bit.
[20:32] <tdonohue> I'm suggesting here that we write up a doc on the wiki that describes what sort of documentation we require before merging. Then, we use that when reviewing PRs & link that that doc if a PR is lacking some key piece of documentation.
[20:32] <mhwood> My point is that, if I want to know what DSpace can do, I go to the Confluence or PDF doco. If it's not in there, I assume it's not in DSpace.
[20:33] <tdonohue> The secondary issue here is what mhwood mentions. Even if the contributor adds explanation or docs to JIRA/PR, *someone* needs to make sure that gets on the wiki as well. That's still a problem we'll need to solve
[20:33] <helix84> hey, didn't we draft a documentation template recently?
[20:33] <tdonohue> bram drafted something
[20:34] <tdonohue> https://wiki.duraspace.org/display/DSDOC/New+Contribution+Template (from bram)
[20:34] <kompewter> [ New Contribution Template - DSpace Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC/New+Contribution+Template
[20:35] <bollini> I'm still conviced that is better give a benefit to whom provide documentation that saying you must provide documentation
[20:35] <mhwood> What would you give him?
[20:35] <bollini> more time
[20:36] <mhwood> Time is what the RT has the least of.
[20:36] <bollini> ok, we can give less time to the other... but let me say more time :-)
[20:36] <mhwood> I will admit that, if I have not done something, and you give me more time, it will take as much more time as you give me. :-(
[20:38] <tdonohue> the common occurrence each year seems to be that the RT is stuck with documenting some things that are not documented (sometimes at the last moment). There's already enough other docs that the RT needs to ensure get done (install / upgrade / release notes) that it'd be better if we can ease the burden on the RT
[20:39] <hpottinger> mhwood, wait, by that math, you already have enough time
[20:40] <tdonohue> so, it's either we require more docs on submission (before PR gets merged), or we find some sort of "documentation team" that is willing to write all these docs for submitters/contributors & can take that burden away from the RT (but not sure how plausible that really is)
[20:40] <bollini> I know that the RT need to work a lot of work in the last days but I'm not sure that make a rule can improve that
[20:40] <bollini> have a documentation template work much better
[20:42] <tdonohue> nothing is going to be perfect :) We change our policies/rules all the time, so it's a matter of trying different options to see what may work. I agree we'd want a documentation template to go along with this idea
[20:44] <tdonohue> In any case, I think the next steps are to work out more of the details here: e.g. draft up a policy, help on that "documentation template" that bram started. Then, we can bring this to an official vote.
[20:45] <bollini> https://jira.duraspace.org/issues/?jql=project%20%3D%20DS%20AND%20%22Documentation%20Status%22%20%3D%20%22Needed%22%20and%20fixVersion%20%3D%20%224.0%22
[20:45] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/issues/?jql=project%20%3D%20DS%20AND%20%22Documentation%20Status%22%20%3D%20%22Needed%22%20and%20fixVersion%20%3D%20%224.0%22
[20:47] <bollini> it looks as our documentation status flag is most of time not updated
[20:47] <bollini> (I hope so... otherwise we have miss much documentation)
[20:48] <mhwood> Imagine how often it is just wrong, because someone overlooked it.
[20:48] <tdonohue> yes, we don't do a good job up updating that status flag. I think that status flag also defaults to "needed"
[20:49] <tdonohue> in any case, that's proof that we have a documentation problem here. How can the RT be expected to look through all 62 of those tickets and try to cross-check the latest Docs to see if there is proper documentation?
[20:49] <bollini> if we have many people that like to volunteer for documentation it will be very nice to have a documentation team that at least assue that this flag is correct for the outcoming version
[20:50] <hpottinger> I think a link to documentation in the PR would help
[20:51] <bollini> one of the problem with is that we use two different system, JIRA and GitHub PR
[20:51] <bollini> we miss often to keep them in sync
[20:52] <tdonohue> bollini: the problem we have with establishing a "documentation team" is finding enough folks to fill *both* a release team and a documentation team (without relying too much on the same people). I recall several years ago we tried to setup a Documentation Team (with Jeff Trimble as the lead) and it didn't ever get off the ground, unfortunately.
[20:53] <tdonohue> If we want to try again on creating a "documentation team" we can try again. Just noting that past attempt
[20:54] <mhwood> One difficulty is that the person who knows what to document, and that in fact documentation is needed, is the contributor. A separate team has great difficulty discovering these.
[20:54] <tdonohue> mhwood: I agree.
[20:56] <tdonohue> A part of me feels like DSpace should be teaching people to be "better open source developers". Part of "Open Source Development" is also ensuring your stuff is documented. There are too many OSS projects out there that have horrible documentation (I'm sure you all can think of 10 off the top of your head). I'd rather not DSpace be one of them. :)
[20:57] <bollini> tdonohue: wait, we are not in such situation (fortunately). Big feature areat least minimal documented
[20:57] <mhwood> If a big feature was not documented, how would we know?
[20:58] <hpottinger> complaints :-)
[20:58] <tdonohue> bollini: Big features for DSpace tend to be documented, I agree (mostly cause we pay the most attention to those big features). The gaps usually are in the small/medium features -- the ones that added 1-2 new configs or changed something ever so slightly
[20:58] <mhwood> Who would know to complain?
[20:58] <hpottinger> in my experience we have a very vocal community
[20:59] <bollini> if we have a big PR what we do? we are doing review... and if we have no documentation at all we are not able to review big feature
[20:59] <bollini> we *only* need to improve further our situation and keep the release process (and RT work) manageable
[21:00] <tdonohue> bollini: if you notice the early draft policy I sent to -commit... I had a statement at the end: "Individual exceptions to this policy can be made by the Release Team and/or a vote of the Committers team."
[21:00] <bollini> ok, I want do the devil job here
[21:01] <tdonohue> bollini: So, I expect there may be situations where there is large new feature, from a trusted committer/developer that we may want to "accept with no docs" provided that that person promises docs very soon thereafter. But, I hope those become the *exceptions* and not the *norm*
[21:01] <bollini> I read that in this way, the committers team can agree that PR that come from trusted developer (the committers) can be documented later
[21:03] <bollini> my first goal for an OSS project is to have as much as contributors is possible
[21:04] <tdonohue> So, I think the next step here is to re-start this discussion on -commit. Post up a new draft of the "Documentation before a PR can be merged" policy, and start to enhance Bram's initial documentation template
[21:05] <hpottinger> +1 I like that plan
[21:05] <tdonohue> Then we would vote on it...assuming it passes, we announce it to -devel & -tech and make sure folks understand what the new requirements may be
[21:06] <bollini> anyway, I don't think to place a veto on a future vote... I only want to be sure that we work more trying to keep things easier for contributors than defining rules and procedures. So I really appreaciete in this sense the Bram's template.
[21:06] <tdonohue> yes, makes perfect sense bollini
[21:07] <tdonohue> I'll try and restart this discussion in the next few days on -commit
[21:07] <bollini> can we dedicate the next backlog hour to review the documentation status flag for the 4.0 issues?
[21:08] <bollini> assuming that the issue that has something different than the default are right we have to check 60 issues
[21:08] <tdonohue> bollini: do you mean you want to review 4.0 issues marked as "docs needed" to verify if they actually have docs?
[21:08] <bollini> yes
[21:09] <bollini> so that we know what is missing
[21:09] <hpottinger> bollini requests to stare the monster in the face :-)
[21:09] <tdonohue> not sure that we'll get through *all* of them in one hour. But, we can try :)
[21:09] <bollini> a such meeting should be scheduled as part of the final meeting pre-release
[21:10] * tdonohue wonders out-loud if we should be creating a "Release Team Schedule Template" somewhere?
[21:11] <hpottinger> good idea, tdonohue
[21:12] <tdonohue> Would the 4.0 RT members be willing to start such a thing? I'd be glad to chip in, but I feel like you all may have it more "fresh" in your minds
[21:12] <mhwood> I would suggest such a meeting happening earlier. By the time new code is frozen, we should have draft documentation or a commitment to a date.
[21:12] <tdonohue> mhwood++
[21:12] <bollini> mhwood++
[21:12] <hpottinger> only thing fresh in my mind is that I just upgraded my Vagrant version from 1.3.5 to 1.4.2
[21:13] <mhwood> I can help with an RT Schedule Template.
[21:13] <bollini> I don't want write documentation for the next 30 days :-) ... we are working hard to supply a full manual for dspace-cris
[21:14] <tdonohue> Well, I suspect the 4.0 RT might have strong ideas about what things should be done "earlier" rather than "at the last moment"....it need not be a strict schedule...just something that the 5.0 RT can use as a reference, and hopefully avoid the same stumbling blocks
[21:14] <tdonohue> thanks mhwood!
[21:14] <mhwood> May we ask you specific questions to refresh our memories, bollini?
[21:15] <bollini> of course, I will also take a look to an initial draft and fill it as needed
[21:15] <bollini> s/of course/sure/
[21:15] <kompewter> bollini meant to say: sure, I will also take a look to an initial draft and fill it as needed
[21:16] <mhwood> OK, I can gather the ideas and write a draft, but it needs some discussion to get it started.
[21:17] <tdonohue> I know we are over time here...one final quick question: Do we want to do anything regarding the "Let's talk about features" meeting idea or set it aside for the time being? Next week is the 3rd meeting of the month, but I'm not sure we're ready to jump in yet...I still feel like we are working to "wrap up 4.0" and see when 4.1 may be coming.
[21:18] <bollini> we should announce the idea early, so to collect some features before the meeting
[21:18] <tdonohue> I like the idea of having a "let's talk about features" meeting each month. But, not sure we are quite ready to talk 5.0 features yet?
[21:18] <bollini> so if we announce that for the 3rd meeting in February we can start collecting idea
[21:19] <hpottinger> when are we ever ready to talk about new features?
[21:19] <hpottinger> did I just type that? :-)
[21:19] <mhwood> Problematically, the answer often is "when they are ready". Hence the meetings.
[21:20] <hpottinger> I honestly didn't mean that to sound as snarky as it came out, as mhwood notes, we have a built-in bias "my work isn't ready"
[21:21] <tdonohue> Ok, so I think I'm going to wait on any "Let's talk about features" announcement this week. It seems too far in advance of Feb 19 (3rd week of Feb).
[21:21] <mhwood> I agree that some advance notice is beneficial. People need some time to think about questions like "what do you want to put into DSpace" or "what would you put into DSpace if you could get some help?"
[21:22] <bollini> ok, let me say it in a different way... if I know that we have a predefined slot to talk on new feature I will try to summarize the idea that I'm working on. If I know that I can do it when I will be ready I will be never ready
[21:23] <mhwood> So the meetings are to invite people to talk about what they are doing or would like to do.
[21:23] <bollini> yes, and we should assure that the committer will try to give a direction and an early evaluation of the idea
[21:24] <hpottinger> I think waiting until February is fine, we should stick to it, though
[21:24] <bollini> I'm sorry but I need to leave in 5minutes
[21:24] <helix84> I'd like to point out that we probably have "new" features in Jira, so we might want to take a look at them and notify their developers to come and talk
[21:24] <tdonohue> Yes, I think this meeting would be more about inviting Developers/Committers to talk about what they are building / have built / want to build.
[21:25] <mhwood> Sometimes I post something to Jira and then let it sit for a while in the hope of seeing comments. These meetings are probably a better way. :-)
[21:26] <tdonohue> Ok, I don't have any other topics for today. So, we can close up the official meeting at this point. I'll be around for a while though if folks have informal stuff to chat about
[21:27] <bollini> bye
[21:27] <kompewter> bye!
[21:28] * bollini (~bollini@host111-17-dynamic.53-79-r.retail.telecomitalia.it) has left #duraspace
[21:28] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has left #duraspace
[21:29] <mhwood> I see 28 New Feature issues in either Received or Accepted, for all versions.
[21:29] * kstamatis (2ebe5803@gateway/web/freenode/ip.46.190.88.3) has left #duraspace
[22:04] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:43] * kshepher1 is now known as kshepherd
[22:54] * tdonohue (~tdonohue@c-50-179-112-246.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.