Timestamps are in GMT/BST.
[6:39] -zelazny.freenode.net- *** Looking up your hostname...
[6:39] -zelazny.freenode.net- *** Checking Ident
[6:39] -zelazny.freenode.net- *** Found your hostname
[6:39] -zelazny.freenode.net- *** No Ident response
[6:39] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:39] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:39] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[9:14] * kompewter (~kompewter@sul272sandbox.lib.ohio-state.edu) Quit (Ping timeout: 245 seconds)
[12:06] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:23] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[14:38] * scottatm (~scottatm@adhcp218.evans.tamu.edu) has joined #duraspace
[14:41] * tdonohue1 (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[14:41] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Disconnected by services)
[14:42] * tdonohue1 is now known as tdonohue
[15:23] * tdonohue1 (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[15:23] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Disconnected by services)
[15:23] * tdonohue1 is now known as tdonohue
[16:06] * tdonohue1 (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[16:06] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Disconnected by services)
[16:06] * tdonohue1 is now known as tdonohue
[16:16] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[16:17] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[16:26] * tdonohue1 (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[16:26] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Disconnected by services)
[16:45] * Jose__ (8dd32b9d@gateway/web/freenode/ip.141.211.43.157) has joined #duraspace
[16:45] <Jose__> This is the office hour chat, right?
[16:55] <Jose__> tim are you there?
[16:55] <tdonohue1> Hi Jose__ : yea, office hours starts in about 5 mins. I just got back to my computer.
[16:55] <tdonohue1> but, feel free to go ahead and ask whatever question(s) you have. I'm here now
[16:56] * tdonohue1 office hours is starting: https://wiki.duraspace.org/display/~tdonohue/DSpace+Office+Hours
[16:56] * tdonohue1 is now known as tdonohue
[16:56] <Jose__> Sorry ... I had it in my mind that it was 1pm.
[16:58] <tdonohue> (FYI to all -- my internet has been a little unstable today. Not sure why. So, I apologize in advance if I accidentally drop out for brief moments during office hours.)
[17:00] <Jose__> My question... In manakin, I want to do what Ideals does when it diesplays a browse result, that is, specifially give the user the ability to go directly to the pdf file. This can get kind of complicated if done correctly - showing an appropriate icon for the file type. I contacted Bill from Ideals and have not heard back, but I'm wondering if you or any one knows of some code out there I could use?
[17:02] <tdonohue> looking around at IDEALS (www.ideals.illinois.edu) to refresh my memory here...
[17:06] <tdonohue> IIRC, I think that's basically just pulling info out of the METS (generated by XMLUI) to get the type of the file marked as the "primary bitstream". It just happens that in most cases, there's just one bitstream which is a PDF
[17:07] <tdonohue> So, for example, on the homepage...there's several "Recent Additions": http://www.ideals.illinois.edu/ (all happen to link directly to the PDF).
[17:08] <tdonohue> Here's the first one listed "Front Matter" (to some issue of a journal): http://www.ideals.illinois.edu/handle/2142/31370
[17:08] <tdonohue> It's DRI XML can be grabbed at: http://www.ideals.illinois.edu/handle/2142/31370?XML
[17:09] <tdonohue> In the DRI, you can get the link to the METS file...which happens to be at: http://www.ideals.illinois.edu/metadata/handle/2142/31370/mets.xml
[17:10] <tdonohue> In the METS File, there's a <mets:structMap> section, which includes a <mets:fptr> that points at the "primary" bitstream. In this example it looks like: <mets:fptr FILEID="file_104452"/>
[17:11] <tdonohue> Then, taking that FILEID value, you can see it points back up at the PDF document (which has a <mets:file> tag where ID="file_104452"
[17:12] <tdonohue> That's the general *concept* of it. But, I don't have access to the latest IDEALS code anymore. This is a theme customization in the IDEALS site
[17:13] <Jose__> Ok, I can try it from here. Thanks!
[17:14] <tdonohue> sure thing. You could also try to email Sarah Shreeves @ Illinois. Hopefully Bill will answer you soon though
[17:15] <Jose__> This can get messy, and was hoping I could just cut and paste.
[17:17] <tdonohue> yea, it probably does get a bit messy. I think the best option would be to ask someone at Illinois to share the code. Unfortunately, I don't think their code is in a public location (a place where it is publicly readable). If they moved it over to GitHub, it'd be so much easier to share / borrow code
[17:17] <tdonohue> (This is part of the motivation to get institutions to think about using GitHub. It becomes much easier for everyone to share cool additions to themes, etc.)
[17:18] <tdonohue> Some DSpace Sites have already started to share their Themes up at: https://wiki.duraspace.org/display/DSPACE/Repository+of+XMLUI+themes
[17:24] <Jose__> Cool, I'm taking a look right now.
[18:03] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[18:43] * PeterDietz (~peterdiet@128.146.173.59) Quit (Remote host closed the connection)
[18:55] * Jose__ (8dd32b9d@gateway/web/freenode/ip.141.211.43.157) Quit (Quit: Page closed)
[19:51] <tdonohue> Hi all, reminder that our DSpace Developer Mtg starts at the top of the hour : https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-06-06
[19:51] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[19:57] * helix84 (a@195.113.97.174) has joined #duraspace
[20:00] * sands (~sandsfish@18.189.31.239) has joined #duraspace
[20:00] <tdonohue> Hello everyone. It's now time for our weekly DSpace Developers meeting. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-06-06
[20:00] <helix84> ++++
[20:00] <helix84> sorry
[20:00] <tdonohue> As always, we'll start with some JIRA reviews for today
[20:00] <tdonohue> https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-1038+ORDER+BY+key+ASC
[20:01] <tdonohue> kicking things off with DS-1038
[20:01] <tdonohue> (oh, no kompewter today)
[20:01] <tdonohue> https://jira.duraspace.org/browse/DS-1038
[20:02] <mhwood> Sounds like a bug to me.
[20:02] <tdonohue> Yea, I think the bundle should be auto-removed if there's no remaining bitstreams
[20:03] <tdonohue> (no reason to keep around empty bundles)
[20:03] <tdonohue> anyone interesting in looking into this?
[20:03] * kompewter (~kompewter@sul272sandbox.lib.ohio-state.edu) has joined #duraspace
[20:04] * PeterDietz (~peterdiet@128.146.173.59) has joined #duraspace
[20:04] <tdonohue> (hey look it's PeterDietz & kompewter!)
[20:04] <tdonohue> no volunteers for DS-1038 then?
[20:04] <kompewter> [ https://jira.duraspace.org/browse/DS-1038 ] - [#DS-1038] CLI itemupdate does not remove empty bitstream bundles. - DuraSpace JIRA
[20:05] <hpottinger> I can take a look, I've been tinkering with ItemUpdate anyway
[20:05] <tdonohue> Ds-1038 Summary: Several of us agree this sounds like a bug. hpottinger will look into it. (Thanks Hardy!)
[20:06] <tdonohue> next up, DS-1039
[20:06] <kompewter> [ https://jira.duraspace.org/browse/DS-1039 ] - [#DS-1039] Item view in Mirage theme broken when ORIGINAL or CONTENT bundle present and empty - DuraSpace JIRA
[20:06] <KevinVdV> I can look into this one if nobody objects ?
[20:07] <mhwood> Probably should be fixed both ways: the theme should handle empty bundles, but there shouldn't *be* empty bundles.
[20:07] <tdonohue> sounds good KevinVdV, thanks!
[20:07] <tdonohue> Ds-1039 Summary: sounds like a bug. KevinVdV will investigate
[20:08] <KevinVdV> I'll add mhwood's comment & look into that also
[20:08] <tdonohue> next up, DS-1040
[20:08] <kompewter> [ https://jira.duraspace.org/browse/DS-1040 ] - [#DS-1040] Discovery results, sorted by title, should ignore stop words in sort - DuraSpace JIRA
[20:08] <mhwood> Thinking that Ds-1038 and Ds-1039 are somewhat related.
[20:08] <KevinVdV> True mhwood ....
[20:09] <KevinVdV> Ps: I'll also take DS 1040 since it is discovery
[20:09] <tdonohue> mhwood -- very loosely related, mhwood. Though there may be other ways that "empty bundles" happen. So, fixing Ds-1038 doesn't necessary fix Ds-1039
[20:09] <tdonohue> whoops, mentioned mhwood multiple times there mhwood mhwood ;)
[20:09] <tdonohue> ok, thanks again KevinVdV
[20:10] <mhwood> Loosely, yes, but the issues' owners should talk.
[20:10] <tdonohue> Ds-1040 Summary: KevinVdV will investigate
[20:10] <tdonohue> next up, DS-1043.
[20:10] <kompewter> [ https://jira.duraspace.org/browse/DS-1043 ] - [#DS-1043] 'ant help' refers to 'install_code' target which does not exist - DuraSpace JIRA
[20:11] <tdonohue> Anything that needs assistance here, mhwood? I see you have this one claimed
[20:11] <mhwood> Assigned to me and I need to get back to it.
[20:11] <tdonohue> ok, we'll skip for now then. Let us know if you need any support
[20:11] <tdonohue> next up, DS-1046
[20:11] <kompewter> [ https://jira.duraspace.org/browse/DS-1046 ] - [#DS-1046] Add metadata export for community and collection managers - DuraSpace JIRA
[20:11] <mhwood> Thanks! Probably I just need to note that nobody objected so I can proceed.
[20:13] <mhwood> 1046 looks like yet another special case of We Need Finer-Grained Permissions.
[20:14] <hpottinger> re 1043, mhwood, if you want a test of your patch, I can prioritize testing, or I can wait for the pull request and test that.
[20:14] <mhwood> hpottinger: thanks, I'll be in touch when I have something ready.
[20:15] <tdonohue> It sounds like 1046 may just require enabling the metadata export link for comm/coll admins? That seems like it might not be that hard (unless I'm overlooking something)
[20:17] <mhwood> That would work, I think. But we keep having requests like this all over, and if we can ever get around to reworking the permissions then they all go away -- you just set your permissions properly and people get what they are supposed to have.
[20:18] <mhwood> So, for a quick fix, yes, just wire that permission into the code. But there's a more general fix, which I try to bug us all about at suitable intervals....
[20:19] * hpottinger thinks this would be a good use of a business rules engine...
[20:20] <mhwood> Yup, but it starts with staring at the data model and writing out a list of what could and should have separate permissions.
[20:20] <tdonohue> one of the oddities about the "Export Metadata" functionality is that it's actually only available when visiting a community or collection page (then it's in the XMLUI Context menu). It seems odd then that only a full SysAdmin can use it. Usually the SysAdmin tools are under "XMLUI Administrative" menu
[20:20] <mhwood> Point.
[20:21] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:21] <tdonohue> But, on the flip-side, the "Import Metadata" option is in the XMLUI Administrative menu (which *is* SysAdmin specific). So, all in all, this is slightly odd
[20:22] <mhwood> Yes, it should be made less odd.
[20:22] <mdiggory> Hi everyone, sorry I'm late :-)
[20:24] <tdonohue> So, for Ds-1046, I'd be OK with giving Community/Collection Admins ability to export metadata. But, it does then seem slightly odd that they cannot import it again -- but as that's the more dangerous task, perhaps that's OK
[20:24] <mhwood> Not odd that read/write permissions are different, but that they are in two such different places.
[20:25] <mdiggory> Seems like a job for delegated administration to determine
[20:25] <mhwood> Hence my usual rant about finer-grained permissions.
[20:25] <tdonohue> I'm assuming this must not be covered by the delegated admin tools that are already available
[20:26] <helix84> just a comment - i often give different people the csv with metadata to edit, but i'm the only one who ever does the import, and I always look at the diff. so this is definitely a valid use case.
[20:27] <tdonohue> maybe we just need a few new delegated admin configs: 'core.authorization.collection-admin.export-metadata = true/false' and 'core.authorization.community-admin.export-metadata = true/false'
[20:28] <mhwood> If we're going to make it configurable, push it into the authz model instead of proliferating dspace.cfg stuff.
[20:29] <tdonohue> mhwood -- although I agree conceptually (for long term), all the other "delegated admin auth" stuff is already in dspace.cfg. So, I was just maintaining consistency for now
[20:29] <mhwood> OK, I'm not familiar with that bit.
[20:30] <tdonohue> but, once the other 'delegated admin auth" stuff is moved out of dspace.cfg, then, yes, I agree
[20:30] <tdonohue> This is the stuff in dspace.cfg : https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg#L319
[20:30] <kompewter> [ DSpace/dspace/config/dspace.cfg at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace/config/dspace.cfg#L319
[20:30] <mdiggory> delegated administration represents "actions" that a user role can perform...
[20:31] <tdonohue> so, it seems like we just need a new configurable action for now -- an "export-metadata" action.
[20:31] <mdiggory> Let me ask a tough question here... delegated admin actually controls exposure of UI interfaces, but does it actually result in testing the users ability to alter the data model and run the "business logic" that the UI interacts with?
[20:32] <tdonohue> I think the answer is *yes* (it actually blocks users in the business logic as well). But, I could be wrong (been a while since I looked at the code)
[20:32] <mhwood> A good point. We shouldn't be controlling access through UI exposure, because we have scads of UIs and they tend to diverge.
[20:33] <mdiggory> https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/authorize/AuthorizeConfiguration.java
[20:33] <kompewter> [ DSpace/dspace-api/src/main/java/org/dspace/authorize/AuthorizeConfiguration.java at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/authorize/AuthorizeConfiguration.java
[20:34] <tdonohue> In any case, we've spent a large amount of time on this one topic :)
[20:34] <tdonohue> there's a lot of great info here though -- need to add to the notes of Ds-1046
[20:34] <tdonohue> Anyone interested in looking more closely at Ds-1046?
[20:35] <tdonohue> (i.e. anyone want to build out this use case)
[20:37] <tdonohue> ok. hearing none right now. Ds-1046 Summary: We brainstormed this out for a bit. (Notes need to be posted to ticket). Needs a developer volunteer to investigate / implement
[20:37] <tdonohue> gonna stop our official JIRA review there for today.
[20:38] <tdonohue> on to other topics. Quick reminder that if you have suggestions for topics at the OR12 DSpace Dev meeting add them to https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-07-09+-+OR12+Meeting
[20:38] <kompewter> [ DevMtg 2012-07-09 - OR12 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-07-09+-+OR12+Meeting
[20:38] <tdonohue> Also, signup there if you plan to attend. We need to make sure we have a properly sized room :)
[20:38] <mdiggory> just one last comment on above... AuthorizeConfiguration is used by AuthorizeUtil and the primary DSO objects
[20:39] <hpottinger> If you *are* going to OR12, please fill out your Crowdvine profile, too, not many of us DSpace folks in there yet...
[20:39] <tdonohue> mdiggory : good to know. So, as expected, it is used down in the API/business logic and not up in the UI-layer
[20:39] <tdonohue> hpottinger: is there a link to the crowdvine somewhere?
[20:40] <hpottinger> http://or2012.crowdvine.com/
[20:40] <kompewter> [ Open Repositories 2012 - Home (CrowdVine) ] - http://or2012.crowdvine.com/
[20:40] <tdonohue> thanks :)
[20:41] <mdiggory> tdonohue: very last comment.... AuthorizeUtil is used throughout the UIs
[20:41] <tdonohue> Ok. we've spent a good time on JIRA today. But, I did want to touch back on topics from last week. Namely we had talked briefly on how our JIRA backlog doesn't seem to get smaller (in fact it's getting bigger) & if there may be ways to speed up some of this process
[20:42] <tdonohue> After today's work (up through Ds-1046), our current JIRA backlog is at 88 unreviewed tickets
[20:42] <mhwood> In the beginning, each issue got one minute, and if there was consensus it could have another minute. Nowadays we tend to go silent for longer than 2min. sometimes.
[20:43] <mdiggory> give out an new ipad for every JIRA task that gets closed.
[20:43] <tdonohue> mdiggory : you are going to give us all ipads? really, that sounds great?
[20:43] <PeterDietz> I'd rather get a gently used iPad, save the planet
[20:43] <tdonohue> err.. that sound great!
[20:43] <hpottinger> dunno about paying for bugs...
[20:44] <tdonohue> mhwood -- yea, I wondered if we need to go back to that old model. I've been less strict about 1min per issue thing
[20:44] <mdiggory> oh no... whatd I get myself into....
[20:44] <tdonohue> I will note that we are running essentially 6+ months behind. We just reviewed Ds-1046, which was opened on Oct 4, 2011
[20:44] <tdonohue> i.e. that's not so good
[20:45] <hpottinger> I wonder if there would be a way to weight the issue list?
[20:45] <mdiggory> how many unreviewed issues are there?
[20:45] <sands> (votes)
[20:45] <tdonohue> mdiggory: at this time, 88
[20:45] <mhwood> Hmmm, I thought the purpose of the JIRA review was to prevent starvation. Weighting tends to promote starvation.
[20:46] <helix84> How about every week a developer gets "cleanup duty" to triage that week's bugs. Then at DevMtg, they can be looked at closer.
[20:46] <tdonohue> +1 mhwood. I worry about "votes". It's possible that a small bug will get no votes, even if it has a quick fix / provided patch
[20:46] <mdiggory> but only 51 assigned to 3.0
[20:47] <sands> tdonohue: only if we are a slave to the votes, which i'm not advocating. the question was whether there was a way to weight them. that seems to be a solution to that problem. it's just a unit of measurement. *shrug*
[20:47] <helix84> (that was a different developer each week, e.g. assigned at DevMtg to prevent his unavailability)
[20:48] <tdonohue> I've been wondering if there is a way we can do something more like "split up" the queue just to do a quick review & catchup
[20:49] <tdonohue> the "cleanup duty" thing could also work, if others liked it
[20:49] <tdonohue> by "split up" though...I mean this..
[20:49] <helix84> tdonohue: the problem is not only with the queue, but also with stale bugs that have been reviewed
[20:49] <mdiggory> I think we should maybe organize on "bug" vs "feature request" or attempt to organize out some of the "I just had this great idea" tasks
[20:49] <tdonohue> 1. each person take N tickets (where N=5 or 10)
[20:50] <tdonohue> 2. do a very quick review of those tickets & essentially "rank it" (either claim it, flag it for 3.0, or somehow mark it as needing more discussion -> in which case it gets discussed in these meetings)
[20:51] <tdonohue> basically, the first issue is that I think the queue gets huge cause we discuss all issues in this meeting (even if the issue is a tiny bug with a patch that could just be flagged / committed for 3.0)
[20:52] <mdiggory> right
[20:52] <mdiggory> 2.b. make sure it classified appropriately as bug or new feature
[20:52] <tdonohue> helix84: yea, I agree about the stale bugs also being an issue. but, in a way, if we can manage the queue, we can also "refresh" stale bugs back into the bigger queue
[20:53] <tdonohue> mdiggory -- true. as part of the quick review, you could do a quick clean up the metadata (the type of ticket, etc.)
[20:53] <mdiggory> I just noticed we have "boards" like "planning", "rapid", "task"
[20:53] <sands> there are also tags in JIRA, so we could subdivide without making separate queues if we wanted to...
[20:54] <mdiggory> https://jira.duraspace.org/secure/TaskBoard.jspa?selectedProjectId=10100&selectedBoardId=10543
[20:54] <kompewter> [ DSpace - Task Board - DuraSpace JIRA ] - https://jira.duraspace.org/secure/TaskBoard.jspa?selectedProjectId=10100&selectedBoardId=10543
[20:54] <tdonohue> yes, there are tags (called "labels") that we could take more advantage of
[20:55] <mhwood> I'd be willing to commit to a best effort to reviewing a small number each week. Maybe someone could just assign a few issues to each volunteer, still in the Received state. A volunteer reviews Assigned+Received and must move each to another state, whether Assigned+Open (he keeps it), Closed (unactionable issue), or something else.
[20:56] <mhwood> I'm thinking, how do we coordinate so that we don't have four people reviewing the same issue.
[20:57] <tdonohue> mdiggory -- yea, that "TaskBoard" is a feature of the new "agile development" GreenHopper plugin for JIRA.
[20:57] <mdiggory> perhaps the release team might consider adopting the Boards in JIRA as a means to track and organize the important issues that should be factored into planning for 3.0?
[20:57] <tdonohue> mhwood: That's why I was talking about "splitting up" the queue. Essentially, we'd want to each take different issues. For example, I could say "I'll take the first 10 in the queue", and then someone could take the next 10, etc.
[20:58] * mhwood wonders if JIRA could automate that somehow.
[20:58] <sands> mdiggory: i'm not familiar with the functionality, but sounds like it's worth the RT looking at.
[20:58] <tdonohue> mdiggory: I think that the boards, although useful, don't let us lessen the queue of *unreviewed* tickets. The unreviewed tickets haven't even been scheduled for 3.0 as they haven't yet been reviewed
[20:58] <helix84> I don't think it's a good idea to take issues by numbers (that could be only for triage). They need to be assigned by areas of interest.
[20:58] <tdonohue> but, I do think the boards could be useful in organzing 3.0
[20:59] <mhwood> But we seem to have some areas of interest in which no one is interested.
[20:59] <tdonohue> helix84: perhaps I'm not being clear. I'm actually talking about "triage". The "split up" the queue would be a way for us to just perform basic triage on tasks to try and determine which actually need discussion in this meeting.
[21:00] <tdonohue> (again, this is really just a brainstorm I had. If I'm crazy or if others think there's a better route, I'm open to ideas)
[21:00] <helix84> tdonohue: IMHO developers shouldn't need to do triage. we have this community group (i keep forgetting what it's called) for that.
[21:00] <tdonohue> I just don't like the fact that we are reviewing tickets that are 6+ months old every single meeting
[21:01] <helix84> CAT
[21:02] <mhwood> I wonder if we could work out a list: OK to assign {this type} of issues to me.
[21:02] <tdonohue> helix84: we don't have a community group that does triage. We have DCAT, but all they do is help create better use cases for *feature requests*. They don't even look at bugs
[21:03] <tdonohue> mhwood: that could work. I like that idea.
[21:03] <mdiggory> tdonohue: I do agree, it might be useful in we, as a group just went through and at least spent 15 seconds on a ticket classifying and prioritizing it... Voting is good way to prioritize as well.
[21:04] <hpottinger> right now, we have a triage system that involves one of us needing to bring a bug to everyone's attention if it's annoying enough to us personally (I do this for any Oracle issue)
[21:04] <mhwood> Issues need to belong to someone if they are to get work (as opposed to attention).
[21:05] <tdonohue> hpottinger: correct. we are doing well at that. I think we should continue to do that as a way to triage
[21:05] <mdiggory> we should at least identify if a issue provides a solution or not.
[21:05] <sands> i've gotta jet. cheers all.
[21:05] * sands (~sandsfish@18.189.31.239) has left #duraspace
[21:06] <tdonohue> hmm..maybe use tags/labels to flag whether it has a solution? Or just schedule it for 3.0 if it's got a patch/solution (and then hope that we can find someone later to tackle it before 3.0)?
[21:06] <mdiggory> I'm not sure, then whoever adds a solution (patch or otherwise) needs to update the label as well...
[21:06] <tdonohue> I agree though -- the tickets I'd most like to "find" are those that either have a patch or a solution. Cause those shouldn't have to wait for 6+ months necessarily. Or at least, we should be considering them all for 3.0
[21:07] <hpottinger> yeah, if a bug report and patch comes in, in past it has sat for review, but it ought to come with a pull request now, so that should speed those issues up
[21:07] <helix84> this areas of interest idea seems to have some support. what about creating a wiki page with a list of devs with "OK to assign {this type} of issues to me." - it might not get rid of all bugs but still a lot
[21:08] <helix84> i'd agree to look at bugs as they come in and somehow ping those devs
[21:09] <mdiggory> this is where boards may come into play... create boards for "needs solution", "review in meeting", "schedule for next release", "postpone"
[21:09] <KevinVdV> *Needs to run*
[21:09] <KevinVdV> Until next time
[21:09] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) Quit (Quit: HydraIRC -> http://www.hydrairc.com <- s0 d4Mn l33t |t'z 5c4rY!)
[21:09] <mhwood> I have to go too. Will check the log.
[21:10] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:10] <tdonohue> mdiggory: yea, maybe boards could have a place here. It's just a bit hard right now as the boards would be so large with 80+ tickets
[21:10] <mdiggory> I think it just dumped all the tasks onto them by default....
[21:10] <tdonohue> but, you could be right that we could use them to be able to categorize these tickets better
[21:12] <tdonohue> maybe it is worth digging around with the boards some. I can see potential here to organize things directly in JIRA. But, right now, it's a giant mess that needs some attention/love.
[21:15] * tdonohue notes that we are obviously in overtime here. Sorry. Meeting is officially closed, but I'm going to stick around a bit while I play with these "boards"
[21:16] <mdiggory> Take a look at fedora... they have a few boards that they are managing the next release in
[21:18] <tdonohue> yea, I see. I think the problem I have is I don't quite understand the ordering yet. It's definitely a different way of viewing/categorizing things. Just trying to determine how this can help us manage our *input* queue
[21:18] <mdiggory> they use alot of subtasks
[21:18] <mdiggory> https://jira.duraspace.org/browse/FCREPO-888
[21:18] <kompewter> [ [#FCREPO-888] Fedora 3.5.0 Documentation Updates - DuraSpace JIRA ] - https://jira.duraspace.org/browse/FCREPO-888
[21:21] <mdiggory> They also have a "Roadmap Theme" that seems like our "Component"
[21:21] <mdiggory> but is more generalized
[21:25] <tdonohue> yea, I can see benefits of using the boards for *release management*. I'm still trying to figure out if they are also useful for managing the unreviewed tickets queue (much of which are not scheduled for a release yet)
[21:25] <mdiggory> tdonohue: what are the available statuses you can set on a task and how do you change them?
[21:26] <mdiggory> for isntance...
[21:26] <mdiggory> https://jira.duraspace.org/browse/DS-892
[21:26] <kompewter> [ https://jira.duraspace.org/browse/DS-892 ] - [#DS-892] Performance issues in update enabling the StatisticsLoggingConsumer - DuraSpace JIRA
[21:26] <kompewter> [ [#DS-892] Performance issues in update enabling the StatisticsLoggingConsumer - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-892
[21:26] <mdiggory> status is set to "received" ...
[21:28] <tdonohue> Right. Everything starts as "received".
[21:29] <tdonohue> If you do an "Accept & Open Issue" it moves to "open". From "open" it can go to "in progress", "resolved" or "closed"
[21:29] <mdiggory> Documentation Status: is this a custom field we added?
[21:29] <tdonohue> Or you can immediately press "Reject & Close Issue" button in which case it goes straight from "received" to "closed" (this is normally for issues which are not valid JIRA tickets -- e.g. questions that can just be answered or should go to the list)
[21:30] <mdiggory> we can manage the workflow stages and customize them
[21:30] <tdonohue> Yes. Documentation Status was something that was added a while back, to try and track which features still needed docs. Not sure that we really use it consistently though
[21:30] <mdiggory> in the project admin
[21:30] <mdiggory> I'm looking at it atm
[21:30] <tdonohue> yep. I know. I customized them already to include that "received" status.
[21:34] <mdiggory> could probably create a "needs solution" workflow phase, then you move it into the phase from received if theres no patch or solution... then move it into Open and/or "In Progress" when a patch is provided or someone takes ownership
[21:34] <mdiggory> and commits to creating a solution
[21:35] <tdonohue> the problem is that the only way to tell if it "needs solution" is to have someone do a "triage" review. That's the main issue here is that we aren't doing "triage" quick enough, which is why our queue has grown to a backlog of 80+ (6 months old)
[21:35] <mdiggory> could even have something at the end that aligns with our Github Pull Request process... "Needs Review"
[21:36] <tdonohue> but, I fully agree we can tweak the workflow how we want. The first issue though is that we need to get *people* involved in that workflow. We don't want to create/tweak the workflow before we figure out how we want to manage the queue.
[21:37] <mdiggory> right, but our triage is too intense and I think we need to be more strict about classifications and quick to classify. TBH, the meeting may not be the right place for triage...
[21:39] <mdiggory> the meeting is more discussion about solutions on tickets we know are important. How many tasks do we actually immediately reject upon review in the meeting?
[21:41] <mdiggory> note that the workflow status can be set very quickly from the search results page
[21:41] <tdonohue> I agree completely about the meeting not being for triage. I'm just not sure that adding more workflow steps resolves that?
[21:43] <mdiggory> I'm just looking for something more formal than labels to Identify status of the issue.
[21:44] <mdiggory> https://jira.duraspace.org/browse/DS-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel
[21:44] <kompewter> [ https://jira.duraspace.org/browse/DS-1178 ] - [#DS-1178] XSLT stylesheet for OAI-PMH - DuraSpace JIRA
[21:44] <kompewter> [ [#DS-1178] XSLT stylesheet for OAI-PMH - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel
[21:44] <mdiggory> here we have a Pull Request, some commitment to work on the task...
[21:45] <mdiggory> so its ready for review in the group and a final decision on who will follow it through.
[21:46] <mdiggory> that seems more like a workflow stage than a priority
[21:46] <mdiggory> or a label
[21:47] <mdiggory> https://jira.duraspace.org/browse/DS-1173
[21:47] <kompewter> [ https://jira.duraspace.org/browse/DS-1173 ] - [#DS-1173] registry loader does not employ the more flexible MetadataImporter - DuraSpace JIRA
[21:47] <kompewter> [ [#DS-1173] registry loader does not employ the more flexible MetadataImporter - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1173
[21:47] <mdiggory> here we have an idea and a recommendation, but no effort to prepare the issue for resolution....
[21:48] <mdiggory> "Needs Work"
[21:50] <tdonohue> unfortunately I have to head out shortly. But, honestly, if you do have thoughts on how the workflow can be tweaked to make things easier, feel free to send them my way (email or similar). Sorry...I wish I could stick around to discuss more right now
[21:51] <mdiggory> no sweat... I've got to head out for my nieces graduation shortly....
[21:51] <mdiggory> enjoy
[21:51] <hpottinger> thanks for the reminder on 1178, mdiggory, I meant to +1 that the other day, but forgot, did it just now
[21:53] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[21:55] <helix84> hpottinger: i'd love if you leave a comment, just +1 or possibly some suggestions for improvement
[21:56] <hpottinger> upvoted, and signed on to the watch list
[21:56] <helix84> i actually started with a METS rendered, but I wanted to make it complete by the XSD which turns out i probably bit of more than i can chew
[21:56] <helix84> s/rendered/renderer/
[21:56] <kompewter> helix84 meant to say: i actually started with a METS renderer, but I wanted to make it complete by the XSD which turns out i probably bit of more than i can chew
[21:57] <helix84> nice feture, kompewter
[21:57] <mdiggory> just accepted the pull request and took ownership of the task...
[21:57] <helix84> s/feture/feature/
[21:57] <kompewter> helix84 meant to say: nice feature, kompewter
[21:57] <helix84> :D
[21:57] <mdiggory> might have been a little premature.
[21:58] <mdiggory> review the comment helix84, just open new pull requests if your going to keep running with some of those recommendations...
[21:58] <helix84> mdiggory: you mean because i'm still working on it (in that case i don't think so) or because you'd like bmore input?
[21:59] <mdiggory> I was just concerned about having the server render html in the case of older browsers...
[21:59] <mdiggory> that it'd probibly be better to just not support them at all.
[21:59] <helix84> ok, i'll comment
[21:59] <mdiggory> k
[22:00] <mdiggory> got to run :-)
[22:00] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has left #duraspace
[22:01] * hpottinger has to run, too, bye!
[22:01] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.