\\

h2. Logistics

* *Meeting Location: University of Virginia*
* *Clark Hall (building 11) at 291 McCormick Rd, Central Grounds UVa* or section D4 on this *[map|http://www.virginia.edu/webmap/GMcCormickRoadArea.html]*
** [C'ville Accommodations]
* *Dates:Wednesday June 6 - Friday, June 8*
** Wednesday: 11 AM Assembly, 11:30 AM start time (Clark Hall/Brown Science and Engineering Library, 148)
** Thursday: Steering 8:00-9:30 AM, Partner's Meeting starting 9:30 AM, end 5 PM (ClarkHall/Brown Science and Engineering Library, 148)
** Friday: Partner's Meeting starting 8:00 AM, wrap-up 5 PM (Clark Hall/Brown Science and Engineering Library, 148)

h2. Attendees

* [*Attendee Roster/Registration*|Attendees list]\\

h3. Partners' meeting

* Institutional Updates
* Preservation and Fedora
* Fedora Development Roadmap & how it relates to Hydra
* APT & DPN
* Fedora performance, scalability
** Scholarsphere
** MediaShelf Fedora sharding project / benchmarks
* Date and venue of next meeting (September)?  ND?  RockHall?
* New Release Managers
* Should the website have more 'up front' info about software releases? (See Islandora.ca)
** which website?
* UI code and the Hydra stack
** How do \*you\* create a new hydra head?
** Splitting out UI code
*** how feasible is this
*** who will maintain it?
*** how maintain integrity of full stack?  (i.e. if changes to a part of the framework breaks the UI)
* is there enough overlap to warrant an institutional repository hydra head?
** is there enough commonality?   data, modeling, ui needs, etc.?
** make this the demo instance?
* demo instance
* Documentation checkup (non-technical)
** what is missing?  what gaps exist?  how will we fill them?
** are the different web site purposes clear?  (projecthydra.org, duraspace, github ...)
** can folks find what they need?  (newbies, wannabes, explorers, etc.)
** Related Jira issues, aka "The Hierarchy of Promises"
*** [HYDRA-507|https://jira.duraspace.org/browse/HYDRA-507]
*** [HYDRA-509|https://jira.duraspace.org/browse/HYDRA-509]

* Tech doc basic requirements  (e.g. "documentation must be sufficient for newly adopting developers to be able to ...")
* OR12 planning
** Talks and their presentation (calendar?)
*** Workshop
*** Hydrasphere FUG talk
** Table/stall for demos and as focus for conversation
** Social?
* Code license review
* Software/hardware stack exchange of information (to be carried on in the developers meeting as required)
** Where is everyone with the different software components (i.e., what is the stage of implementation for each site)?
** How can local institutions best keep pace with keeping local apps in sync with latest developments?
** What issues have arisen in upgrading (and could be useful learning for prospective partners)
** What hardware stack are partners using, and what pros/cons have been identified in these choices?
* Fall webinars for DuraSpace
* HH5 update and planning
* Hypatia update (if Ben A. is attending)
* ScholarSphere demo/update
* HydraCamp
** 2012 details
** potential 2012 attendees/institutions
** evolving the model, expanding attendance, etc.
* Repository service management: support flows, etc.

h4. Partners' meeting - developers

* Technical Release planning
** Hydra-head
*** 4.1\+
**** Will have all the code deprecated
*** 5.0
**** Will have removed deprecated code in Hydra-Head
*** 6.0
**** No plans
** ActiveFedora
*** 4.x
**** Needs deprecations brought up to current standards.
*** 5.0
**** Will have deprecated code removed. (MetadataDatastream, ask Adam Wead (and the list) whether he cares)
** OM/Solrizer
*** 2.0 (not sure if anyone will actually tackle this. Might be cbeer)
**** Optimized documents (fewer fields created by default)
**** Insert and remove node with templates
**** Separating concerns
***** Addressing xml nodes
***** creating a solr document
**** Proxies can't override term indexing attributes (Ben will write a ticket for this)
**** Proxy vs Ref is confusing
**** More transparency to Nokogiri (path vs xpath)
* Deprecation/Removal code practices
** How do we decide what to deprecate?
*** TOMORROW
** How are we deprecating (syntax) 4.1
*** What version it was deprecated in (as code comment).
*** Target removal release.
*** extend Deprecation
*** {color:#333333}deprecation_deprecate :method_name (For each method that will be removed){color}
*** YARD @deprecated documentation 
*** Classes/modules do not need any deprecation warning, so long as all the methods are deprecated
*** {color:#008080}Deprecation{color}{color:#333333}*.*{color}{color:#333333}silence{color}{color:#333333}(ClassName){color} { deprecated_method_call() } {color:#333333}on our code using deprecated methods.{color}
** When do we deprecate?
*** DECIDED: When we deprecate functinoality in a minor (e.g. 4.1) we can remove it in the next major release (e.g. 5.0)
* which ruby platforms are we supporting?
** Survey the list -  What version of ruby is everyone deployed to?
** can we NOT insist on a particular rubygem version
*** YES - this was because of a bug.
** Can we get rid of .rvmrc
*** YES - have your own .rvmrc  (don't check it in to git)
** Git rid of Gemfile.lock (in AF)
*** YES put in the .gitignore
** Recommendation: Keep Gemfile.lock at app level
* *Splitting out UI code*
** *how?*
*** Whiteboard exercise for tomorrow
** Out-of-the-box Hydra Heads?
** Hydra-as-a-framework helpers
* *Documentation*
** what is missing?  what gaps exist?  how will we fill them?

* -Hudson fun-

* -Ruby autoload is going away in 3.0 (or at least deprecated)-
* OM roadmap
** "insert node", "remove node" approach per Hydrus
* Solrizer default behaviors (strategies for making Om terminologies less verbose in solr)
* Security - Datastream-level permissions
* The "depositor" field, apply_depositor_metadata, and the deprecated properties datastream
* How to stay on the bleeding edge without bleeding out
** Was a bug that HH was pinned to a specific version of AF.
* Technical Documentation needs

* [HYDRA-804|https://jira.duraspace.org/browse/HYDRA-804] What is necessary for creating a hydra model?

* Test coverage
** what is missing
** how do we fill gaps
* Course reserves

* Wrangle Jira tickets older than a year
* [HYDRA-696|https://jira.duraspace.org/browse/HYDRA-696] Ben worked on this.

h6. Additional issues for developers brought up at the June 4 committer's call

*  

h3. Steering Group

* where should Hydra be in one year?  Two years?
* December meeting.  Steering Group only?  Where?
** _discuss with Partners. Dec Partner meeting valuable?_
* Protecting the Hydra brand.  Trade mark process $5-10,000 ???
** talk to lawyers
* [Hydra Community Use Cases]
* Hydra Meetings - SG, Partner and Developer Meetings
** Sept 2012 and beyond:
*** Name should allow for mix of SG, partners and developer activities "Hydra Meeting"
*** Increased use of multi-track
*** Demos limit to twice per year at multi track meetings
*** Engineer Code Swap annual hackfest type meeting is desired (e.g. DIL or ScholarSphere into other IRs) Winter prior to Cod4Lib and DevConX would be good
*** An annual SG retreat to focus on strategic direction would be useful
** Winter Meeting, Jan San Diego
*** Co-location with developers would allow combined dinner discussion
*** Time for SG to step aside and take a fresh look at Hydra direction
*** smaller number of people
*** visioning retreat
** Overall
*** Winter Jan Developer & SG Retreat
*** Spring Mar LibDevConX & Hydra MultiTrack
*** Summer Hydra MultiTrack potentially co-located with OR?
*** Fall Hydra MultiTrack