Date: Fri, 29 Mar 2024 00:44:03 -0400 (EDT) Message-ID: <168218031.29708.1711687443762@lyrasis1-roc-mp1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_29707_744740557.1711687443761" ------=_Part_29707_744740557.1711687443761 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Face-to-face developer's meeting on topic of DSpace RoadMap before OR2= 012 in Edinburgh, Scotland.
If you don't fall into one of the above categories, you are still welcom= e to attend. However, be warned that discussion will likely get very techni= cal at times (which is why we recommend you be a developer or have a techno= logy background).
Space is limited. Please sign up on the Sign Up sheet below. If we beg= in to achieve capacity, preference will be given to Committers or DCAT Memb= ers. However, we welcome any interested DSpace developers to join us and ta= ke part in the discussion!
Format of Meeting
This meeting will be organized as a group discussion. Although at times = one or more of us may lead discussion sections, it is meant to be a group d= iscussion and not a series of presentations.
Meeting Notes will likely be taken on PiratePad: http://piratepad.net/= a>
AGENDA:
"Master of Ceremonies (MC)": R= ichard Rodgers, MIT
9:00am: Introductions, Overv= iew of Day (Discussion Director: Richard Rodgers)= p>
9:15am: DuraSpace / Fedora /= "DSpace with Fedora Inside" Discussion & Updates (Featu= ring Jonathan Markow)
10:15ish : Break
10:30am: DCAT Discussions (Discussion Director: Val Hollister)
11:00am: Open Discussion Per= iod (Discussion Director: Sarah Shreeves)
12:30 - 1:30pm: Lunch Break<= /span> (LUNCH WILL BE PROVIDED)
(Please note that the after-lunch sessions are meant to be a bit mor= e "technology heavy". Non-developers are still welcome to sit in, if you wi= sh. Though you are also welcome to join up again later at the chosen local = pub. It's entirely up to you.)
1:30pm: 3.0 Planning / Updat= es / Digging Deeper (Discussion Director(s): Robin Taylor)= strong>
2:30ish: Break
2:45pm: Discussion of DSpace= Developer Practices (Discussion Director: Mark Diggory)
3:45pm: Summarizing & Br= inging it all Together (Discussion Director: Richard Rodgers= )
4:00ish: End Meeting & D= epart for the Pear Tree House Pub for Food/Drink
This is a list of topics which we may wish to touch upon either duri= ng the "Open Discussion" period, or during another part of the day. This li= st is unordered and unr= anked.
Please feel free add any topics to this list that you feel would be wort= h discussing!
If you're planning to attend this meeting, please add your name to the s= ign up sheet. This will allow us to determine a proper headcount. If you on= ly plan to attend for part of the day, you can also let us know (e.g. "AM o= nly", "PM only", etc.).
Sign Up Sheet - Will Be Attending
Want To Attend / May Be Attending
Will Not Be Attending
The following is a brief summary of the meeting. No official note ta= ker was appointed. These notes are cobbled together, based on the shared re= collection of those in attendence, and the notes they've made available. If= you have a revision or an addition, please share. Thanks!
Jonathan Markow began the day with an explanation of a new initiative fr= om Duraspace called 'Managed Projects', this was further expanded on in the= Duraspace plenary. In response to promptings from the Fedora committers Du= raspace will attempt to organise funding and/or resources to facilitate mor= e sizeable pieces of work. (More on "Managed Projects" can be found at: Fedora Committer Mtg Notes (2012-05-10)= - This was the first mtg where Managed Projects were discussed with the Fe= dora Committers) He continued with a brief discussion on 'Fedora inside DSp= ace'. It was noted that no institution has been willing or able to take on = this work and as such it has not progressed. This is not to say that the id= ea is dead, just a statement of reality.
Some cross discussion about best ways to foster big development projects= /large architectural changes in community-supported open source projects. A= discussion of a need for better communication between committers and the c= ommunity, possibly an information exchange about active development project= s. Valorie Hollister pointed out that there is a page for this information = on the wiki, the Developm= ent Proposals page, though it was later pointed out that the wiki page = doesn't really provide a good way to track project status.= Bram Luyten suggested the possibility to automatically track an "outside" = project status by linking to other issue trackers and wikis, perhaps via RS= S feeds.
Valorie Hollister spoke about DCAT:- a description of what it is, who pa= rticipates, etc. Valorie observed that the "most successful meetings have b= een when committers have been present," which leads to a discussion of ways= to encourage this synergy in the future. The idea of a regular joint meeti= ng of DCAT and the committers was brought forward. Everyone in the room see= med to agree that making a specific agenda available prior to a joint meeti= ng would be key to the success of the meeting.
Some ideas were proposed to create better awareness of DCAT:
Currently, DCAT meetings are one hour phone conferences (where you can a= lso use Skype to dial in). The developers present in the room shared benefi= ts of using IRC for text based chat meetings (could be in parallel with pho= ne conversation):
The developers commented that if DCAT will create new issues in JIRA, it= would be best if:
Commenting on existing issues is no problem at all and should be encoura= ged at all times.
This discussion segued into the subsequent session hosted by Sarah Shree= ves on 'hot topics'.
The following topics were offered for further discussion: Metadata, Auth= (both N and Z), XMLUI Repository, i18n, Configurable Submission. Taking th= e topics in order, the discussion around "metadata" (generally understood t= o mean the concept of "metadata for all objects") was lively, and seemed to= hover closer to the need for a better definition of what "metadata for all= " really means. Richard Rodgers discussed his MDS work, where it's clear th= at the existing metadata system can easily be extended to apply to all DSpa= ce objects. Richard acknowledged that there's some question and need for fu= rther discussion whether this is "good enough" to serve the use cases envis= ioned for "metadata for all?" Some stumbling blocks for acceptance of this = approach would be the current state of date handling in the code base, and = the "simple" or "flat" metadata approach may not be as expressive as necess= ary. At least one committer declared there is value in simply extending the= existing design to all objects, citing the usefulness of a consistent inte= rface. Richard Rodgers then asked what the status of the DCAT recommendatio= n for out of the box metadata schemas might be. Bram Luyten offered that DC= was the clear winner, just from a skimming of the results. Amy Lana pointe= d out that DCAT is still evaluating the survey results. Mark Diggory urged = caution before proceeding, since a recommendation from DCAT is still in the= works. Richard Rodgers asked whether DCAT should also consider recommendin= g a migration path from the existing model to their recommendation.
There was also a discussion of the need for better integration of contro= lled vocabularies and identifier systems, such as ORCID. There appeared to = be consensus that integration with ORCID would be a clear win for the vast = majority of DSpace repositories given that most are focused on people.
Configurable submission was the next topic tackled, Elin Stangeland is k= eenly interested, but says that things appear to be a bit messy: DCAT has a= wiki page up for discu= ssing/prioritizing, there was a Google Summer of Code project on the to= pic, Robin Taylor adapted some of the code from GSoC and put it into a patc= h, but only added the back-end code, not the interface work (nodding heads = from many committers in the room), MIT is working on Context-guided ingest.= Elin stated, and there seemed to be agreement, that what is needed is a de= veloper to champion and make sense of the state of the work. Robin offered = to take the topic up with the committers. Bram cautioned that "use cases ar= e important for this feature," especially how one actually customizes the w= orkflow (i.e. via a config file, or a web-based interface). For example, a = delegated admin (collection or community admin) should have the functionali= ty to modify the submission process for his or her collections, without bei= ng able to access or change those of any other collections. Furthermore, th= e person who can take the design & functionality decisions for the subm= ission process might not necessarily be someone who knows how to modify an = XML config file, or have the authority to do a server update & restart = to put certain changes to effect.
A number of "repository" ideas were discussed next, an XMLUI "theme gard= en" has long been on the wish list, and now add to that a curation task and= SWORD package garden/repository. From the discussion, it seems like GitHub= can handle the actual code storage handily, it's just an issue of discover= ability. The wiki may work OK for this task. To motivate contributions to t= he XMLUI theme garden, it could be nice if those themes could easily be sur= faced in the demo repository. Richard Rodgers asked, "who takes the lead?" = on implementing this idea? The consensus seemed to be that we should push t= he community to use the wiki at first and that as the number of shared them= es, etc grows we should revisit a more formal strategy.
Wrapping up before lunch, a final question: "how do we deprecate code?" = (The question was raised in relation to the JSPUI but was relevant to other= code). Do we need a formal process, with a comment period? How could a fea= ture or an area of functionality be identified for deprecation? The easiest= case is when there is something better replacing it, guaranteeing to cover= all of the original functionality while still being backwards compatible. = It's a good question, but we're all hungry, something to think on in the we= eks to come.
After lunch Robin Taylor hosted a discussion on the upcoming DSpace 3.0 = release. A list of major contributions is still to be identified, more work= required here. The provisional schedule was discussed and no objections we= re raised.
It was observed that there are a number of pull requests listed on the D= Space 3.0 wiki page, almost all of them needing further testing. If you're = itching to contribute to the 3.0 process, please do consider testing these.= In addition, Richard Jones has a new SWORD2 contribution (general improvem= ents, pull request is "imminent").
Robin pointed out that we have about five weeks until feature freeze on = august 17th.
Mark Diggory would like to do some Maven restructuring/refactoring, whic= h makes the most sense to do as part of the RC release process, post-featur= e-freeze, so as to minimize the impact on active development.
In relation to the testathon, the question came up whether there is stil= l an accurate checklist of things that require testing, like this one that was created= for 1.5
Mark Diggory began a discussion on developer practices with a tutorial o= n Git and Github and how they relate to DSpace. Mark referred to the ThinkupApp's "Contributor Workflow"= , which closely mirrors the suggested DSpace Git workflow. He used a prezi version of the= diagram, for walk-through purposes.
Tim Donohue has formulated compelling improvements to the current DSpace JIRA Workflow.&= nbsp; In short, the current JIRA statuses (Open, Received, In Progress) do = not clearly reflect what a JIRA ticket is "waiting for" exactly. T= herefor, following improvements are proposed:
In the discussion that followed it was debated whether there should be a= DCAT specific status to indicate that DCAT is taking on specific issues, e= specially in the "Needs more details" and "Needs volunteer" statuses. I don= 't think there was a unanimous opinion here so just noting that I personall= y think the fewer different statuses, the better and DCAT can show its acti= vity in the comment logs within particular tickets. Activity on tickets wil= l put them higher on the list of "last changed" tickets which will get them= more attention anyway.
Quite a few interesting points popped up on the future potential of DSpa= ce in different contexts. Stuart Lewis argued that DSpace is in pole positi= on to offer more extensive support for digital preservation. The platform might not be up to part with the digital preservation promi= se right now, but he assured that all the necessary hooks are present. As a= n example, he indicated that hooking in JHove // Pronom would only be a mat= ter of a few days of development.
Richard Rodgers mentioned LOCKSS for items & SafeArchive (BramL:= my notes are vague on this :()
The group felt like the game is still wide open when it comes to leverin= g DSpace as a platform for managing research data. No othe= r platforms are arising at the moment with substantial different feature se= ts than repositories, so again, an opportunity for DSpace.
There was discussion about the relation between CRIS systems (like PURE, Avedas, Symplectic, ...) and repositories. Particularly i= n Europe, CRIS systems are aggressively on the rise as they facilitate comp= liance with national reporting requirements, such as the RAE in the UK. App= arently in the US this trend is less visible. With CILEA's upcoming contrib= ution of CRIS functionality for DSpace, there was discussion on whether DSp= ace could and should offer more CRIS functionality. There didn't seem to be= a unanimous opinion on this topic.