Timestamps are in GMT/BST.
[6:47] -sendak.freenode.net- *** Looking up your hostname...
[6:47] -sendak.freenode.net- *** Checking Ident
[6:47] -sendak.freenode.net- *** Found your hostname
[6:48] -sendak.freenode.net- *** No Ident response
[6:48] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:48] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:48] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[6:59] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[7:02] * Tonny_DK (~thl@130.226.36.117) Quit (Client Quit)
[7:03] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[12:29] * alxp (~aoneill@blk-30-155-121.eastlink.ca) has joined #duraspace
[13:10] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[14:14] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[14:26] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[14:40] * ksclarke (~kevin@adsl-39-49-230.clt.bellsouth.net) has joined #duraspace
[14:58] * scottatm (~scottatm@adhcp136.evans.tamu.edu) has joined #duraspace
[18:45] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[18:46] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[19:07] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:29] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[19:37] * helix84 (a@195.113.97.174) has joined #duraspace
[19:40] * cccharles (~chris@li123-120.members.linode.com) has joined #duraspace
[19:53] * PeterDietz (~PeterDiet@128.146.175.194) has joined #duraspace
[19:55] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) Quit (*.net *.split)
[19:56] * robint (5229fe8f@gateway/web/freenode/ip.82.41.254.143) has joined #duraspace
[19:58] <tdonohue> Hi all, DSpace Developers starting here in a few minutes. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-02-16
[19:58] * hpottinger (80ce8882@gateway/web/freenode/ip.128.206.136.130) has joined #duraspace
[20:01] <tdonohue> Ok all.. DSpace Devel meeting begins now. As usual, we'll start with some JIRA catchup. Today we are starting with DS-678.
[20:01] <tdonohue> Here's a list of 'to-be-reviewed' items, so you can follow along: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-678+ORDER+BY+key+ASC
[20:01] <tdonohue> https://jira.duraspace.org/browse/DS-678 Community Admin unable to create new bundle type for items
[20:03] <tdonohue> thoughts on DS-678? Should a Community or Collection Admin be allowed to create a new Bundle?
[20:03] <tdonohue> I'd say "yes", they should have this right...but, i'm curious what others think.
[20:04] <PeterDietz> when you submit an item, you end up creating ORIGINAL, LICENSE, CC-LICENSE. So that should also be the case during item edit.
[20:04] <stuartlewis> It seems logical that they should be able to.
[20:05] <grahamtriggs> I would say yes - but also this is essentially the same as DS-776 - we should close one as a duplicate, probably 678, as the other has a better description of the problem
[20:05] <tdonohue> makes sense grahamtriggs. So, that sounds like we are in agreement that this is an issue/bug. Any volunteers to fix this? Seems like it should be a relatively minor fix
[20:07] * mdiggory (~mdiggory@rrcs-74-87-47-100.west.biz.rr.com) has joined #duraspace
[20:07] <tdonohue> no one wants to tackle DS-678/DS-776? really :)
[20:08] <grahamtriggs> that said, would it be useful to have a 'manager' role - where they can affect the items that are part of the collection, but not alter the items themselves?
[20:08] <tdonohue> ok -- guess we'll leave unassigned for now. I'll schedule DS-678/DS-776 for 1.7.1, and merge them into one issue. Hopefully we can get someone to fix this
[20:09] <mdiggory> why can't collection admins create bundles?
[20:09] <tdonohue> Next one -- https://jira.duraspace.org/browse/DS-679 : Modifying dspace oai code to offer harvesting through collection : harvest any item with a request on metadatavalue
[20:09] <grahamtriggs> mdiggory: because of a bug :)
[20:09] <tdonohue> mdiggory, see previous discussion. It's a bug. We think they should be allowed to
[20:10] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[20:11] <tdonohue> stuartlewis or kshepherd, is DS-679 something you are already working on locally then?
[20:11] <mdiggory> its like trying to play a symphony with kazoos
[20:12] <stuartlewis> If we drove oai-pmh via solr, this sort of virtual set would be trivial.
[20:12] <mdiggory> they never liked "Search" in teh OAI-PMH community
[20:13] <kshepherd> tdonohue: i was planning on working on it as a feature.. had a few attempts but i think getting familiar with (and improving) discovery is the best first step to 'virtual sets' or 'virtual collections'
[20:13] <grahamtriggs> mdiggory: http://www.royalalberthall.com/tickets/bbc-radio3-big-red-nose-show/default.aspx
[20:13] <tdonohue> so, is anyone working on driving oai-pmh via Solr? Or wanting to do that? I wouldn't be opposed to the idea, assuming we are still doing valid OAI-PMH
[20:13] <PeterDietz> RE:DS-678/DS-776, I think that it is an XMLUI specific bug.
[20:14] <grahamtriggs> mdiggory: and yes, I will be in the choir seats for that, with a kazoo.... I also saw a professional choir doing the chorus for the Chicken Run theme on kazoo...
[20:14] <mdiggory> theres allot of ways it could get done... OAI-PMH requesthandler inside solr implemented in Java w/ Velocity or XSLT
[20:15] <mdiggory> but, I wonder if this stuff is better suited for http://proai.sourceforge.net/
[20:15] <tdonohue> So, is there any more to discuss on DS-679? Or is this just in a "waiting queue" for someone to tackle it :)
[20:15] <kshepherd> tdonohue: one of the stumbling blocks i did come up against is the set identifiers.. are they supposed to be persistent? can they be reused? where do we set them? they don't correspond to static DSOs so we can't reserve handles. it can probably be done all through dspace.cfg but that seems messy
[20:15] <tdonohue> aha..ok, i can understand that complexity then
[20:15] <kshepherd> tdonohue: i'm happy to keep looking at it once i've worked with solr a bit more.. but also happy to help others if they want to take lead on it
[20:15] <stuartlewis> Could we comment and close this one, suggesting the reporter looks at the other open tickets for virtual collections?
[20:16] <kshepherd> (related jobs are DSCR-12 and DS-277)
[20:16] <PeterDietz> tdonohue, you can assign the merger of DS-678/DS-776 to me
[20:16] <tdonohue> PeterDietz -- thanks, will do!
[20:17] <tdonohue> stuartlewis. I think that's probably a good route forward. I'm assuming it looks like "DS-277" is the most appropriate "main ticket"?
[20:18] <mdiggory> http://www.digitalcommonwealth.org/
[20:18] <mdiggory> uses a solr based OAI-PMH engine to search digital collections within Massachusetts.
[20:18] <tdonohue> DS-679 -- close issue and mark as "duplicate". Forward user on to DS-277/DSCR-12 for more info.
[20:18] * kshepherd notes that there is a community-supplied 'virtual sets' addon at https://wiki.duraspace.org/display/DSPACE/DSpaceOAISets
[20:18] <mdiggory> maybe thats the opposite... sorry
[20:18] <kshepherd> i'll take a closer look when i have some free time
[20:18] <grahamtriggs> I'm not convinced about the request in 679... yes, to virtual sets, but rather than mapping directly to a search / discovery query, it needs to be named sets that map to a defined query
[20:19] <tdonohue> grahamtriggs -- either way, we already have a request for OAI virtual sets in DS-277. So, DS-679 is a duplicate idea/request
[20:19] <grahamtriggs> so, you can specify an arbitrarily complex query, behind a simple set name
[20:20] <kshepherd> grahamtriggs: yep, i think that's the consensus
[20:20] <tdonohue> moving on for now: https://jira.duraspace.org/browse/DS-680 invalid input syntax for type timestamp in db query for stat-initial utility
[20:21] <tdonohue> anyone have ideas on DS-680, or want to volunteer to investigate this further?
[20:21] <mhwood> Hmmm, where did that "::" stuff come from?
[20:23] <tdonohue> mhwood -- that "::" looks to also be in Trunk version of LogAnalyser
[20:23] <tdonohue> lines 1209 and 1225 of LogAnalyser in Trunk
[20:24] <mhwood> If no one else wants it, I can dig into it.
[20:24] <tdonohue> ok, assign DS-680 to mhwood for investigation / fix
[20:25] <tdonohue> We'll stop there for now...and move on to other topics, which actually are a few more issue reviews. See agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-02-16
[20:26] <tdonohue> As you may recall, from a few week's ago, we had discussed that DCAT will start to review Feature Request in JIRA, and add their comments. They've already reviewed 3 older feature requests, which I want to make us all aware of
[20:27] <tdonohue> DCAT does all their reviews on the Wiki, in a new "forum" area: https://wiki.duraspace.org/display/dsforum/Home
[20:27] <tdonohue> (can everyone get to that page? It just prompted me for a login...which is odd)
[20:27] <kshepherd> i got to it ok
[20:27] <kshepherd> but i was already logged in..
[20:27] <robint> I cant login
[20:28] <kshepherd> "You must be a registered wiki user to participate."
[20:28] <helix84> same as kshepherd here
[20:28] <stuartlewis> I'm in (as a logged in user)
[20:28] <mhwood> I got it without login
[20:28] <tdonohue> Ok, well, as long as we can all get to it. I know we are supposed to have access to it -- i.e. anyone in the community should be allowed to get to it and join discussion
[20:29] <kshepherd> DS-164 has reminded me of another idea i had, but i'll save it for later ;)
[20:29] <tdonohue> So, in any case, I wanted to (1) make everyone aware of this. DCAT is voting on whether they feel these older feature requests still have merit or not. (2), I thought we could all specifically revisit DS-164 (the first one they reviewed)
[20:29] <mhwood> Wait, wrong link. Got in with login.
[20:29] <tdonohue> https://wiki.duraspace.org/pages/viewpage.action?pageId=23268096&focusedCommentId=25067837#comment-25067837
[20:29] <mdiggory> Just found it earlier and have been at play in there all morning... thanks
[20:30] <grahamtriggs> yeah, we kinda noticed
[20:31] <tdonohue> So, does anyone else have comments / suggestions / ideas on DS-164? Anyone aware of the status of any work that could eventually meet these needs, or is there more info we want to ask DCAT for (i.e. better requirements, etc?)
[20:31] <tdonohue> (i'm reading mdiggory's input now)
[20:33] <tdonohue> I should also mention that I agree that this would make a great feature. If anyone is interested in tackling it (or even starting to investigate what it would take to tackle it), I'd do my best to support you (as would DCAT).
[20:33] <grahamtriggs> in my case, I'm the one dealing with the .xml files, so it insulates admins from that layer - but we're seeing issues in terms of what people want simply not being capable with the input-forms (or even the proposed DB driven stuff)
[20:33] <mdiggory> In its simples form... smells like Content Models
[20:33] <mdiggory> grahamtriggs: hear hear
[20:33] <grahamtriggs> and that is in the forms needing to be 'designed' more - not just be a collection of fields
[20:34] <mdiggory> again... hear hear... and TBH, the authority control lookup is still not what our clients want
[20:34] <mhwood> Are there existing forms packages we could use?
[20:34] <tdonohue> grahamtriggs -- makes perfect sense. have you or anyone at Open Repositories begun to brainstorm this out at all? Or is the dependency on DB driven configs what is really in the way?
[20:36] <grahamtriggs> I've been forging ahead with Freemarker UI - getting browse / search / item viewing in place - haven't quite got to admin or submission - yet... but I was toying with making it possible to just define the fields directly in Freemarker templates
[20:36] <mdiggory> I worry the DB driven drive detail is a red herring... Though it would be nice to put the capability into the Admins hands, theres still some problems with how this is all hodge podge wired together like a pachinka machine
[20:36] * kshepherd would be more inclined to spend dev time/effort on SWORD, EasyDeposit, etc. than submission in jspui/xmlui
[20:37] <mdiggory> kshepherd: we have need for both... and the validation part I write about plays into the SWORD work as well
[20:37] <grahamtriggs> I tend to agree with mdiggory to separate the validation of fields away from the configuration of the forms. The issue of items being 'correct' is not tied just to the submission forms (although the submission forms do need to be able to present useful feedback in the case of error)
[20:37] <kshepherd> i can see that validation is still needed, yeah
[20:37] <tdonohue> kshepherd -- we do need people on both sides of things. But, it's perfect fine to prefer one over the other :)
[20:38] <mdiggory> tdonohue: how diplomatic...
[20:38] <tdonohue> haha :)
[20:39] <mdiggory> So... I ponder if we can come up with a set of changes to something like the MetadataRegistry that might get us part of the way there
[20:39] <mhwood> Yes, validation belongs to the abstract metadata field, not the box or element or whatever in which it is presented to the machine.
[20:39] <tdonohue> Ok. So, what are the next steps in getting towards something like DS-164? Trying to tease out the dependencies here. Sounds like we've already hit on a few of the bigger issues...
[20:40] <mhwood> Tag the metadata field with a validator class.
[20:40] <tdonohue> mdiggory -- putting validation details in MetadataRegistry?
[20:40] <kshepherd> if we are redesigning the forms, i wonder if it's worth thinking about 'edit item' as well -- i've thought of trying to get XMLUI's item edit page using input-forms.xml or similar so that we can use better form elements, auth control lookups etc in edit pages
[20:40] <tdonohue> kshepherd ++ I agree completely
[20:40] <kshepherd> (and potentially keep the old plain textarea forms behind 'Advanced Edit' or something)
[20:40] <tdonohue> (both edit and submit should be using the same mechanism)
[20:41] <mdiggory> ContentModelRegistry... A list of Content Models that have Metadata Fields Assigned to them and some validation rules like (required, optional) and a value syntax rules
[20:42] <mdiggory> we use the submission forms again in the EditMetadata stage in the XMLUI, seems plausable it could be used in the EditItem as well.
[20:42] <tdonohue> hmm...interesting idea. Not sure I'd call them "Content Models". worried that's a loaded term (e.g. Fedora, Hydra, etc. all use that term)
[20:42] <mdiggory> It is purposefully "loaded"
[20:43] <mdiggory> ;-)
[20:43] <mdiggory> "Schema"?
[20:43] <kshepherd> or we could try and tie it in with templates
[20:43] <mdiggory> I promise not to say... Ontol...
[20:44] <kshepherd> then along with validation rules, you can supply default values, bitstreams etc. as we do with templates currently
[20:44] <grahamtriggs> mdiggory: I was about to say something similar - I wouldn't mind seeing 'input control/data type' and validation tied against the metadata registry. Form design would then place which fields you are interested where you want them, with minor option tweaking (ie. is it repeatable)
[20:44] <tdonohue> this does bring me back to the question that mhwood posed (no one responded): "are their existing forms packages we can use?" Similarly, is there existing validation/schema/content models frameworks we could use?
[20:44] <kshepherd> (the term "templates", i mean, not the actual code)
[20:45] <grahamtriggs> If you are using the same metadata field for different formats of data in different circumstances (ie. item types or different collections), you probably should rethink your field usage
[20:45] <mdiggory> kshepherd: Templates is interesting, but the problem is that we only get so far with the Item model before we need more
[20:45] <mdiggory> I do agree that Template might be replaceable by one or more "item Schema"
[20:45] <mdiggory> especially ina Type driven submission system
[20:47] <kshepherd> here's something that's kinda fun to play with -- an html5 forms builder: http://www.reformedapp.com/#home
[20:47] <mdiggory> grahamtriggs: I agree on the last statement, we get allot of requests to change the Label for dc.foo.bar on collection X but not Y
[20:48] <mdiggory> And we then immediately respond with why thats not so wise to do...
[20:48] <grahamtriggs> different metadata = different fields... If you need to expose it in a common field for OAI-PMH, etc., then that's what crosswalks are for
[20:48] <kshepherd> indeed
[20:49] <tdonohue> So, is DS-162 of definite interest to anyone or their institution? Curious if we have a person or two who is already interested in digging in deeper on some possible options? (this doesn't mean you'd have to "lead" or build it, just that you'd dig around more and report back on some options/issues)
[20:49] <mdiggory> robint: I'm curious about your view on the topic give the work you've done on Type Driven Submission?
[20:50] <tdonohue> err..I meant DS-164, not DS-162 (obviously)
[20:50] <robint> mdiggory: Slow thinker.
[20:51] <robint> Can see the need for different labels for the same metadata filed though - dc.date
[20:51] <robint> s/filed/field
[20:52] <robint> Claudia has well developed thoughts on this subject
[20:53] <tdonohue> fyi -- if any of you have more thoughts on this later as well, please do feel free to comment directly on DCAT's page, or the DS-162 issue itself. DCAT is watching both of those, and it'd be good to keep discussions moving forward
[20:53] <mdiggory> I tend to agree that if you want to change the meaning of a field by changing its Label. It is better to change the field or at least qualify it
[20:53] <grahamtriggs> If you need different labels, then the data is representing different things. If the data is different, then the field should be. You can always crosswalk all of them into (eg. dc.date) when you expose the fields if you need to
[20:54] <robint> Are our DC qualifiers not just labels of a sort ?
[20:55] <mdiggory> Old Search/Browse adapted to this through merging metadata fields into single search or browse fields, SOlr currently doesn't "
[20:55] <mdiggory> merge"
[20:55] <kshepherd> yep. my stuff is only ever proper OAI-DC or MODS or whatever after crosswalk and serialisation... before that it's all sorts of crazy schemas and fields ;)
[20:55] <kshepherd> mdiggory: very easy to do in schema though
[20:55] <kshepherd> i have an example as a blog post
[20:55] <grahamtriggs> Granted, there are some curiosities with Dublin Core - ie. titles and book chapters, etc. but that's just crappy, ambiguous dublin core. Store it internally in something that isn't DC and isn't ambiguous, and crosswalk it to DC on the way out
[20:55] <mdiggory> kshepherd: to a degree
[20:56] <mdiggory> but yes, good catch there, and we need some more of that kind of documentation
[20:56] <kshepherd> yeah i have some more to write, too
[20:57] <mhwood> Is the problem separable into nicely-sized subproblems? F'rinstance, can we move validation information away from the forms separately from redoing the presentation? Are there other subproblems?
[20:58] * tdonohue is reminded that many of these discussions seem to circle back to improving Metadata. We need to schedule a special topics meeting on improving how we manage Metadata, etc
[20:58] <kshepherd> just on a tangent, i notice one of the DCAT requests is DS-638
[20:58] <mdiggory> Also back to the forms issue, if the validation rules are abstracted from the form definition, it really opens the doors to experiment with new form technologies. Possibly even allot more JSON / AJAX driven Forms handling
[20:59] <kshepherd> and i agree with the JIRA comments.. this should be a curation task
[20:59] <tdonohue> kshepherd -- yes, DS-638 is another they are interested in :)
[21:00] <tdonohue> kshepherd -- I'd encourage you & everyone else to comment on DCAT recommendations outside of this meeting as well. So, don't hesitate to add thoughts/suggestions or ask questions of DCAT. I'm trying to get better about that myself :)
[21:00] <mdiggory> http://www.reformedapp.com/ ... eh.. whats so easy about filling out lots of individual forms to generate a form?
[21:02] <tdonohue> Ok. it sounds like discussion of DS-164 is slowing down a bit. I'll post a summary to DCATs page. Please feel free to add more comments there, etc. If you come across and idea or something that could be worth investigating more, let us know!
[21:02] <mhwood> Do we have a good grasp of what sites want from the forms presentation layer? Other than "not so much icky XML".
[21:02] <mdiggory> Per DS-638 the BitstreamFormatRenovation would have introduced Pronom/Droid in this space...
[21:02] <tdonohue> mhwood -- that's something we can ask DCAT for, better requirements. Right now, I think the only request, is 'not XML based, please'
[21:04] <tdonohue> Ok -- we're already running a bit long, but I wondered if we could take a quick moment to comment on DS-820. helix84 is in our meeting today, and asked me if we could provide some general feedback, if we had time.
[21:04] <tdonohue> https://jira.duraspace.org/browse/DS-820 : SFX button + SFX in Mirage
[21:04] <kshepherd> well, i'd vote +1 to the validation/content-model stuff before the actual form-builder/UI stuff i guess, since validation, etc is of benefit to sword deposits as well as internal submission
[21:06] <tdonohue> kshepherd -- i'll add some comments to DCAT about splitting up that problem. I think it's worth trying to separate those two pieces, if there's a way to do so easily.
[21:06] <kshepherd> re DS-820 - i can get Yin Yin (who did previous SFX patches) to check it out and test
[21:06] <helix84> hello. i'm looking for someone who could assign this. having an SFX server is not necessary, you can test e.g. with our publically available SFX server.
[21:06] * snail (~stuart@130.195.179.88) Quit (Ping timeout: 246 seconds)
[21:06] <tdonohue> kshepherd : that'd be great! DS-820 looks like a nice addition at a glance, but it'd be good to get another developer to look at it and try it out, etc
[21:06] <helix84> just today i also ralized that i can add the customize dimage to JSPUI, too, and provide a patch. it will be trivial.
[21:07] <kshepherd> looks almost identical to the previous verisons, so should work OK
[21:08] <tdonohue> ok, so for DS-820, kshepherd will ask Yin Yin to investigate/test, and report back to us and helix84
[21:08] <kshepherd> yep
[21:08] <helix84> thanks. is anyone interested to assign this to himself?
[21:08] <robint> Got to go. Cheers everyone.
[21:08] <tdonohue> helix84 -- if you had the time/inclination to do it for the JSPUI, feel free. It's not truly a requirement that everything *must* work in both XMLUI and JSPUI, but it helps
[21:08] <kshepherd> i've taken it
[21:08] * robint (5229fe8f@gateway/web/freenode/ip.82.41.254.143) Quit (Quit: Page closed)
[21:09] <helix84> looking at the JSPUI code, it should be a two-liner. kshepherd: thanks
[21:09] <PeterDietz> only thing I noticed was that in xsl we usually use xsl:template name="SFXLink" and xsl:match name="SFXLink" not xsl:variable name="SFXLink" and xsl:copy-of select="SFXLink"
[21:09] <tdonohue> Ok all...that's all I had on the agenda, and it looks like we've run over yet again.
[21:10] <helix84> PeterDietz: about that - I used a template for the Reference theme, but it wouldn't work in Mirage
[21:10] * tdonohue is beginning to wonder if we either (a) need a longer meeting (1.5 hrs), or (b) need to find ways to tackle some of these tasks asynchronously outside of the mtg
[21:11] <helix84> PeterDietz: it has to do with how DRI is available from different files in dri2xhtml-alt
[21:11] <tdonohue> (no need to respond to my ramblings now -- just pointing out, that we are consistently running short on time -- to much to do with DSpace these days!)
[21:12] <helix84> PeterDietz: so I just did it the simple way, constructing the link in one xsl file, passing the variable to annother for display. Did the same in Reference for consistency.
[21:12] <tdonohue> So, we'll close up the meeting for today. I'll be around for a while, if anyone has anything else to discuss informally, etc.
[21:13] <PeterDietz> helix84: the xsl is fine by me then
[21:14] <mhwood> Hmmm, we used to allow 60 seconds for discussion of a JIRA item and then ask for a vote.
[21:15] <PeterDietz> tdonohue, I think if we followed a format like in Prime Ministers Questions, where people have to pick up a book and set it on a table, and talk fast enough before they get jeered off stage, likewise, when you make points you have to get to the point fast enough so that you get people to cheer for you
[21:15] <helix84> tdonohue: I'd like to ask about access rights to the DSpace manual wiki pages. I left some comments fixing a lot of typos, they're still not fixed. But I would also often like to improve on the manual, adding a section here and there or rephrasing for clarity.
[21:16] <tdonohue> mhwood -- yea, unfortunately, we've been bad about that recently. It seemed discussion has been going longer as we encounter complex JIRA issues. But, that could be an idea to revisit, if others are interested and willing to return to a much quicker JIRA review process
[21:16] <helix84> tdonohue: it was easy to send a patch to the pre-confluence manual...
[21:17] * mdiggory thinks helix84 just got elected documentation editor
[21:17] <helix84> yay for me ;)
[21:18] <tdonohue> helix84 -- anyone who wants access and is willing to chip in, can get access. We just "lock it down" to prevent spammers. Initially, Jeff Trimble (Documentation Guru) & I may closely review your edits (we get notified of any edits). But, that shouldn't discourage you to make changes.
[21:19] <tdonohue> I'll give you access & send Jeff & you an email...what's your JIRA login?
[21:19] <tdonohue> I mean, your JIRA username
[21:19] <helix84> tdonohue: it's helix84. I'm used to review from Wikipedia. But then it also has more open policies ...and more manpower to handle spam.
[21:20] * snail (~stuart@130.195.179.88) has joined #duraspace
[21:20] <tdonohue> yea. We definitely don't have the manpower of Wikipedia. Right now, the Docs area is mainly managed by the Committers group, and a few other volunteers. :)
[21:22] <mhwood> BTW do we have any kind of style manual? Not "do we use Oxford comma" and that sort of thing. I've seen pages where the same sort of matter (say, a command example) is marked up two different ways without apparent reason and wondered whether I was fixing or breaking by making A have the same markup as B rather than vice versa.
[21:23] <helix84> tdonohue: the edit link just appeared for me, thanks
[21:23] <kshepherd> mhwood++, style guidelines would be great
[21:23] <tdonohue> mhwood -- no, but you can start one :) The closest we have is a "DSpace Wiki Style Guide", which is more just a reference to using the general wiki syntax: https://wiki.duraspace.org/display/DSPACE/DSpace+Wiki+Style+Guide
[21:24] <helix84> there are two things I dislike about the manual - 1) it mixes howtos with reference (think list of dspace.cfg properties)
[21:24] <tdonohue> that looked like an "mhwood--", I didn't mean to decrement mhwood. That was supposed to be a dash! In reality, it is mhwood++
[21:24] <helix84> 2) there currently isn't a single-page HTML
[21:25] <kshepherd> the DSDOC manual doesn't have howto stuff, does it?
[21:25] <kshepherd> the rest of the wiki does, sure, but that's separate to the 'manual'
[21:26] * hpottinger (80ce8882@gateway/web/freenode/ip.128.206.136.130) Quit (Quit: Page closed)
[21:26] <helix84> what i meant was "common dspace set-up tasks howto"
[21:26] <tdonohue> helix84: if you have ideas of how to rework things, we are definitely open to changes. I think the best route forward would be to "mock up" some examples of changes you'd like to see in a new wiki page(s).
[21:26] <mdiggory> we should when the opportunity arises... take wiki stuff out of the wiki, clean it up and put it into the documentation... that could include howtos
[21:26] <tdonohue> mdiggory++
[21:26] <mdiggory> thats the great benefit of them being on the same platform
[21:27] <helix84> mdiggory: that's what I meant. wiki should contain a broad set of howtos, while manual should have a narrower set of recommended approaches.
[21:27] <mhwood> mdiggory: I thought we just finished piling all of the documentation *into* the wiki.
[21:27] <tdonohue> part of the reason for moving to Wiki-based docs was that it would allow us to take 'how-to' docs from the main wiki, clean them up, and make them part of the "official docs"
[21:27] <mdiggory> mhwood: right now I want you to take it all back out and put it into the docbook again [sic]
[21:28] <kshepherd> aha
[21:28] <helix84> oh, there's a 3rd thing I dislike. 3) confluence wiki is slooow
[21:28] * mhwood feels thankful for SVN
[21:28] <tdonohue> helix84, I like that idea. broad 'how-to' on general wiki, narrower set of specific recommendations in the 'manual' area
[21:28] <kshepherd> i must need to re-read the manual and wiki
[21:28] <kshepherd> i thought that's how it already was :P
[21:28] <mdiggory> tdonohue: we need more warp drive
[21:28] <mhwood> The manual is *in* the wiki. Isn't it?
[21:29] <kshepherd> mhwood: wiki vs. wiki/DSDOC
[21:29] <tdonohue> kshepherd, yes and no (as is everything). In some areas, we have better recommendations in the 'general wiki area', than we do in the actual manual. We need to be more willing to pull things over to enhance the manual contents
[21:29] <mdiggory> sorry mhwood ... what kshepherd said, I didn't realize that wasn't clear
[21:29] <helix84> kshepherd: in general, it is. specific example of important missing information is what i just answered on dspace-tech an hour ago: how do i connect tomcat with apache?
[21:30] <kshepherd> fair enough...
[21:31] <helix84> I'd like to ask a question, but please, don't throw stones just yet... why did the manual move from docbook to confluence if it has restricted access anyway?
[21:32] <kshepherd> helix84: i think one of the main reasons was to lower the barrier for *us* to actually get around to editing it
[21:32] <kshepherd> (us being the community at large)
[21:32] <mhwood> No, that was the reason for changing it from Word to DocBook. :-/
[21:32] <kshepherd> but it also ties in nicely with other atlassian stuff
[21:33] <kshepherd> oh, well..
[21:33] <helix84> is there any way the performance of jira and wiki could be improved? e.g. a reverse proxy?
[21:34] <kshepherd> i was under the impression that jeff was getting hit with most of the work when docbook was used
[21:35] <mdiggory> kshepherd: ding ding ding ding... you get a grand prize...
[21:35] <kshepherd> is it coffee?
[21:35] <PeterDietz> confluence/DSDOC = official recommendations that has consensus (more or less). confluence/DSPACE is a free for all.. So anyone in community can put how their method for getting tomcat to serve at port 80 into confluence/DSPACE, but once its clear that that is the best way, or Method A/B/C for getting tomcat up-and-running, then it can get moved to confluence/DSDOC
[21:36] <mhwood> Well, you only had to ask...DocBook doesn't scare me. However, 'tis done now.
[21:36] <mdiggory> mmmm... cofffeee
[21:36] * mdiggory wishes we have the same spread as the Google coffee lounge...
[21:37] <tdonohue> helix84 - the main reason for the switch to Confluence was to allow for non-technical people to also contribute to the manual. So, although they still need to ask for access, any non-technical person can also help enhance it (e.g. we want to eventually have a User Guide there)
[21:37] <mhwood> PeterDietz: OK, so we need terms a little sharper than "wiki" vs. "manual".
[21:37] <helix84> tdonohue: I understand that. What's should the User Guide be in comparison to DSpace Manual?
[21:38] * mdiggory thinks developers often overlook the user and their needs.
[21:38] <tdonohue> kshepherd is also right. When we used docbook, Jeff Trimble was doing almost *all* of the documentation. It became a difficult scenario for him, and we needed to open it up more to others
[21:38] <mhwood> The manual is all the stuff you can do. The User Guide is good ways to think about what you are doing.
[21:39] <helix84> is there a stub of User Guide yet?
[21:39] <tdonohue> helix84 -- a User guide would be something like: "Here's how you Add Users via the UI", "Here's how you can customize your Metadata Schemas via the UI", etc. It'd be more user friendly, with screenshots, and a guide to using DSpace from a Repository Manager point of view
[21:40] <kshepherd> good discussion
[21:40] <tdonohue> no, unfortunately, there's not a "stub" that I know of. Though, I know some folks at @mire (Bram especially) have thrown around the idea.. not sure if they have anything to share yet though?
[21:40] <helix84> ah, so basically Manual would be for admins and User Guide for people working with the DSpace web interfaces
[21:41] <tdonohue> exactly! Manual = DSpace System Admins, User Guide = DSpace Repository Managers / Guide to Admin UI tasks, etc
[21:41] <helix84> What about renaming it to Administrator Guide (=manual) and User Guide_
[21:41] <tdonohue> I'd be all for that :)
[21:41] <mhwood> Well, no, I don't think so. Manual is definitive (or should be): these are the things DSpace does. Guide is more how to put it all together -- how you might actually use the things DSpace does.
[21:42] <helix84> that's my other grief with manual I mentioned. I'd like to have reference and guide split. Currently manual is both.
[21:43] * mhwood is thinking of the VMS doc set: every component had a Reference and a Programmer's (or User's) Guide.
[21:43] <tdonohue> whatever we call it ("manual", "guide" or whatever), I think there are two main audiences for DSpace Documentation: (1) The System Administrator (which is essentially what our current docs are oriented for), and (2) The Repository Manager (currently missing in docs)
[21:44] <mhwood> So: split on the SA/RM axis, the what/how axis, or something else?
[21:44] <tdonohue> It could be that I confused this by calling it a "guide". that's just my word for it, and I'm perfectly fine with it changing. I just wanted to point out that we are only serving one audience for our current Manual
[21:44] <helix84> I'm volunteering only for the admin stuff. I'm not at all into screenshots :)
[21:45] <tdonohue> helix84 -- perfectly fine! we need people to help in both areas
[21:45] <mhwood> Manual, Sysadmin Guide, Repo Mgr Guide?
[21:46] <helix84> mhwood: if I understand correctly, list of options vs. how do I accomplish this task. That's what I meant.
[21:46] <mhwood> Sounds right.
[21:47] <helix84> Doesn't necessarily be a separate document. Maybe just moved into Appendices of the Sysadmin guide
[21:47] <tdonohue> Yea, that sounds right to me too...or at least a good place to start
[21:48] <mhwood> Yeah, I was thinking that other-product-specific stuff (like, how to do X in Tomcat) should be moved to appendices and the stuff in the setup section be made generic.
[21:48] <kshepherd> we don't really have a big, maintained FAQ either
[21:48] <helix84> mhwood: I wasn't thinking that, but that's also a good way to think about it.
[21:48] <mhwood> FAQ needs someone to figure out which Q are FA.
[21:49] <kshepherd> i think we could cut down on some of the repeat questions on dspace-tech if we had a monthly mailout to the list with an updated FAQ, links to wiki, guides, manual, etec
[21:49] <helix84> kshepherd: I was actually going to go through dspace-tech archoves and expand TechnicalFaq
[21:49] <kshepherd> mhwood: mailing list archives are pretty telling...
[21:50] <mhwood> I tried to genericize the servlet-container setup stuff once, but it wasn't good enough and got reverted.
[21:50] <helix84> so I will do an extensive FAQ first, which will help filter out really often needed howtos currently missing in tha manual.
[21:50] <tdonohue> kshepherd -- yea, I think those are good ideas, we just need to tackle as a group. We mostly don't have a big maintained FAQ cause we don't have volunteers to help maintain it! If folks are interested in that, I'd be willing to chip in -- I just cannot do it on my own :)
[21:50] <helix84> then it will be quite easy to cheerry pick from FAQ to Sysadmin guide/manual
[21:51] <tdonohue> helix84++ If you can do some updates to the Technical FAQ, that'd be *wonderful*!
[21:51] <mhwood> Yes, thank you!
[21:51] <kshepherd> helix84++
[21:51] <helix84> I've been thinking about that for a month now. I'll start this weekend.
[21:52] <tdonohue> thanks helix84!
[21:52] <helix84> I'll try to live up to so many thanks :)
[21:52] <helix84> Good night for today
[21:52] <tdonohue> If we can get that Technical FAQ more up-to-date, hopefully as a group we can all chip-in to *keep it up-to-date*. It's a great resource to have, but it cannot be maintained by one person
[21:53] <helix84> I'll come and report on next Dev Meeting
[21:53] <kshepherd> awesome
[21:53] <tdonohue> good night. Thanks for joining discussion today, helix84
[21:53] * helix84 (a@195.113.97.174) has left #duraspace
[22:14] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[23:00] * alxp_ (~aoneill@blk-30-155-121.eastlink.ca) has joined #duraspace
[23:00] * alxp_ (~aoneill@blk-30-155-121.eastlink.ca) Quit (Client Quit)
[23:02] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[23:02] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has left #duraspace
[23:42] * mdiggory (~mdiggory@rrcs-74-87-47-100.west.biz.rr.com) Quit (Quit: mdiggory)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.