IR vertical - how to work together

Owned by Bill Branan
Jun 16, 2017
3 min read

November 7, 2013: These are notes from conversations at the September 2013 Hydra partner meeting. See the Shared IR project for more up-to-date information about this developing initiative.

Managing Curate (shared IR candidate) with the community

General principles

  • We are going to park the discussion about vendors to provide hosting for a shared IR ā€“ we will talk about that next summer. We don't want to do anything that will prevent this, but aren't prepared to grapple with it as we are talking about product goals and how to work together

Timelines and needs:

What does it mean to share?

  • Technical approaches, these will be possible:
    • Shared bundle/popup installationĀ ā€“ reference implementation (like Curate)
    • Application that is customized -- gems from the IR bundle with additional customization (like CurateND)
  • Configurable/swappable elements
    • DOI provider
    • Authorization/identification services
    • Author identifiers/authorities (ORCID, LC, ISNI or other)
    • UI branding
    • Metadata specification field limits
    • Configurable workflows with constraints - certain number of steps (2 steps or 4 steps), not a full workflow engine. Mediated deposit is an example of an important workflow. Initial deposit is another.
  • General agreement on definition and scope: what do we mean by an IR? what distinguishes this from a DAM? Sufia is already a shared IR. Curate may become a second one. Be able to distinguish between these two options, what are the distinguishing features of each? Embedded in this: be more clear about where the two are going.
  • If there are big chunks of work that we want to see focused work on, big enabling tasks (like extracting mediated workflow from Hydrus), identify time to do it and people to do it. Is there a way to do this without being f2f?

Key next steps

  • Road map for ScholarSphere (Sufia), roadmap for Curate. How do we clearly distinguish between these for potential adopters? we would like a shared core
  • Have the IR/DAM/Curate/escholarship/services/scholarly work conversation. Not for local marketing/communications, but so that we know how to describe this thing we're building.
  • Answer the 'every institution' questions
  • Finish reviewing the strawman and deciding on our structure
  • Get organized with roles: who will do what, how will other organizations and projects (non-shared IR participants, other IR initiatives like DSpace, etc.)

Every institution wanting to participate in a shared IR:

  • What are your high level needs?
  • When would you like to go into production, what is your minimum viable product? How much flexibility do you have, what are non-negotiable dates/commitments?
  • When do you expect to begin active work on the shared IR project?
  • What resources can you contribute?

UVA

  • WhGoing into production June 2014

Notre Dame

  • ORCID grantĀ 
  • High level needs: video (including streaming), large files

Structure for working together:

Roles:

  • Campus/organization project director - high level vision, 5-10% time minimum, responsibility to larger stakeholders)
  • Overall product product owner & Campus/organization product owner - high level and detailed product vision, 25-35% time minimum, responsible for gaining campus director input, responsible for coordinating SMEs, writing stories.
  • Overall product tech lead -
  • Overall product tech lead UI/UX lead
  • Team members
    • Developers - specific expertise variable, time commitment variable but no less than 30% time desirable, likely to be assigned to project in chunks of two weeks corresponding to sprints, with approximately 2-3 sprints of advance notice
    • Subject Matter Experts (SMEs) - expertise in some specific area (metadata, content/data models, service support, policy, etc.), time commitment variable, likely to be told when to engage and to come and go from the project
    • Campus/organization Tech lead
    • QA
    • UI/UX

BELOW THIS POINT: ELEMENTS OF THE STRAWMAN THAT WERE NOT DISCUSSED/REFINED BY THE GROUP YET

General guidelines:
-No more than 3 product owners at one time, no one can be a product owner without observing standups and sprint plannings for at least one cycle
-If possible, a lead product owner should be identified to remove blockers
-To be a product owner, a campus/organization must be within two cycles of a direct contribution to development (in kind or $ to hire vendor resources)

Organizing work:
-Stories and tasks for the current sprint and the upcoming sprint are organized as issues in github. At this point, prioritization has already happened and the focus is making sure the work is understood and is of appropriate size for the available resources
-Stories and tasks for the backlog and beyond are drafted in the github wiki, and weekly updates and questions about these items should go out to one or more of the Hydra lists. Phone calls to discus and refine will be frequent but are scheduled on an ad hoc basis, and whenever possible, the community at large is welcome to join these conversations (this could get to be chaotic, but we could try it).

Questions:
-What about UI/UX, is this a specialty that should be called out? what about a scrum master?
-Should we be more or less structured about community feedback? have some kind of voting process?