Page History

...

Valorie Hollister spoke about DCAT:- a description of what it is, who participates, etc. Valorie observed that the "most successful meetings have been 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 meeting of DCAT and the committers was brought forward. Everyone in the room seemed to agree that making a specific agenda available prior to a joint meeting would be key to the success of the meeting.

Some ideas were proposed to create better awareness of DCAT:

• Invite new repositories (through their managers after they signup for a listing on dspace.org)
• invite duraspace sponsors
• find ways to approach the non-english speaking community.
  • Translated wiki pages?

Sarah Shreeves open discussion

...

Configurable submission was the next topic tackled, Elin Stangeland is keenly interested, but says that things appear to be a bit messy: DCAT has a wiki page up for discussing/prioritizing, there was a Google Summer of Code project on the topic, Robin Taylor adapted some of the code from GSoC and put it into a patch, 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 developer 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 are important for this feature," especially how one actually customizes the workflow (i.e. via a config file, or a web-based interface). For example, a delegated admin (collection or community admin) should have the functionality to modify the submission process for his or her collections, without being able to access or change those of any other collections. Furthermore, the person who can take the design & functionality decisions for the submission 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 "repositoryA number of "repostiory" ideas were discussed next, an XMLUI "theme garden" 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 discoverability. The wiki may work OK for this taskThe wiki may work OK for this task. To motivate contributions to the XMLUI theme garden, it could be nice if those themes could easily be surfaced in the demo repository. Richard Rodgers asked, "who takes the lead?" on implementing this idea? The consensus seemed to be that we should push the community to use the wiki at first and that as the number of shared themes, 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? other code). Do we need a formal process, with a comment period? How could a feature 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 weeks to come.

...

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, which makes the most sense to do as part of the RC release process, post-feature-freeze, so as to minimize the impact on active development.

In relation to the testathon, the question came up whether there is still an accurate checklist of things that require testing, like this one that was created for 1.5

Mark Diggory on Github and new JIRA Workflow

...