Page History

...

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 community, possibly an information exchange about active development projects. Valorie Hollister pointed out that there is a page for this information on the wiki, the Development 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 RSS feeds.

...

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.

Sarah Shreeves open discussion

This discussion segued into the subsequent session hosted by Sarah Shreeves on 'hot topics'.

The following topics were offered for further discussion: Metadata, Auth (both N and Z), XMLUI Repository, i18n, Configurable Submission. Taking the topics in order, the discussion around "metadata" (generally understood to 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 that the existing metadata system can easily be extended to apply to all DSpace objects. Richard acknowledged that there's some question and need for further discussion whether this is "good enough" to serve the use cases envisioned 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 necessary. At least one committer declared there is value in simply extending the existing design to all objects, citing the usefulness of a consistent interface. Richard Rodgers then asked what the status of the DCAT recommendation 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 pointed 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 recommending a migration path from the existing model to their recommendation.

There was also a discussion of the need for better integration of controlled 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 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).

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? Confluence plugin

Currently, DCAT meetings are one hour phone conferences (where you can also use Skype to dial in). The developers present in the room shared benefits of using IRC for text based chat meetings (could be in parallel with phone conversation):

• Automated transcript of everything being typed
• Subject overlaps, easy to pick up on something someone else has said before in parallel to another topic going on. This takes some time getting used to
• It tends to be short & very focused. Barrier is higher to keep typing as opposed to keep talking on the phone.

The developers commented that if DCAT will create new issues in JIRA, it would be best if:

• it's thoroughly verified if the bug or feature request isn't already logged in another JIRA ticket. If variants or related problems are logged, use the functionality to link JIRA tickets together.
• the issue category is carefully selected: New feature, improvement or bugfix is carefully considered.

Commenting on existing issues is no problem at all and should be encouraged at all times.

Sarah Shreeves open discussion

This discussion segued into the subsequent session hosted by Sarah Shreeves on 'hot topics'.

The following topics were offered for further discussion: Metadata, Auth (both N and Z), XMLUI Repository, i18n, Configurable Submission. Taking the topics in order, the discussion around "metadata" (generally understood to 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 that the existing metadata system can easily be extended to apply to all DSpace objects. Richard acknowledged that there's some question and need for further discussion whether this is "good enough" to serve the use cases envisioned 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 necessary. At least one committer declared there is value in simply extending the existing design to all objects, citing the usefulness of a consistent interface. Richard Rodgers then asked what the status of the DCAT recommendation 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 pointed 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 recommending a migration path from the existing model to their recommendation.

There was also a discussion of the need for better integration of controlled 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 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 task. . The 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? to 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

...