Dial In Details

Date: Friday August 14, 2pm EDT (-4 UTC)

- U.S.A/Canada toll free: 866-740-1260, participant code: 2257295
- International toll free:  http://www.readytalk.com/intl 
- Use the above link and input 2257295 and the country you are calling from to get your country's toll-free dial-in number
- Once on the call, enter participant code 2257295

Meeting Goals

Achieve shared understanding of:

  • The proposal, at least at the high level

  • Participant’s roles and commitments

  • Development process

  • Process for reviewing, prioritizing, and accepting use cases and requirements

Discuss (time permitting):

  • Current use cases

  • Scope

Attendees

Agenda

  1. Introduction and Proposal Review

  2. Roles and Commitments

    1. Identify Stakeholders, Designers, Developers

  3. Development Process(es)

    1. Sprint-based?  Two-weeks in length? For design and development?

    2. Process for identifying what tasks go in a sprint

    3. Communication modes (IRC, Slack, list email, etc?)

      1. Does every role have to be at every meeting?  Sensitive to the time commitments of Stakeholders, especially

    4. Location for documents, code (Duraspace wiki?  Fedora GitHub?)

  4. Process for reviewing and accepting use cases, scope, and requirements

    1. Do we vote on them?

    2. Prioritize them in some way?

  5. Discuss Use Cases

    1. Are they adequately described?

    2. Do we have all the use cases we need or want?  Are there more?

  6. Discussion of scope

Related Resources

Minutes

Intro:

  •  Data Conservancy use case based on Fedora 4
    • Attractive capabilities, but some shortcomings
  • Ultimately want to be able to develop, deploy, and expose services on top of fedora repository in a formalized manner
  • Everybody agreed that this is external, outside of Fedora core
    • Aaron B:  Recent OSGI work may mean it will be possible some day to deploy extensions easily in same container/framework, but extension framework is not going to be part of the core, and ideally would not not require any changes to core.

Listing names and roles:

  • Stefano:  discussing use cases first will help define roles

Use cases:

  • Place on the wiki to put use cases?
  • Joshua: I'm here to listen.  Have plans for Fedora 4 for research data.  Sounds like the kind of feature to keep up to date on, so no specific use cases right now.
  • Ruth:  coming from stakeholder role, existing use cases are not really written in the manner I'd expect.    e.g. "As a user, I want to expose OpenSearch services over object content..."
    • Adam:  Be careful, this is middleware, not user-facing software
    • Elliot:  If you want to provide an OpenSearch, that would be a use case for an extension, need to work back to determine requirements for extension arch.
    • Stefano:  Group use cases into main issues, then come up with requirements based on that.
    • Consensus  is to accept end user use cases, then work backwards.
  • Where should we put them?  There's a template on the Fedora wiki
  • If people have not seen the use cases page, there may be some of interest there
  • Put use cases in a subpage of the extension architecture wiki page.
  • Look through existing Fedora use cases - are there any that apply to this work?
  • Action item:  Create subpage for use cases.  People with existing use cases will put them on the wiki, people with new use cases will be encouraged to do so as well.

Are there any use cases already that have particular appeal to people?

  • Package ingest of complex, multi-part objects
  • Sharing and deployment of extensions people develop.  Infrastructure should make this possible to do, even easy and pleasant.
  • Domain models
  • Selecting, combining, transformation across objects to produce a representation
    • This also is concurrent with the interests of  AIC.  CRUD of representation of resources, but middleware maps it to a set of operations inside and outside of Fedora.  Several use cases for that.
  • Access control outside of Fedora to index.
  • Shipping content from Fedora to APTrust.
    • Sounds similar to "select objects and do something with them"

Next steps:

  • Period of time to add use cases to wiki
  • Collectively categorize them, select some that would help inform the design.

Possible Roles Revisited

  • Stefano: stakeholder
  • Ruth, Lynn, Peter:  stakeholder
  • Aaron Coburn:  this architecture is similar to what we're going to want to be pursuing, so we're interesting in being involved in some capacity
  • Elliot, Aaron B: development
  • Dan:  Sidora using a similar set of technologies.  Can contribute use cases and architecture design, as well as experiences
  • Joshua:  Probably shouldn't commit to too much, but interested in following progress

Action item:  Define a clear amount of time to define use cases as children pages of the one indicated.

  • We meet two weeks from now, same time (Friday Aug 28, 2 PM EDT)
  • Have use cased on wiki, as a subpage of API Extension design page, by end of 25 August
  • Please list your name by names use cases as "possibly interested party" or "this is important to me
  • Use fedora-community-list for communication


Minutes of the introduction of the proposal, Fedora Committers Meeting June - OR ‘15

  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.