Participants

Jessie (Stanford)
Matt Zumwalt (MediaShelf) - moderator
Justin (MediaShelf)
Joe (UVa)
Naomi Dushay (Stanford)
Bess Sadler (Stanford)
Chris Beer (WGBH)
Bill Parod (Northwestern) - notetaker
Others...

Agenda

Select Moderator and Notetaker
1. Matt Zumwalt moderator; Bill Parod notetaker
Call for Additional Agenda items
Blacklight Project
1. strategic directions
  1. 3.2 will be out in the next few weeks:Multiple configs per controller;
  2. SASS Refactor, abstracting out the stylesheet for rendering;
  3. Streamlining customizability, making core leaner / modules that provide more advanced features;
2. release planning
  1. Master git branch should always be runnable;
  2. Feature branches are used for development and fixes;
  3. Try to do semantic versioning / debatable; Try to insure that patch releases don't break anything; Though because any method can be overridden, it's difficult to claim that a new version is backwards compatible.
  4. Perhaps over time, Blacklight can start declaring private methods to protect backwards compatibility, facilitating semantic versioning.
3. overview of configurability, intended overrides, etc
  1. It's a Gem;
  2. Worked on the helpers and controllers to make them more "Railsy";
  3. Catalog behaviors are all in a module;
  4. Can pull in Blacklight functionality as needed; CatalogController renaming can be accomplished in router;
  5. Blacklight provides more straightforward hooks for setting search params and "before" filters based on current controller's request. Hydra uses that to inject access control into the searches for gated discovery;
  6. Helpers (View helpers) are now organized as modules that you can include in your helpers;
  7. Justin reworked Hydra's helpers to work that way; Motivated by wanting to make it easier to override Helper methods; More explicit about what is being loaded and when.
4. how to do Blacklight patches
  1. Create Jira tickets
  2. Make pull requests
  3. Attend IRC channel to answer questions.
  4. What's the best way to contribute plugins?
    - Same issues as writing and sharing a gem. When should it be in a gem and when should it be in blacklight?
    - Needed hooks to make a gem possible probably should go in Blacklight;
    - If you're making a plugin and have to fight Blacklight in some way to make it happen, that's a candidate change to core.
Hydra Project
1. strategic directions
  1. Up until Rails 3, the Hydra Rails 2 use of Blacklight:
  2. Start with Blacklight - add to that edit views and assets controller to update, create, delete assets (Fedora objects);
  3. Edit views are mitigated through Cataloger; Asset CRUD requests go through a single controller;
  4. Rails 3:
  5. With ActiveModel support if Rails 3. Now ActiveFedora objects behave more like ActiveModel objects; Using ActiveModel APIs.
  6. Moved Hydra towards controller/views per model (create, edit, show, update, delete) methods
  7. Blacklight's role is now confined to searching rather than also providing the application's broader MVC framework.
  8. Makes the code more readable and is more "Rails-ish" and recognizable to Rails developers.
  9. Facilitates workflows - multi-step interactions - by allowing each content type to have its own controller
  10. Blacklight is now the "Solr controller"
2. release planning
  1. Moving towards quarterly release; patch releases "weekly" if there are new patches that week;
  2. Patch releases are just bug fixes; no new features;
3. Blacklight usage that blacklight committers should be aware of
  1. For release planning, should we consider synchronizing releases?
  2. Rails 3 timing made sense. If Hydra is putting a major release every quarter, perhaps coordination with Blacklight, we can prevent lags between Hydra/Blacklight major release.
  3. Knowing in advance what changes are coming in the other platform makes it easier to react and keep your platform compatible.
Hydra Project's Pinch Points
1. please put specific pinch points here

- Good things that have helped Hydra - putting helper behaviors in lib has really helped Hydra
- If there are controllers that should be in its own module, let Blacklight know.
- The other direction - pulling a controller out of a module - is also possible, though more difficult, but let Blacklight know when that's useful.
- Overriding Views; Each function as gems, provide partials rather than overrides.
- Easier to provide your own layouts without having to undo/override Blacklight partials; continually with each new head
- The SAS makes it easier to modify as well.
- In writing thorough documentation on writing a Hydra Head and customize, have covered some Blacklight documents. Will notify Blacklight folks for pickup / ownership…
- Blacklight documentation is editable. Perhaps Hydra should add/edit/reference it.
- Want to encourage the Hydra folks or other Blacklight adopters to let Blacklight know when something needed is missing; Or write it up and put in a pull request.

Blacklight project's action items: What configurations, hooks, API, documentation should be added?
1. None
Hydra project's action items: What in Hydra code should change to better leverage Blacklight?
1. Jessie and others: what in Hydra code should change
  1. configurations?
  2. helpers
  3. (e.g. refactor code to use x approach instead of monkey patch for feature y)

- Distinguish framework from heads:
- Here's Hydra the framework
- Here's the Hydra the MODS editor gem
- Here's the Hydra gated discovery gem/plugin
- Will discuss separation of MODS editor from core head in next committers call.
- Hydra Solr configuration needs work and attention. Modifications are needed to use it in other contexts/environments.
- Will schedule a joint Blacklight Hydra call like this as part of release planning

Browser not supported