Timestamps are in GMT/BST.
[1:18] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[1:18] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[3:16] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[3:16] * bradmc__ (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[6:30] -barjavel.freenode.net- *** Looking up your hostname...
[6:30] -barjavel.freenode.net- *** Checking Ident
[6:30] -barjavel.freenode.net- *** Found your hostname
[6:31] -barjavel.freenode.net- *** No Ident response
[6:31] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:31] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:31] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[7:13] * bradmc__ (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[7:15] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[8:32] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has joined #duraspace
[11:48] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[12:03] * eddies (~eddies@unaffiliated/eddies) Quit (Ping timeout: 240 seconds)
[12:04] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) Quit (Read error: Connection reset by peer)
[12:05] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[13:08] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[13:09] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[13:28] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[13:56] * kompewter (~kompewter@sul272peter.lib.ohio-state.edu) Quit (Ping timeout: 246 seconds)
[13:56] * kompewter (~kompewter@sul272peter.lib.ohio-state.edu) has joined #duraspace
[14:10] * kdweeks (~Adium@2001:468:c80:a103:223:dfff:fefe:ac7d) has joined #duraspace
[15:13] * barmintor (barmintor@specdl11.cul.columbia.edu) has joined #duraspace
[16:06] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) Quit (Read error: Connection reset by peer)
[16:09] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[16:22] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has left #duraspace
[17:51] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[19:59] * KevinVdV (~KevinVdV@d54C15567.access.telenet.be) has joined #duraspace
[19:59] <tdonohue> Hi all, DSpace Devel meeting will start here in a few minutes. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-06-22+-+Documentation+Mgmt+Discussion
[19:59] <kompewter> [ DevMtg 2011-06-22 - Documentation Mgmt Discussion - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-06-22+-+Documentation+Mgmt+Discussion
[20:01] * robint (522921b0@gateway/web/freenode/ip.82.41.33.176) has joined #duraspace
[20:02] <tdonohue> Hmm... looks like Jeff Trimble hasn't joined us yet, and he's supposed to be helping to lead this discussion on 1.8 Documentation Mgmt.
[20:02] <mhwood> General announcements?
[20:02] <robint> PeterDietz: Any news ?
[20:03] <tdonohue> In the meantime, one general announcement. We have notes from the OR11 Face-to-face meeting posted on the wiki now: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-06-06+-+OR11+Meeting So, if you missed the meeting, you can catch up from the notes
[20:03] <kompewter> [ DevMtg 2011-06-06 - OR11 Meeting - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-06-06+-+OR11+Meeting
[20:04] <tdonohue> beyond that, the only other thing to mention is that I'll be working on a way in JIRA to mark an issue as "Requesting Review by DCAT" (which is something that came up at OR11 discussion).
[20:06] <tdonohue> Ok. How about we start with a few JIRA items (to give time for Jeff to join us). We'll do some JIRA updates till about quarter after, and if he hasn't shown by then, I can just lead the discussion
[20:06] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[20:06] <tdonohue> so, here's our list of JIRA items needing review: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-819+ORDER+BY+key+ASC
[20:06] <kompewter> [ https://jira.duraspace.org/browse/DS-819 ] - [#DS-819] Metadata Masking - DuraSpace JIRA
[20:06] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-819+ORDER+BY+key+ASC
[20:06] <tdonohue> we'll begin with DS-819
[20:06] <kompewter> [ https://jira.duraspace.org/browse/DS-819 ] - [#DS-819] Metadata Masking - DuraSpace JIRA
[20:07] <tdonohue> (hi mdiggory...we're reorganizing today's discussion to see if jtrimble joins us in a bit)
[20:07] <robint> This is a common request at the moment which we have discussed before
[20:07] <mhwood> Sounds like the Metadata For All project
[20:07] <mdiggory> This seems more a dialog about how to manage grouping metadata and applying ACL... shoulds like more of a proposal than a JIRA issues
[20:08] <robint> I think it comes back to who has access to what
[20:08] <robint> IMO it should be done with Resource Policies
[20:08] <mdiggory> I'd like to see a very clearly lead architectural direction on this one.
[20:08] <mdiggory> because it intersects with how metadata would be treated in the future.
[20:09] * richardrodgers (~richardro@18.111.79.162) has joined #duraspace
[20:09] <robint> The problem is that we need to resolve the DCValue issue first
[20:09] <mdiggory> Some of my prototype work for the Domain Model does solve this
[20:09] <robint> mdiggory: I was hoping that might help
[20:10] <mdiggory> it makes DCValue and MetadataValue equivalent conceptually and does away witht he public fields
[20:10] <tdonohue> bravo...we need to "retire" DCValue
[20:11] <mhwood> SO that gives us the ability to say "no" and enforce it, but then we need ACLs on lots of things that don't have them now, and many more access types. (No, I don't have lists.)
[20:11] <mdiggory> sort of... I think it should have been matured rather than creating a MetadataValue class
[20:12] <mdiggory> refactoring will clear all the poor usage of public fields in the class.
[20:12] <mhwood> Also need to decide: static or dynamic inheritance of ACEs.
[20:12] <mdiggory> ACE?
[20:12] <mhwood> Access Control Entry. What the list is made from.
[20:13] <mdiggory> you mean the ResourcePolicy
[20:13] <mhwood> I guess so.
[20:13] <tdonohue> So, is Ds-819 essentially a 'sub-category' of the Domain Model / Metadata for All work? (in which case maybe we can link it back into those proposals?) Or is it worth keeping separate?
[20:13] <mdiggory> Ok... heres the dilemma IMO
[20:14] <mdiggory> creating Resources Policies on individual metadata fields is not going to get us the level of control we really should be striving for in describing the parts of an item
[20:15] <robint> tdonohue: It already references some other Jira issues. If you want I'll assign it to myself and try and group it with other related issues.
[20:15] <mdiggory> what is really needed are "groupings" of metadata that can be associated with DSpace Objects
[20:15] <mdiggory> and permissions are attached to those "groupings"
[20:15] <robint> mdiggory: Is this the metadata bundles idea ?
[20:15] <mdiggory> bundle is a bit loaded, but yes
[20:16] <mdiggory> the idea is that an Item has a description that is a group of metadata, but it also has other "groups" of metadata that are either descriptive or technical
[20:17] * tdonohue is noticing we're rapidly heading into implementation details -- not sure we have time for that deep of discussion today
[20:17] <mdiggory> and if you have these "groups" of metadata and can serialize them into a representation, that representation can be stored, for instance in something like a Fedora Datastream
[20:18] <mhwood> Will we be able to create categories that satisfy everyone or do they need to be configurable? (Eeeek!)
[20:18] <mdiggory> or a file in an AIP
[20:18] <tdonohue> robint -- i think it would be good if you can connect this issue up to related ones (and group them together in some way)
[20:18] <mhwood> Serialization is a separate issue.
[20:18] <robint> tdonohue: assigned to me
[20:18] <mdiggory> tdonohue: no doubt... I'm just setting the stage for the need for some guided architectural roadmap/vision here
[20:20] <mdiggory> mhwood: some would be required / fixed, others would be open to the definition
[20:20] <mdiggory> a fixed "dc" namespace that was required would align us with Fedora easily.
[20:21] <mhwood> So make 'em all configurable and pack the required configuration into some JAR where it's relatively hard to tinker with.
[20:21] <mdiggory> possibly, your are on track that "serialization is a separate issue"
[20:22] <tdonohue> ok. Ds-819 Summary: assign to robint, who will group with related issues. Need to bring ideas back into larger discussions (Metadata for All & Domain Model work). May need a few volunteers to start to architect this or split tasks up into smaller chunks
[20:22] <mhwood> I think that access control and convenient grouping for serialization are distinct uses of bundling/categorization.
[20:22] <mdiggory> to poke a hole at my own proposition, the groupings may not cleanly align between what the users want control over...
[20:23] <mhwood> Trying to stay focused on one thing at a time.
[20:23] <tdonohue> I propose we move on to Documentation Management discussion now. I can lead the discussion in Jeff's absence today.
[20:23] <mhwood> Who says that a field has to be a member of exactly one group?
[20:23] <mdiggory> but I can say that "provenance" is different than "description" and should be stored separately
[20:24] <mhwood> Time to go away and write up requirements for various things we want to be able to do?
[20:24] <mdiggory> Letting tdonohue move us on,
[20:24] <mhwood> Yes, moving on....
[20:25] <tdonohue> mhwood & mdiggory -- I suggest maybe moving some of these thoughts into a wiki proposal (or we can do a Special Topics meeting)
[20:25] <tdonohue> Ok. Moving on to Documentation Mgmt Discussion
[20:26] <tdonohue> Essentially, the root issue here is that (to this day) we still don't have good Documentation Mgmt. Jeff has done some amazing work at helping us to get close.
[20:26] <mdiggory> what is missing?
[20:26] <tdonohue> Yet, at the same time, the 1.7.0 release only had it's Docs completed because both Jeff & I spent nearly 2 full days apiece (in the final week of the release) cleaning up docs, rewriting some of them, and essentially making sure they were 'acceptable'
[20:27] <mhwood> I don't disagree, but specifically what do we need to fix?
[20:27] <mdiggory> so, is this about developers keeping up with the documentation?
[20:28] <mdiggory> Slight tangent... I'm really of the opinion that the html docs in the dspace release should go away.
[20:28] <tdonohue> essentially the problem is twofold: (1) developers are not keeping up with Docs, and (2) even when they are keeping up with Docs, those docs tend to be "hard to find" -- i.e. they are off on the main DSpace Wiki and are never actually moved into DSDOC (or similar)
[20:28] <mdiggory> they create vendor branch management pain
[20:29] <richardrodgers> so tdonohue: do we need better procedures or more hands (or both)?
[20:29] <tdonohue> So, part of the issue here is one of communication. Even when developers are writing good docs, Jeff (or I) don't have a clue where to find them
[20:30] <tdonohue> I'd recommend a little of both -- better procedures can help with some of this. But, we also need more hands as well (otherwise, release week ends up being "hell" for all involved)
[20:30] <mdiggory> the flow should be for someone to recognize work ongoing int he wiki and propose the developer prepare/move it to DSDOC
[20:30] <mhwood> By "off on the main DSpace Wiki," you mean: in separate articles?
[20:30] <mhwood> So then: how does someone become aware that pages are appearing in the wiki?
[20:31] <mdiggory> Should JIRA issues reference a document in the wiki as the target for documentation?
[20:31] <tdonohue> mhwood -- that's the whole problem. Developers are creating docs in https://wiki.duraspace.org/display/DSPACE/Home and Jeff is never notified. So, when it comes time to do the release, Jeff has to search around to see if he can find relevant docs
[20:31] <kompewter> [ Home - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Home
[20:32] <mdiggory> at least in that case "something" is being captured
[20:32] <mdiggory> and thats a start
[20:32] <tdonohue> Not only that -- but sometimes docs are created off in https://wiki.duraspace.org/display/DSPACE/Home area, and they are 'incomplete' or not quite ready -- Jeff only discovers that when he goes to search for them
[20:32] <kompewter> [ Home - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Home
[20:32] <mhwood> Guideline for release coordination: feature freeze means your code *and documentation* must be ready for prime time (and identified), or they don't go in.
[20:32] <tdonohue> So, in the end.. Jeff & I have a few ideas here of how to make things a bit easier
[20:32] <mdiggory> by off... do you mean not as a child?
[20:33] <mdiggory> mhwood... yuck
[20:33] <tdonohue> mdiggory, I just mean they are hidden somewhere in the DSPACE space of the wiki, when they need to be over in DSDOC for the official release
[20:33] <robint> mhwood: I agree
[20:33] <mdiggory> tdonohue: understood
[20:34] <mdiggory> robint: mhwood thats a bit draconian
[20:34] <mhwood> Heehee, I didn't even get to "write the documentation first."
[20:34] <mdiggory> 90% of whats gone into DSpace probibly wouldn't be there if we were that rigid
[20:35] <robint> I am not sure it should be applied to the letter of the law, but the intention is good
[20:35] <tdonohue> Proposal #1: We may need a "Developer Docs" area of the Wiki (similar to DuraCloud). Essentially, we'd have a new DSDOCDEV space which is (initially) a copy of DSDOC space, but it's a place where developers *must* write their NEW docs for the next release
[20:35] <robint> A feature is not finished if its not documented
[20:35] <mdiggory> mhwood: ha... ok... what about Tests! ;-)
[20:35] <tdonohue> For more on proposal #1 -- see the bullet point on agenda on how DuraCloud manages their docs: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-06-22+-+Documentation+Mgmt+Discussion
[20:35] <kompewter> [ DevMtg 2011-06-22 - Documentation Mgmt Discussion - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-06-22+-+Documentation+Mgmt+Discussion
[20:36] <mdiggory> tdonohue: I"ve actually taken to writing my docs in my personal space, then moving them out to wiki once they reach a stable representation
[20:36] <tdonohue> Essentially, DuraCloud manages their docs in two *main* Wiki Spaces. They have the DURACLOUDDOC space (like DSDOC) which is the official documentation (for latest release of software)
[20:37] <richardrodgers> so who would own the process of DSDOCDEV->DSDOCS?
[20:37] <mdiggory> tdonohue: those links don't seem to work
[20:37] <tdonohue> They also have the DURACLOUDDEV space which is for the *next* release of the software (the DSDOCDEV idea for us)
[20:37] <mdiggory> [DURACLOUD08]
[20:37] <mdiggory> [DURACLOUDDEV]
[20:37] <mhwood> And how does that differ from what we do now?
[20:38] <tdonohue> richardrodgers: Jeff or the Release Coordinator would "own" the process of migrating DSDOCDEV -> DSDOC during the release of the software
[20:38] <mdiggory> mhwood: the wiki is a "freeforall" and the docs get lost in it unless the author notifies tdonohue and trimble
[20:38] <mdiggory> or moves it themselves
[20:39] <mhwood> Yes, but doesn't DSDOC get snapshot to produce the release-specific versions that I see on https://wiki.duraspace.org/display/DSPACE/DSpaceResources#DSpaceResources-DocumentationandGuides ?
[20:39] <kompewter> [ DSpaceResources - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpaceResources#DSpaceResources-DocumentationandGuides
[20:39] <mdiggory> can you migrate a subset of pages from one space to another?
[20:39] <tdonohue> mhwood -- that differs from now because right now it's a 'freeforall' -- we have no clue where people are putting their docs on the Wiki. But, if we do a DSDOCDEV space (which is an identical copy of DSDOC initially) then we only need to copy DSDOCDEV -> DSDOC to release them
[20:40] <tdonohue> mdiggory -- no. unfortunately the copy process is a bit more complex (but DuraCloud has figured it all out, and I can steal docs from them for us to use)
[20:40] <mdiggory> I'm rather of the opinion that you should decide this for us ;-)
[20:41] <tdonohue> mhwood -- we only generate a PDF & a HTML from DSDOC -- but not really a "snapshot" of the entire DSDOC space to another Wiki space
[20:41] <robint> All sounds reasonable to me
[20:41] <tdonohue> mdiggory -- I'm of the opinion that I'm only one vote here :)
[20:42] <robint> +1 for mdiggory's suggestion :)
[20:42] <mdiggory> excellent, so you've volunteered yourself!
[20:42] <mdiggory> sorry... I'll try to be more serious...
[20:42] <mhwood> Well, there are two issues here: (1) it is stated that people are writing "DSpace manual" content various places around the wiki; (2) no process to cut off and clean up wikified versions of the "manual".
[20:43] <tdonohue> completely correct, mhwood. The DSDOCDEV space idea is just to try and resolve your #1
[20:43] <tdonohue> But, #2 (no 'cut off' date for docs) is still an issue
[20:44] <mdiggory> I agree its important to have the process in place so that the weight of the effort does not actually fall on tdonohue or jtrimble to execute.
[20:44] <mhwood> See, where I get confused is that, if I'm writing stuff that (to me) is clearly "manual" material, I wouldn't know where to put it if I didn't write it into DSDOC.
[20:44] <mdiggory> and mirroring the docs and telling developers to edit them directly is sensible.
[20:44] <tdonohue> Which brings me to the next proposal. Proposal #2 : We absolutely must have an early cutoff date for finalized Documentation. Otherwise, jtrimble & I & RC end up having to edit/spellcheck docs at the very last moment.
[20:45] <mhwood> Hence my controversial comment that feature freeze = documentation ready or else.
[20:45] <mhwood> Maybe I meant code freeze.
[20:45] <mdiggory> more documentation can always be added in the next release.
[20:45] <mdiggory> even inbetween releases
[20:46] <tdonohue> mhwood -- yea, and I personally don't find your idea that controversial. But, maybe we need a separate "Documentation Freeze" date?
[20:46] <tdonohue> mdiggory -- that's not good enough in my opinion. We really shouldn't release new features that are 100% undocumented
[20:46] <mhwood> No matter how wonderful code is, it doesn't matter if nobody knows it's there or nobody knows how to use it.
[20:46] <mdiggory> the probilem is that if code is in the trunk without documentation, your telling use we need to take it out
[20:46] <mdiggory> not very agile
[20:47] <mhwood> I think that ideally documentation, like tests, is part of the design process.
[20:47] <tdonohue> +1 mhwood
[20:47] <robint> mdiggory: Not exactly. More that the documentation should be done at the same time
[20:47] <mdiggory> well, then theres a lot in the last release that shouldn't have gone in because there wasn't documentation generated on it
[20:48] <tdonohue> mdiggory -- let's not look at how we did things in the past (which I agree wasn't ideal -- again, 1.7.0 docs were not fun to clean up)
[20:48] <mhwood> So we have an opportunity to improve in 1.8.
[20:48] <tdonohue> exactly... 1.8 can be better.
[20:48] <mdiggory> and we should do a review on everyones commits going forward to and reject them immediately if they havn't written at least two paragraphs of documentation about them
[20:49] <mhwood> Commits != features.
[20:49] <mdiggory> how can you tell?
[20:49] <tdonohue> no -- we don't need to get that strict. IMHO. Personally, I'd be fine if we just stuck to the idea that all New Features must have some minimal documentation *by* the Feature Freeze date to be accepted
[20:50] <mdiggory> but their already in the codebase? how are you going to unaccept them?
[20:50] <mhwood> And: documentation doesn't have to be written by the coder; he only has to ensure that it gets written.
[20:50] <mdiggory> force the developer to rollback, what if that work was done earlier in the release cycle?
[20:50] <mhwood> Can't unaccept them -- if undocumented, we don't know what they are. :-/
[20:51] <mdiggory> how much would break?
[20:51] <tdonohue> mdiggory -- let's hope it doesn't get to that. The goal is not to go haywire 'unaccepting' features. Rather, the goal is to ensure we are all doing docs as we develop features
[20:51] <mdiggory> so... how about a carrot instead of a whip
[20:52] <mdiggory> though I've not a clue how to get developers interested in eating carrots
[20:52] <tdonohue> if you have other ideas, i'm all ears
[20:52] * robertqin (~robertqin@bb116-14-174-250.singnet.com.sg) has joined #duraspace
[20:52] <mhwood> The carrot: "not only does this new feature do wonderful things, but the manual is so clear I had no trouble understanding it!"
[20:52] <tdonohue> currently, the only idea I've heard that can force us to do docs is that we reject new Features that don't have docs
[20:54] <mdiggory> "mhwood: Can't unaccept them -- if undocumented, we don't know what they are. "
[20:54] <mhwood> Yup, so we have some catch-up to do when we find underdocumented features. But in the future we want that to happen much less.
[20:54] <tdonohue> Remember: All new features are supposed to be "approved" (by the RC or by the Committers) *before* it is committed to the release. So, we can choose to not even approve it if it has no docs
[20:55] <mdiggory> Ok... to bring forward an example (not picking on you richardrodgers).... modular configuration slipping in with the curation tools.
[20:55] <mdiggory> modular configuration wasn't documented and many were not aware of it until after the release
[20:56] <richardrodgers> mdiggory: I think it was in the context of curation...
[20:56] * gaurav_kl (75c62054@gateway/web/freenode/ip.117.198.32.84) has joined #duraspace
[20:56] <tdonohue> to be honest, not sure what past examples of 'mistakes' really leads us to (we've all made mistakes or provided less than stellar docs in the past). I'd rather think of ways we can improve this in the future
[20:56] <mdiggory> if it was discovered before the release, your going to drop that feature just because of a lack of docs?
[20:57] <tdonohue> no -- you'd instead target that developer and say: "Hey, we need some docs here please. This feature is undocumented"
[20:57] <mhwood> The whole point is to make it clear that that *could* happen so we all want to avoid it by documenting well.
[20:57] <robint> Plus, tating that aim now may help ensure that it doesn't happen
[20:57] <mdiggory> its an empty threat
[20:58] <robint> tating/stating
[20:58] <tdonohue> mdiggory: I'm not looking for a way to plug up all "holes". I'm just looking to change the perceptions that I can throw in as much code as I want without docs
[20:58] <mhwood> tdonohue: yes. We need to invite others to hold us accountable for describing our contributions in timely fashion.
[20:58] <mdiggory> just ask for docs... and publically flog if they do not
[20:58] <tdonohue> mdiggory: it's not an empty threat if during the next release we start to pay closer atttention to all your new feature submissions (i.e. over time, we'll figure out who is good at giving docs, and who is not)
[20:59] <mhwood> Maybe someone else will see an unmet need and write the docs. It's exhausting, but a great way to understand unfamiliar code.
[20:59] <tdonohue> mdiggory: it's also not an empty threat if on mailing lists we say: "Go talk to ____ about Feature X , as he/she is the one who built it and didn't document it" :)
[20:59] <robint> If its an agreed aim/procedure then I trust committers to abide by it
[20:59] <mdiggory> now that motivating...
[21:00] <mdiggory> richardrodgers: sorry, I was stretching for an example... I'm sure you got some docs on it somewhere in there. ;-)
[21:00] <mhwood> If I just can't make myself document, then I should pair up with someone who can.
[21:01] <richardrodgers> mdiggory: no prob, it is an interesting edge case :)
[21:01] <tdonohue> +1 mhwood. The goal here is documentation. Whether the developer writes it, or finds someone else to help out. The key though is the developer is *responsible* to ensure that documentation exists (no matter who writes it)
[21:02] <tdonohue> Ok. So, we probably should wrap this up now...as we are running over a bit
[21:02] <mdiggory> +1 robint its all about trust
[21:02] <mdiggory> Why can't we all just get along Man!
[21:02] <tdonohue> It sounds like we've come to the following decisions: (1) we should create a DSDOCDEV space for "in development" documentation
[21:03] <mdiggory> hear hear
[21:03] <richardrodgers> fine with me
[21:03] <robint> tdonohue: +1
[21:03] <mhwood> So I do what I do now, only in a different space (to me, just a different link).
[21:04] <tdonohue> (2) We need to all be responsible for ensuring Documentation exists for new Features (preferably at least a few weeks in advance of release). (at least it sounded like we were coming around to that decision)
[21:05] * mdiggory except for the mark diggory guy... he's always got to be so contrary
[21:06] <tdonohue> (3) If mdiggory doesn't give us docs, then we provide his home email/address/phone to everyone who has questions on new features built by mdiggory
[21:06] <tdonohue> I may have slipped in a #3 there ;)
[21:06] <mdiggory> haha
[21:06] <richardrodgers> +1 but add bank acct
[21:08] <mdiggory> I'll open up bidding for those who want to write my documentation for me at two shillings
[21:08] <mhwood> Don't be afraid...join us...I'm amazed at the kinds of fuzzy thinking I uncover when I try to explain what I did.
[21:08] <tdonohue> Ok. I think that's it for the DSpace Devel Mtg for today (i'll report this all to Jeff). Thanks all! As usual, we now move on to the GSoC Update meeting if anyone is interested in hanging around for a bit more.
[21:08] <robint> Got to go unfortunately. Thanks all.
[21:08] <mdiggory> Theres a couple followups I want to try to tackle if I can bend an ear for a few minutes.
[21:09] <richardrodgers> Thanks all got to run, bye
[21:09] * richardrodgers (~richardro@18.111.79.162) Quit (Quit: richardrodgers)
[21:09] <mdiggory> https://jira.duraspace.org/browse/DSCR-22
[21:09] <kompewter> [ [#DSCR-22] Discovery module back end rewrite to support discovery without solr. - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DSCR-22
[21:09] <tdonohue> mdiggory -- feel free to take over for GSoC meeting if you want. I'll be here for the GSoC update meeting, but these meetings are meant to be more open discussion (no real agenda)
[21:09] <mdiggory> I'd like to start bringing this into Discovery for 1.8...
[21:10] <tdonohue> oh, this is not GSoC related then....i misunderstood
[21:10] <mdiggory> we should move onto GSoC just after it.
[21:10] * robint (522921b0@gateway/web/freenode/ip.82.41.33.176) Quit (Quit: Page closed)
[21:11] <mdiggory> I just want to voice I'm looking to commit this and its all just discovery code
[21:11] <tdonohue> this is a huge (size wise) commit. hard to say for certain without time to review it
[21:11] <mhwood> Documented of course. :-)
[21:11] <mdiggory> the featureset is that Discovery gets a bit of a rewrite...
[21:12] <KevinVdV> To make it more accessible
[21:12] <KevinVdV> & it creates a possibility to plug in something other then solr into the discovery UI
[21:12] <mdiggory> As Discovery is optional its also the case we should still consider it something that will change over time
[21:12] <KevinVdV> (should you want to)
[21:12] <tdonohue> more accessible in terms of UI accessibility? or in terms of "accessible" to developers?
[21:13] <KevinVdV> Accessible for developers at the moment
[21:13] <KevinVdV> I do plan on making to UI a little more accessible to but I first wanted to do the back end
[21:14] <mdiggory> One of the possible benefits of the approach is a clearer path for implementing WebMVC / Freemarker variants of Discovery
[21:14] <tdonohue> In essence of time (again this patch is way too large to review), I wonder if it'd be best to get a few other DSpace committers to look at this work? I'm thinking of kshepherd or stuartlewis as I know they have been using Solr/Discovery heavily (and therefore may have some good feedback, etc)
[21:14] <mdiggory> its basically creating a domain model, plugable backend and presentation tier for discovery
[21:15] <KevinVdV> T.b.h. the more people that cna review it & give me feedback the better
[21:15] <mdiggory> I agree.
[21:16] <tdonohue> I'd suggest requesting feedback then on dspace-devel, or emailing kshepherd & stuartlewis (since I know they are using Solr/Discovery).
[21:16] <mdiggory> we need to get this finished up, its been actually sitting there for a number of weeks
[21:17] <KevinVdV> I could always attempt to email kshepherd & stuarlewis since it is my idea and request feedback
[21:17] <tdonohue> if anyone else in this chat is heavily using Solr/Discovery, it'd also be worth more eyes as well (I only suggested kshepherd & stuartlewis cause I know they are using it)
[21:19] <tdonohue> yea, in general, for such large changes/patches, it's best to find someone else who is familiar with this code who could help give some feedback. So, in this case, it's best to find some other committers/active developers who are already familiar with Solr/Discovery
[21:20] <KevinVdV> So tdonohue are there any other developers you know who use discovery ? (beside the already mentioned ksheperd & stuartlewis)
[21:20] <mdiggory> yes, that is why I'm clarifying the intention to get it in, I've already reviewed the work and am accepting the task
[21:20] <tdonohue> mdiggory: yea, I'd also clarify that on something like dspace-devel or dspace-commit though. Cause, as you can tell, our audience in today's meeting is a bit small
[21:21] <tdonohue> KevinVdV: PeterDietz might as well. But, to be honest, I don't always know what features people are using heavily. It's best to just ask on dspace-devel or similar
[21:22] <mhwood> Must go home and find out if the Solr & Lucene books I ordered have arrived....
[21:22] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[21:23] <tdonohue> Ok. So, is there anything GSoC related that needs discussing?
[21:23] <robertqin> hi Tim!
[21:23] <gaurav_kl> hi
[21:23] <mdiggory> yes, lets shift gears
[21:24] <robertqin> perhaps i'll just post a quick update to my webmvc
[21:24] <tdonohue> I'll note that our attendance is still a bit small today -- many mentors aren't here, but we can still do updates, etc.
[21:24] <robertqin> yeah
[21:24] <tdonohue> Hi robertqin & gaurav_kl
[21:24] <tdonohue> go ahead, robertqin..
[21:24] <robertqin> i'm basically done with the registration component, epeople and group for admin
[21:25] <robertqin> and i've issued a pull request to graham
[21:25] <robertqin> so as mentioned
[21:25] <robertqin> one of the dilemmas i'm pondering b4 i proceed with further development
[21:26] <robertqin> is whether i should wait for graham to merge his changes with the master repository and syncing that with my fork
[21:26] <robertqin> because the last time, the webmvc master repo was not in sync with my fork
[21:26] <robertqin> and when i tried to run fetch upstream, there were alot of conflicts that occured
[21:26] <robertqin> and its kind of messy to fix them
[21:27] <robertqin> yeah, so i'm kinda of waiting for more updates from graham or peter regarding this
[21:27] <robertqin> i've already highlighted this issue with peter
[21:28] <robertqin> yeah, so these are my updates..
[21:29] <tdonohue> robertqin: sounds great!
[21:29] <robertqin> hi thanks tim !
[21:29] <tdonohue> hopefully peter & graham can help you figure out a better process for those syncs/merges
[21:29] <robertqin> yeah..
[21:29] <robertqin> graham seems kind of tied down at the moment
[21:29] <tdonohue> (and hopefully they can also inform other projects as well -- so that we can avoid that for all projects)
[21:30] <tdonohue> yea, I know graham just recently switched jobs (he now works for Symplectic instead of Open Repository), so that might be part of it
[21:30] <robertqin> yeah i've heard about it..
[21:31] <tdonohue> I also know peter & his wife are expecting a baby any day now -- so, he might disappear off and on in coming days/weeks
[21:31] <robertqin> haha, yeah i know!
[21:31] <robertqin> heard about it from last week discussion
[21:31] <robertqin> its great news
[21:31] <tdonohue> so, if you find you need help on something and peter & graham have "disappeared" temporarily, let us know on the duraspace-gsoc list, and we can try to find others to help you out.
[21:32] <robertqin> yeah thanks
[21:32] <robertqin> in any case, https://github.com/DSpace/webmvc/pull/4
[21:32] <kompewter> [ #4: Added EPerson admin func by robertqin for DSpace/webmvc - Pull Request - GitHub ] - https://github.com/DSpace/webmvc/pull/4
[21:32] <robertqin> the link shows my current commits
[21:32] <robertqin> i'm planning to step up with Supervisors next
[21:33] <robertqin> but i'm currently reading up on understanding that component better
[21:33] <tdonohue> excellent. sounds like you are making good progress overall!
[21:33] <robertqin> my current difficulties is really understanding the complete workflow of each component
[21:33] <robertqin> hey thanks!
[21:34] <robertqin> in any case, its great if there were more documentation available to help understand the workflow for each component
[21:34] <robertqin> because currently, i try to understand the workflow by reading thru the code
[21:35] <robertqin> and it actually takes up a rather substantial amount of dev time
[21:35] <tdonohue> if you need help or have questions about DSpace workflow (or any other existing DSpace JSPUI component), that is something many of us could help you better understand (even if we didn't know WebMVC as well as peter or graham). So feel free to just post questions to duraspace-gsoc
[21:35] <robertqin> i see..
[21:35] <robertqin> yeah, thats what i do currently !
[21:35] <robertqin> thanks for all those advices
[21:35] <robertqin> :)
[21:36] <tdonohue> no problem. you are welcome
[21:37] <tdonohue> Any other GSoC Updates from anyone?
[21:37] <gaurav_kl> yeah
[21:38] <gaurav_kl> So I am basically done with the API and JUnit tests and plan to refine it little bit and start with UI
[21:38] <gaurav_kl> I have been behind schedule
[21:38] <gaurav_kl> but I am catching up
[21:38] <mdiggory> do you have a reference (link) to your API in Github?
[21:38] <gaurav_kl> and I plan to finish the UI part by June end.
[21:39] * barmintor (barmintor@specdl11.cul.columbia.edu) Quit ()
[21:39] * KevinVdV (~KevinVdV@d54C15567.access.telenet.be) Quit (Quit: KevinVdV)
[21:39] <gaurav_kl> yeah
[21:39] <gaurav_kl> https://github.com/gauravkl/DSpace/tree/master/dspace-api/src/main/java/org/dspace/submission
[21:39] <kompewter> [ dspace-api/src/main/java/org/dspace/submission at master from gauravkl/DSpace - GitHub ] - https://github.com/gauravkl/DSpace/tree/master/dspace-api/src/main/java/org/dspace/submission
[21:40] <gaurav_kl> I still have to code for the core "actions"
[21:40] <gaurav_kl> but that I think can be done after the basic UI
[21:41] <gaurav_kl> So how should the core "actions" be splitted?
[21:41] <gaurav_kl> like currently there's DescribeStep,LicenseStep
[21:41] <gaurav_kl> what can be possible smallest "action"
[21:42] <mdiggory> The Code for a set of actions is currently mixed together in the step
[21:43] <mdiggory> Take for Instance Select Collection Step
[21:43] <mdiggory> https://github.com/gauravkl/DSpace/blob/master/dspace-api/src/main/java/org/dspace/submit/step/SelectCollectionStep.java
[21:43] <kompewter> [ dspace-api/src/main/java/org/dspace/submit/step/SelectCollectionStep.java at master from gauravkl/DSpace - GitHub ] - https://github.com/gauravkl/DSpace/blob/master/dspace-api/src/main/java/org/dspace/submit/step/SelectCollectionStep.java
[21:44] <mdiggory> We need to identify and breakdown the actions in here...
[21:44] <gaurav_kl> ok
[21:45] <mdiggory> and like steps in Configurable Submission... Actions may or may not have a view
[21:45] * robertqin (~robertqin@bb116-14-174-250.singnet.com.sg) has left #duraspace
[21:45] <gaurav_kl> so like what are the Actions in this particular Step
[21:46] <mdiggory> this is a bit simple here...
[21:46] <mdiggory> SelectCollectionAction
[21:47] <mdiggory> most of the logic is one to one...
[21:47] <gaurav_kl> ok.so for submission-form there will be separate actions for different
[21:47] <mdiggory> its when we get into mutliple paths that more actions emerge
[21:47] <gaurav_kl> types of input fields?
[21:48] <gaurav_kl> like for Dropdown,textfiled?separate actions
[21:49] <mdiggory> I think we should look at the parts of the Reviewer Workflow Contribution that deal with using the Submission DescribeStep / Upload File steps to possibly see the mapping...
[21:49] <gaurav_kl> ok
[21:50] <mdiggory> looks liek you put parts of it into your code
[21:50] <gaurav_kl> yeah.I have to clean it
[21:52] <mdiggory> Take a look at EditAction to get ideas for the Describe step
[21:52] <gaurav_kl> ok
[21:53] <mdiggory> think of the possible routes out of the page as the Actions that need to be provided on the step.
[21:53] <gaurav_kl> ok
[21:54] <mdiggory> UpdateMetadata, Next Page, Previous Page, Cancel, possibly even steps to launch term completion popup and/or add fields
[21:55] <gaurav_kl> ok
[21:56] <mdiggory> TBH... I look at EditAction and I even think it should have been broken up into more actions because it still contains conditional flow control within it
[21:57] <gaurav_kl> ok
[21:58] <gaurav_kl> So I was planning to start with UI work and the API will get refined in that process as I feel dat will be a better approach.
[21:58] <gaurav_kl> so I plan to send a mail to duraspace-gesoc for finalizingin the UI
[21:59] <gaurav_kl> and finish the UUI by 30th June
[22:00] <gaurav_kl> then I plan to start these "actions" and modify code which Cobineis the Steps
[22:00] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) has joined #duraspace
[22:02] <tdonohue> Sounds good, gaurav_kl! I also think the UI work will probably help you notice areas of the API that need work or need refining.
[22:03] <gaurav_kl> yeah
[22:03] <mdiggory> so... with UI work, are you referring to integrating the existing xmlui portion of the configurable reviewer work?
[22:03] <mdiggory> I would look closely at EditActionXMLUI.java
[22:04] <gaurav_kl> ok.
[22:04] <gaurav_kl> so can you give a basic layout of how our UI is gonna be.though I had come up with mine
[22:08] <mdiggory> Well, for the moment, I think you should view DescribeStep as an "InputForms" viewer rendered on a DSpace Item... that "Viewer" probibly does a great deal of the same rendering if it is viewed in the Submission or in the Reviewer Workflow Edit Step.
[22:08] <mdiggory> However, the behavior and where the Action "forwards" to when completed will be different.
[22:09] * gaurav_kl1 (75c621a0@gateway/web/freenode/ip.117.198.33.160) has joined #duraspace
[22:09] * gaurav_kl (75c62054@gateway/web/freenode/ip.117.198.32.84) Quit (Ping timeout: 252 seconds)
[22:09] <gaurav_kl1> which is mostly similar to one I did in the previous "input-form" project
[22:09] <mdiggory> in the Reviewer Workflow, those controls are Reviewer "centric" IE Update, Accept, Reject,
[22:09] <tdonohue> I unfortunately have to head out all. Good to hear GSoC updates from both robertqin and gaurav_kl! (I'll catch up with mdiggory & gaurav_kl's discussion later on)
[22:09] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has left #duraspace
[22:10] <gaurav_kl1> so like the option for mapping collec tion to workflow should be where?
[22:10] <mdiggory> In Submission those controls are Submitter Centric : Previous Step, Save, Next Step
[22:10] <gaurav_kl1> ok
[22:11] <mdiggory> Well theres a generic "Step" class that holds the Actions... depending on the state of the request, a specific Action is forwarded to and a specific view is associated with that action.
[22:12] <gaurav_kl1> ok
[22:13] <mdiggory> So the SelectCollectionAction has the business Logic and the SelectCollectionXMLUIAction contains the XMLUI DRI rendering of the form for the view.
[22:13] <gaurav_kl1> yeah.sorry i was talking about the adminUI .i think u interpreted it for the actual submission stage.
[22:14] <mdiggory> the "outcomes" of the SelectCollectionAction are linked to new steps, the Submission Controller would move the workspace Item to the new "Step" if the outcome is returned by the Action
[22:15] <gaurav_kl1> yeah
[22:15] <mdiggory> oh... ok
[22:16] <mdiggory> It should be an Option under the "Context" Menu item for the Collection when the CollectionAManger is logged in
[22:16] <gaurav_kl1> ok
[22:17] <mdiggory> or, the approach with the legacy Reviewer Workflow is that its in the Edit Collection view as one of the tabs...
[22:17] <gaurav_kl1> and for mapping of steps to actions and step to workflow are we going to have like "Manage Workflow" ,"manage Steps"
[22:18] <gaurav_kl1> ok..
[22:18] <mdiggory> But TBH, I find it difficult to add to that view cleanly, so I usually just add Options to the Options panel under the context
[22:18] <gaurav_kl1> 2 separate options for these 2 in the main "administer options-set"
[22:19] <mdiggory> So, you'll be on a Collection, the Option will show and you can navigate to see a page that contains?
[22:19] <mdiggory> One or more Workflows, one of which that can be assigned to the collection
[22:20] <gaurav_kl1> so this option won't be in side "edit Collection"
[22:20] <mdiggory> I would try to create some simple mockups in the WIKI using.... https://wiki.duraspace.org/plugins/servlet/mockups?do=add&page=19005968
[22:20] <kompewter> [ Login Required ] - https://wiki.duraspace.org/plugins/servlet/mockups?do=add&page=19005968
[22:20] <gaurav_kl1> ok
[22:21] <gaurav_kl1> dat will be better
[22:21] <mdiggory> careful.. I think that like will put it in the DSpace Home wiki page
[22:21] <mdiggory> like = link
[22:21] <mdiggory> Make a new page and add the mockup fromt he "Add" option in the upper right
[22:21] <gaurav_kl1> ok..then i can post it to the mailing list to get opinions.
[22:22] <mdiggory> thats a good idea
[22:22] <gaurav_kl1> hmm
[22:24] <mdiggory> Select Existing Workflow or Create New Workflow <---> Add /Edit Step <---> Choose Action <----> Assign Outcome To <list of Steps> .... something like that....
[22:25] <gaurav_kl1> yeah..this makes it clear er
[22:25] <gaurav_kl1> so everything will inside a particular colection only?
[22:26] <mdiggory> not sure... seems it could apply at the site or Community level as well.
[22:26] <gaurav_kl1> ok
[22:26] <mdiggory> and be inherited... same as the way it is now
[22:27] <mdiggory> I can imagine some permission nightmares emerging...
[22:27] <gaurav_kl1> oh
[22:27] <mdiggory> Collection A Manager creates new workflow, Collection B Manager assigns it but changes part of it...
[22:28] <mdiggory> changes impact Collection A workflow
[22:28] <mdiggory> not sure if we care or not about that...
[22:29] <mdiggory> or maybe permissions to edit depend on where its created (i.e. Community Manager creates Workflow but Collection Managers can't change it...
[22:29] <gaurav_kl1> yeah.dat makes sense.
[22:31] <gaurav_kl1> ok.thanks.i will post to the mailing list by tomorrow with the mockup of all the admin UI steps..
[22:32] <gaurav_kl1> so in Junit is there any way to check the in-memory DB?
[22:32] <gaurav_kl1> to verify if my table has been created.cuurently I have to do workarounds to test taht
[22:33] <mdiggory> All I can think of is to do select or update to it as a test.
[22:34] <mdiggory> select on a table that does not exist should fail
[22:34] <gaurav_kl1> ok
[22:34] <mdiggory> select on an empty table should success but have no results
[22:34] <gaurav_kl1> ok
[22:37] <gaurav_kl1> ok.thanks Mark.
[22:39] * gaurav_kl1 (75c621a0@gateway/web/freenode/ip.117.198.33.160) Quit (Quit: Page closed)
[22:44] * kdweeks (~Adium@2001:468:c80:a103:223:dfff:fefe:ac7d) Quit (Quit: Leaving.)
[22:51] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
[23:39] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.