Dial In Details

Date: Friday September October 30, 2pm EDT (-4 UTC)

• Dial-in Number: (712) 775-7035
  • Participant Code: 479307#
  • International numbers: Conference Call Information
  • You may also call in using the VoIP dialer from a web browser, or Android/iOS apps
• IRC:
  
  • Join the #fcrepo chat room via Freenode Web IRC (enter a unique nick)
  • Or point your IRC client to #fcrepo on irc.freenode.net

Meeting Goals

1. Determine where we are in the use case evaluation and requirements gathering process
2. Determine how we transition to design and development.

Attendees

• Aaron Birkland
• Unknown User (acoburn)
• Stefano Cossu
• William G. Cowan
• Daniel Davis
• Randall Floyd
• Unknown User (daniel-dgi)
• Elliot Metsger
• Bethany Seeger
• Joshua Westgard
• Andrew Woods

Agenda

1. Discuss use cases that have been evaluated per the adopted criteria
2. Can we assemble an initial list of requirements for the next meeting?
3. When do we think it makes sense to formally designate roles and resource commitments?
4. Do we want to plan for a design/proof-of-concept sprint?
5. Do we want to adopt an approach of selecting one or more use cases for initial implementation as an extension?
6. Current events and outreach, async storage meeting and Hash URI thread

Related Resources

Design Page (with use cases outline)

Use Cases Parent Page

Previous meeting agenda, including minutes

Minutes

• Aaron Birkland runs through evaluation of Generic Use Case: Adding http 'headers to Fedora resources (e.g. Signposting) as an example of use case evaluation
  • Unknown User (daniel-dgi) believes this filtering pattern may suit some Islandora use cases
  • Reveals interest in deployability in the context of a proxy, or alongside Fedora
  • Indicative of a general filtering pattern
• How do we like the evaluation requirements?
  • Looks good
  • Unknown User (acoburn) and Joshua Westgard thought the evaluation process itself was revealing
    • For Amherst, many of their use cases have already been implemented as independent services.  The appealing aspect of API-X is discoverabilitty
• What is our trajectory towards a list of requirements hands on the keyboards?
  • General consensus that it is still a little early to consider this, need to define set of stakeholders
  • Stefano Cossu proposes that stakeholders self-identify, pick out the use case(s) that are relevant to them, then from these decide the initial set of use cases that drive implementation
    
    • General consensus around this plan
    • Maybe add a wiki page for this list
    • Some have concrete use cases they're committed to, but timing/resources won't allow participation as a formal stakeholder in API-X, at least in the short term.
• Recap of 2015-10-28 - Asynchronous Storage Meeting
  • Evolution of async storage use cases will clarify understanding of role of API-X.  Some storage integration points may likely not be through API-X, as they may be more involved with Modeshape layer, or lower.
  • Some members from both Async Storage and API-X will attend each other's calls
  • +1 for cross-polination of efforts from Andrew Woods
• Action items for next call:
  • Stakeholders self-identify, pick a use case (or use cases), make sure they are evaluated, and be prepared to discuss on next call
• Agenda items for next call:
  • Sort through this list, figure out a process appropriate to the number of stakeholders and initial use cases.