Agenda for Deployer Meeting 8-10 February 2012

Owned by Patrick Schmitz (Unlicensed)
Last updated: Mar 26, 2012 by Angela Spinazzè (Unlicensed)
See Short Agenda

Agenda: Wednesday, February 8th (Start time: 1:00pm)

1:00 to 1:15: Welcome

1:15 to 2:30: Intro and discussion of current implementations, methods, and tools

Tell us about your deployment (a chance for big-picture introductions and context). Include how you do development, and the specific pain points in your development process.

Answer these questions as part of your intro (this will help guide the emphasis for the next few days):

  • Have you done simple UI customization, like changing a label, or hiding a field?
  • Have you done more ambitious UI customization, like changing layout of a record editor, or changing theme for whole UI?
  • Have you built a new UI widget, or changed the behavior of an existing one?
  • Have you done any schema extensions? Simple (few scalar fields) or complex (new, complex schema structures, repeating groups, etc.)?
  • Have you added a new procedure or authority?
  • What other types of customization have you done?

Related Discussion and Documentation

Museum of the Moving Image (15 mins)

Statens Museum for Kunst (15 mins)

Walker Art Center (15 mins)

History of Art Visual Resources Collection (10 mins)

Phoebe A. Hearst Museum of Anthropology (10 mins)

University and Jepson Herbaria (10 mins)

2:30-3:15: Core development team on development process, development tools, source code repos, etc.

30 minutes of presentation and discussion, and 15 minutes of questions.

Topics:

  • How central team uses and manages development tools
  • How we use repos (SVN and GitHub), for core development.
  • How UCB is managing source code for local work
  • Models for implementers to manage their local code, and planning for code contributions

3:15-3:25: Bio break (brief!)

3:25-5:00: Strategies for local and community extensions

This will inform the discussion of how we do specific extensions, to be covered over the next few days.

Topics:

  • Comparing notes on how you have approached extensions
  • What's coming with regard to the IMLS community of practice templates.

Goals (takeaways that are critical to completion of IMLS grant) include the following. Note that this session is an introduction to these topics - we will not complete all this in 90 minutes! We'll discuss this over the next few days, and will revisit these goals in subsequent sessions.

  • A documented approach and set of clear steps for the mechanics of how to assemble the set of extensions that a museum would want to use to build their tenant.
  • A framework/model and documentation for:
    • where templates and extensions live
    • how templates are discovered and accessed
    • how templates are integrated into local development
    • how templates are documented and maintained.
    • governance models for templates

Related Discussion and Documentation

Schema extension

Community code contribution process (walk thru of the process to contribute code back to CSpace using examples from UCB)

Related Discussion and Documentation

/wiki/spaces/collectionspace/pages/666275647

/wiki/spaces/collectionspace/pages/666276054

/wiki/spaces/collectionspace/pages/666276095

/wiki/spaces/collectionspace/pages/666275266

Agenda: Thursday, February 9th (Start time: 9:00am)

8:30-9:00: Breakfast

9:00-9:15: Recap and Agenda review

9:15-11:15: Walk-through of customization and extension use-cases

Meeting notes, 9 Feb 2012 AM

For each of the proposed use-cases, we'll discuss:

  • Preparation work required:
    • Schema, UI design, and community review.
    • Technical prerequisites and background (e.g., what fields are required in order to build an authority).
    • Planning for reuse.
  • Development steps (copy these files, global search and replace, etc.)
  • Testing an extension
Candidate use-cases for review

We'll canvas the group to choose from among the following list of use-cases. Most of them will illustrate general principles, but each of them has distinct technical issues.

  1. Customize a procedure or authority
    1. Add a field to a local or domain schema (in a new tenant)
    2. Apply another schema (from a template) to your record
    3. Add validation
    4. Roles and Perms and field-level perms
    5. Rename field or authority
    6. Add a field to a repeating field group (can not be done now without replacing the whole group -- what could we do to change this in the system?)
    7. Blue sky: Fundamentally change the data model (e.g., to display information from a related record on the main panel or right panel)
  2. Build a custom procedure (e.g., Claim/NAGPRA Claim)
  3. Build a custom authority (e.g., Place)
  4. Add UI widget or capability following discussions in the pre-meeting on Tuesday)
    1. Add a boolean widget
    2. Add link/button that examines a field that is a URL (e.g., link to image in another system) and open browser window)
    3. Add link/button that talks to an external web service (e.g., sends locality info to Berkeley Mapper and draws a map; sends locality text info to a georeferencing service, gets back locality data, stores data in system)
    4. Modify/extend report invocation widget to also invoke batch processes
    5. Modify report/batch widget to display a dialog requesting parameters for invocation
    6. Integrate data from related record on page

Related Discussion and Documentation

Documentation in process

11:15-12:00: David Greenbaum on sustainability and foundation

12:00-12:45: Lunch (brought in)

12:45-2:30: Walk-through of customization and extension use-cases (continued from AM)

More on community contribution models and practices, including:

Localization of CSpace

This conversation is on-going and needs a collective conversation to bring it to the next level

Related Discussion and Documentation

Localization Requirements

SMK Localization Use Case

2:30-2:45: Bio-break

2:45-5:15: Discussion of community contribution process

Building on the discussion of customization and extension use-cases, and on the sustainability and foundation presentation, we'll review:

  • The /wiki/spaces/collectionspace/pages/666275647 for making contributions
  • Gaps or weak areas in the existing workflows and process
  • Facilitating cooperation and preventing duplication of effort
  • Variants or different classes of contributions. E.g.,
    • a new procedure vs. a new template,
    • UI translations,
    • documentation and translations thereof
    • etc.
  • Structure of the community repository
  • Guidelines for adopters of contributions (especially templates)

Note: As part of the IMLS National Leadership Grant, these features/functions are currently being developed, have been developed, or were proposed to be developed by a museum involved in the grant.  

Museum of the Moving Image

  • interface for publishing collections on-line
  • procedures for condition checking and technical assessment

University of California, Berkeley

  • management for taxonomic, place, and concept term authorities
  • Native American Graves Protection and Repatriation Act (NAGPRA) management
  • batch processing examples
  • design and planning to extending collection objects and media objects to support hierarchic structures

Walker Art Center

  • API for using RFID to manage collections movement
  • procedure for managing insurance assessments and valuations

Others?

Evening: Drinks and/or dinner?

Possibilities (assuming the predicted good weather):

Agenda: Friday, February 10th (Start time: 9:00am)

8:30-9:00: Breakfast

9:00-11:00: Discussion of community contribution process (continued), OR more on Customization

Continued from Thursday: Community code contribution process (discuss development of features, functions, procedures, authorities that any early adopter is considering taking on in 2012 - to make sure that efforts are not being duplicated)

11:00-12:00: Schedules looking ahead

Roadmap review, and discussion of how this aligns with deployers' schedules and plans.

12:00-12:45: Lunch (brought in)

12:45-4:45: Other issues that you would like to discuss

(Meeting attendees: Please add your issues here)

  • Configuration
  • Using the common REST APIs
  • data import and ETL
  • http://issues.collectionspace.org/browse/CSPACE-3894 (adding/removing fields to groups)
  • NS: enable http caching for static assets (put nginx in front as a proxy server? Build default config? Or can this be turned on / off in the app layer?)
  • NS: we need to build an OAI-PMH endpoint providing at least CDWAlite, ideally oai_dc, etc.
    • Where does this go? App layer queries item XML and transforms is using XSL? Then we hook OAICat up to just use those calls instead of pre-formatted XML from a DB?
  • Aron: Flow of check-ins with switch to git from SVN (particularly pertinent for the project team right now)
    • When check-ins go from local to upstream, or through an origin repo (on a user's GitHub acct)
    • How pull requests are handed - who takes care of them, who is notified about them
  • ...

4:45-5:00: Wrap up, next steps

Agenda ideas, to be inserted:

More discussion of query or export or? for supporting things like public browsing.

Possibilities:

  1. Use the application layer to map services into a data model for the public browser
  2. Build new services that aggregate things for common cases
  3. Use a data warehouse model that exports CSpace data to a custom DB just for the browser.

Think about issues around media reuse sharing.

Managing documentation for current deployments

For sharing of experience, pain, etc.

Integration with external systems

Regular, automated import or export from/to another system

Linking to DAM systems, etc. for media management.

Fetching data, sending data, upon user invocation for specific tasks (placename resolution, mapping, query or export to genomic DBs, etc.)

Adding constraint logic on entered values

  • In the UI vs. in the services (user entry constraints, vs. data constraints including on import)
  • Code development and maintenance in Javascript vs. Java

Mini-build

  • How it's working for you
  • What you need from it
  • When it's appropriate to use it, and when not
    • When not appropriate: UI development work, very rapid UI turnaround of HTML/CSS changes via local loading with record.html

BOF (birds of a feather) sessions on specific topics

Do we want to consider this, or should we keep discussions global with everyone?

Specific topics might include:

  • Custom widgets, e.g., modifying structured date behavior
  • Citation authority requirements
  • Concept Authority for various authorities
  • CDWA (lite) mapping